其他分享
首页 > 其他分享> > oo第二单元总结

oo第二单元总结

作者:互联网

目录

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:

PART 5 感想与体会

​ 从层次化角度来看,这次我的代码我个人认为得益于生产者消费者模式,有了较好的层次,input对接waitQueue实现数据生产,scheduler实现调度,processingQueue进一步让电梯们自由竞争任务,最后电梯执行任务,大概是这样的设计,各层次分工明确,在正常运行时不会过分干涉.

​ 从线程安全角度来看,本单元最开始因为线程不安全问题,我经历了四次痛苦的重构,这让我深切体会到线程安全的重要.可以说本单元作业最大的感想就是心累与恐惧,第五次作业的时候,我花了一整个清明假期,经历了四五遍重构以及找周围朋友求助还是没找到陷入ctle点的问题,(真的是接近完全重构了),我迫于无奈转向了单任务型电梯,得到了稳定,然而问题并没有完全得到解决,第六次作业迭代难度并不大,很感谢这次的命题让我有信心重新面对电梯这一单元的问题,在好友建议要在处理队列建立任务容器而不是在电梯反复操作之后我终于解决了以前的问题,顺利实现了捎带,真的感谢给我支持的几位朋友以及讨论区的几位大佬,第七次作业我最后还是对着ctle无能狂怒,但我不断分析查看终于解决了问题,最后还努力去帮助和我有同样问题的人,我想学习确实是个人的事情,但是通过大家的讨论与合作,我确实成长了不少.希望我能不断精进自己debug水平,提升自我

标签:oo,总结,作业,任务,bug,电梯,PART,waitQueue,单元
来源: https://www.cnblogs.com/ladybeetle/p/16218729.html