BUAA OO 第二单元总结

一.同步块设置和锁的选择

• 第五次作业

  在这次作业中，我创建了RequestQueue类负责存储需求队列，并在每处需要用到RequestQueue类的地方都给RequestQueue类上了锁，但也因此造成强测零分的结果。

• 第六次作业

  在此次作业中，我吸取了上次作业的经验，将RequestQueue存在Scheduler类中，并锁换成了Scheduler类中对方法的同步。如此就可以很大程度上避免多部电梯调用一个方法导致RequestQueue的更新不及时。

• 第七次作业

  与第六次作业的设置相同。

二.调度器设计

• 第五次作业

  在第五次作业中，调度器和电梯功能没有区分分明，调度器接收RequestQueue，同时保存电梯所有的参数，在电梯每进一层时都调用一次调度器来判断是否需要出入乘客，以及判断主需求，同时又由电梯来判断方向。可以说电梯和调度器的功能混淆，导致这两个类都比较复杂。

• 第六次作业

  在第六次作业中，我将电梯和调度器的功能区分开，电梯负责传递参数给调度器，由调度器分析方向，进出人等。调度器内部也不保留电梯的参数，只对接收的参数进行分析判断，输出相应的出入人队列供给电梯，这是为了避免多个电梯同时运行导致的混乱。

• 第七次作业

  与第六次作业相似，只是在一些方法中多添加了读入电梯内部人数上限进行判断，并没有换乘的分析。

三.分析第三次作业架构

我的第三次作业主要分为电梯，调度器，输入生产者，可选楼层这几类。

对于调度算法，我选择了look算法，让电梯在无人时向有人的方向运行，在有人后顺路接上同方向的人，让几个电梯进行自由竞争。

这次的可拓展性还是比较好的，因为第三次作业本身就是在第二次作业的基础上稍加改进便完成了，由于策略类的分析与电梯内部参数是完全分离的，因此每次变动都只需要为策略类的方法增添参数和为电梯传入参数。

 

 

 

 

四.分析BUG

在第五次作业中，强测阶段出现了电梯在错误的楼层出入人的错误。根据对策略类内同步锁的分析，发现是由于锁加的太多导致死锁的出现。

在第六次作业中，强测阶段出现了电梯楼层超出范围以及电梯运行时间过长的错误，对于前一个问题，依旧是因为我在第五次作业后更改了同步锁添加的策略，将对RequestQueue的锁改成了对Scheduler的方法的锁，由于将所有Scheduler的方法都上了锁，因此导致死锁的出现。而电梯运行时间过长的问题则比较有随机性，在多提交了几次后就在规定时间内送完了乘客。

第七次作业由于沿用了改进后的第六次作业的程序，因此没有出现BUG。

五.分析发现别人程序BUG的策略

在这一单元中我没有找到一处其他人的BUG，主要原因是多线程的高压测试环境在本地不容易模拟，同时就算找到了BUG提交后也有可能会因为随机性而通过，这种吃力不讨好的事我在尝试了几次后就放弃了。

六.心得体会

• 线程安全

  对于线程安全的概念在我做前两次作业时没有理解的很透彻，基本是在所有要调用同一个对象的地方都加了锁，从而导致了许多次死锁的发生。但在第二次作业的DEBUG阶段我认真复习了理论课的知识，并理解了同步的概念，从而减去了不必要的锁，让电梯成功通过强测。

• 层次化设计

  在第五次作业中，我的层次化设计还不完善，主要原因是电梯功能和调度器功能的重叠，同时调度器中又保存着电梯的参数，导致电梯除了输出和判断方向外可有可无。

  但在第六次作业后，我将电梯和调度器完全区分开，调度器中包含需求队列，电梯中包含调度器，多个电梯共用一个调度器，让调度器通过电梯传入的参数独立判断各个电梯的状态，方向，进出队列。