标签：oo 总结 作业 任务 bug 电梯 PART waitQueue 单元
目录oo第二单元总结
PART 1 同步块构造与选择
本单元我们进入了多线程的世界,最重要的一个概念的就是同步锁,本单元作业均选取了synchronized锁,最开始我是有尝试在电梯的属性中设置synchronized,而这样的尝试让我连着四次失败,由此我借鉴了实验3的代码架构,简单地将传送带的所有方法设置了synchronized锁,后面我才反应过来,应该在printer(输出类)也上锁,防止输出顺序问题.同时在每次设置变动时notifyAll(),保证整体的顺利运行
PART 2 调度器设计
本实验中我的调度器的主要内容就是把任务从输入的传送带waitQueue分发到应当执行该任务的处理传送带上,前两次实验十分简单,直接根据任务的楼座或者楼层分发到对应队列即可,而第三次实验由于斜向请求的存在,我们必须能够拆分请求,笔者没有据此构造严格意义的最短路径算法,而是创建了新的find函数查询应该分配的队列,同时在请求(Person)中新增了是否中转标志,进行动态规划调度,即需要中转的任务多次进入调度器,完成了调度
PART 3 三次作业架构分析
三次作业架构分别如下
- 第五次作业
- 第六次作业
- 第七次作业
- 协作图
三次作业中第五次作业采取了单任务调度模式,这是在四五次重构之后求稳的无奈妥协之举,第六次作业开始我采取了look策略加电梯自由竞争:即电梯没有电梯内请求时,以距离最远的电梯外等待请求为目标任务,反之以电梯内任务最远处为目标任务,在每层及进出人时刷新,实现较为简单但是可能无法达到最优,第七次作业时我采用斜向请求动态规划,基于横向电梯开关门定制化问题,设置了Horizon信息类,方便处理队列查询,同时避免ProcessingQueue与电梯的过度耦合.
扩展性方面,理想中的第五次作业到第六次作业的迭代应该是由电梯父类派生出横向电梯与纵向电梯,但是我选择了统一使用电梯类,根据type不同,采用完全不同的两个任务处理策略,方便设置电梯进程,扩展可以选择继承电梯类或者加入新处理逻辑,针对电梯各运行参数,定制相关属性即可,而Horizon等特别信息类的出现避免了处理队列中绑定过多电梯使逻辑混乱.日后也可以通过这样的辅助查询的办法来实现类似需求.
PART 4 自我分析bug策略
本单元三次作业分别出现了如下的主要bug:
-
第五次作业:输出顺序不对的电梯
第五次作业由于前三四次架构都崩掉,可能无法实现捎带或者存在ctle,后面经过重构,尽管我的电梯无法实现捎带,但是解决了ctle问题,而我并没有注意到部分输出时间戳不递增的问题,后面经舍友提醒明白了需要关注这一现象,就在printer的静态方法中加锁
-
第六次作业:遁地的电梯
第六次作业一开始在本地和强测均没有暴露出什么奇怪的输出错误问题,但是后面我在检查自己代码时发现,我在输出arrive前,判断楼层移动时,可能存在这目标楼层与本楼层一致却移动的潜在风险,即可能有人从8楼下1楼电梯接到了从1楼到2楼的任务,部分情况下电梯掉头不及时,导致了电梯去0层虚空接人的bug,修改增加判定目标楼层是否与本楼层相同即解决了这个问题.
-
第七次作业:关不上门的电梯
这次的bug尤其可恨,让我直接十个点全ctle,bug来源是因为waitQueue的来源不止只有input了,其他没做完的中转任务也会被扔回去,所以需要新增waitQueue的属性todo去结算waitQueue是否完成所有任务的输入,但我只顾改动了为传送带添加任务请求的函数,忘记改动取请求的,后者应该在本队列为空并且(当前队列没达到末尾或者仍有任务会增加到waitQueue时)进入等待,我的朋友yhy则是在由waitQueue输入完成通知其余处理队列上增加了一些细节修好了这个bug,可以说他的处理方法更加简洁
由于本人第二单元未进行hack,故不在此分析hack他人策略
PART 5 感想与体会
从层次化角度来看,这次我的代码我个人认为得益于生产者消费者模式,有了较好的层次,input对接waitQueue实现数据生产,scheduler实现调度,processingQueue进一步让电梯们自由竞争任务,最后电梯执行任务,大概是这样的设计,各层次分工明确,在正常运行时不会过分干涉.
从线程安全角度来看,本单元最开始因为线程不安全问题,我经历了四次痛苦的重构,这让我深切体会到线程安全的重要.可以说本单元作业最大的感想就是心累与恐惧,第五次作业的时候,我花了一整个清明假期,经历了四五遍重构以及找周围朋友求助还是没找到陷入ctle点的问题,(真的是接近完全重构了),我迫于无奈转向了单任务型电梯,得到了稳定,然而问题并没有完全得到解决,第六次作业迭代难度并不大,很感谢这次的命题让我有信心重新面对电梯这一单元的问题,在好友建议要在处理队列建立任务容器而不是在电梯反复操作之后我终于解决了以前的问题,顺利实现了捎带,真的感谢给我支持的几位朋友以及讨论区的几位大佬,第七次作业我最后还是对着ctle无能狂怒,但我不断分析查看终于解决了问题,最后还努力去帮助和我有同样问题的人,我想学习确实是个人的事情,但是通过大家的讨论与合作,我确实成长了不少.希望我能不断精进自己debug水平,提升自我
标签：oo,总结,作业,任务,bug,电梯,PART,waitQueue,单元 来源： https://www.cnblogs.com/ladybeetle/p/16218729.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。