度量分析和思路简析
•第一次作业:
思路:
第一次作业主要是为了让我们熟悉多线程的操作,难度比较低.
在这次作业里,我设置了三个线程,main线程,Elein线程和电梯线程.
共享对象则是请求队列RequestQuene.这次作业中,我采用了生产者-消费者模式,Elein读入请求后把请求放到RequesQuene中,当RequestQuene不为空时,电梯从RequestQuene中取出请求并按自己的调度策略执行.在调度策略方面,我采用的就是题目所说的ALS.电梯按ALS获得主请求,每到一层判断有无要下电梯的请求或同向可捎带请求,然后进行开关门.在这里,我用了一个小技巧,就是在关门时的瞬间进行人员的进出.
UML:
复杂度分析:
这次作业我的耦合性和复杂度都比较低.
•第二次作业:
思路:第二次作业在第一次作业的基础上增加了最大载客量的限制和多部电梯的协同.
单部电梯的调度策略方面,与第一次作业相同,为了实现多部电梯的协同,我采取的是让每个电梯自己进行竞争的策略.
在获得主请求的时候,会把主请求从队列中移除,以免多个电梯同时获得一个请求,损失性能.
UML:
复杂度分析:
这次作业总复杂度比较正常,但是由于大多数工作集中在电梯线程,导致电梯类run方法的复杂度比较高.
•第三次作业
第三次作业在第二次作业的基础上将电梯进行分类,每一类有不同的载客量,运行速度和可达楼层.
在这方面,导致难度提升最大的,就是会出现换乘的情况.我的解决方法是在调度器中对每个请求进行拆分和分类,当电梯需要去请求时,返回相应类别的请求.
另外,第三次作业,还有电梯动态增加的要求,为了实现这一点,我将输入工作交给了main线程.
UML:
复杂度分析:
这次作业由于难度较高,代码的复杂度也较高.主要是涉及到请求的进出这方面的方法,复杂度都超标了.
二,bug分析
•自己的代码bug
第一次作业和第三次作业,在强测和互测中均未发现bug.
第二次作业,强测未出现bug.互测中出现了一个小bug,就是当总请求数小于电梯数时,未工作过的电梯无法退出.
•互测相关
在互测中,我没找到别人的bug
互测策略:这次没有搭出自动评测机,我采取的是构造特殊数据,如同时输入大量起始和目标楼层都相同的请求.
但是,由于数据范围的局限性和多线程的随机性,这种方法并不好.
三,心得与体会
第二单元主题是多线程.通过这一单元的学习,我熟悉了多线程的相关操作,并了解了生产者-消费者模式.但是,在写代码的过程中,还是无法有效避免死锁等线程安全问题.说明距离多线程的完全掌握,我还需继续努力.
相对于第一单元次次重构的情况,这单元我的迭代性显然更好,没有出现过较大程度的重构.在复杂度和耦合性方面,虽然还是不够好,但比第一单元有了很大的进步,这说明我对面向对象掌握的更深.