OO Unit2 单元总结

[尹祺霖-22371157]

OO Unit2单元总结

总架构图

生产者-消费者模式

时序图

同步块的设置和锁的选择

hw5

在hw5中，我都是对于方法上锁，对RequestTable类的所有方法都上了锁，RequestTable类是请求的集合，也就是生产者和调度器，调度器和消费者唯一的共享对象类，对于这个类的所有方法上锁可以保障线程安全问题的解决。

hw6

在hw6中，我依然保持了hw5中对于RequestTable上的锁，并且对于hw6中增加的一个receiveResetRequest的方法用于把reset的电梯的里面的人和配给他但是没有去接的人放给主请求队列，初次之外，我对Elevator中的一个表示是否在reset状态的变量isReset的get和set方法进行了加锁，这个变量是调度器和电梯共享的变量，都是可读可写所以要加锁。

hw7

在hw7中，对于DCReset的加锁方式类比于hw6，对于双轿厢电梯我的处理方法是把当下的电梯变成一个调度器，然后新增A和B轿厢，AB轿厢的实现和加锁也类比于总调度器和普通电梯。

而对于双轿厢电梯不相撞的要求，我让两个线程共享了一个isInChangeFloor的类对象，对他的方法加锁，并且在AB轿厢的move（）中加锁保障了线程安全来保障双轿厢不会相撞。

调度器与线程互动

调度器和线程进行互动的方法是通过共享对象RequestTable，也就是调度器分配给这个电梯线程的任务。通过对于

调度器设计与调度策略

在hw5中，由于指定了上的电梯，所以调度器不包含调度算法，他起的作用仅仅是把请求放到对应的和电梯的共享对象里。

在hw6中，需要我们自己设计调度算法来分配，并且由于增加了重置功能，所以我们不能给正在重置的电梯分配任务，我才用的是均匀调度，也就是i%6来进行分配,在保证了正确性的前提下是90分左右。均匀调度比较好的一点就是不会给一个电梯过多任务。并且如果看到有5个电梯在重置的话调度器线程就会睡1.2s,牺牲了一点性能来换取正确性。

在hw7中，我依然采用了均匀调度，并且无论是第一种还是第二种重置的电梯我都不会分配请求，也就是对于第二种重置的处理类似于第一种重置。而且由于双轿厢电梯有耗电量优势以及上下可以同时动的优势，我选择双轿厢只有1个任务和没有任务时优先分配给它。保障了正确性的情况下性能分也是90分左右。

稳定与易变内容

稳定的内容包含：

Main方法

Strategy：提供电梯建议，也就是LOOK调度算法，基本没变，hw7单独为AB轿厢提供了调度算法，根据LOOK算法简单修改而得。显然比较稳定。

易变的内容包含：

InputThread的run里面需要根据jar包接口的变化来微调，整体变化较小。

Elevator的run：增加一种reset之后需要微调。

调度器中的run：需要修改调度方法

bug与debug方法

hw5：hw5强测没有bug，但是初次写完后发现有CTLE，debug的方法是在可能的轮询的地方输出一下，如果出现了很多次（上千）的该输出，则说明了该地方轮询，解决方法是wait，notify。

hw6：hw6强测没有bug但是互测有一个bug，就是卡49s导致把所有请求都分配给了一个电梯导致了RTLE，解决方法是调度器遇到了5个电梯都在reset的话就sleep 1.2s，虽然牺牲了一些性能但是保障了正确性。

hw7：hw7强测和互测都没有bug。

心得与体会

在第二单元中，我们系统学习了多线程，其中重点就是线程安全问题，在hw6和hw7中也对这个问题很头疼，总的来说是看线程对于的共享对象是可读的，还是可写的，亦或是都有，是否有读写的先后顺序，而加锁又包含了对于对象加锁和对于方法加锁，对于对象加锁的话则需要覆盖对于这个对象的查找和修改操作，对于方法加锁是简洁明了的，也是和最近OS中学到的管程呼应了起来，相比于上个单元，这个单元的表现好了很多，也达成了上个单元总结中给自己指定的目标，感觉OO的学习逐渐进入了状态。下个单元给自己定的目标是多多考虑性能的优化。OO长征路已然走完了一半，革命胜利曙光就在前方，加油！