面向对象第二单元个人总结
1.第五次作业
在第五次作业中，我采用的是一个等待队列配对一个电梯的方式，设置了电梯线程和输入线程。
1.1 同步块的设置和锁的选择
对于锁的选择上，为了防止莫名其妙的问题，加上我并不太了解其他锁的方式，所以我直接采用的是方法加synchronized锁。显然这种方式会拖慢效率，因为可能只访问一个类中的某一个元素，但是却把整个类都锁住了，但是这种方法让我在电梯队列的线程安全上没遇到问题。
对于同步块的设置，因为主要产生线程安全的元素是等待队列，而只有输入线程和电梯线程会共享这个电梯的等待队列，所以我直接在等待队列类中采用方法上锁的方式。为了让电梯线程正常结束，我在队列类中设置end信号指示输入是否结束，当等待队列类中请求为空且end=ture后，电梯进程结束；否则，如果等待队列类中请求为空，执行waitInput等待后续请求/在等待队列类中的push和setEnd方法中设置notifyAll，使得电梯线程可以被唤醒。因此，当输入结束且队列为空时，可以正常结束电梯线程。
1.2 调度器设计
第五次作业的调度器，我采用的是一部电梯对应一个调度器的策略，调度器直接写在电梯线程里，并且使用look策略控制电梯运行。电梯类中进行各种判断与决策，只有获取请求、查看等待队列时调用等待队列类Container中的方法。
1.3 UML类图
1.4 UML协作图
2. 第六次作业
2.1 同步块的设置和锁的选择
这次同步块的设置和锁的选择相比于第一次基本没有改动，只是在总调度器类Scheduler的push、setEnd等与等待队列类相关方法上加上synchronized锁。
2.2 调度器的设计
这次作业的调度器我采用的是一个总的调度器+各个电梯的小调度器，总调度器分配所有请求，而小调度器负责电梯的运行策略。小调度器依旧采用look策略，总调度器则使用LRU算法在所有电梯都不空闲时，将新请求分配给最长时间没有分配过的电梯。
2.3 UML类图
2.4 UML协作图
3.第七次作业
3.1 同步块的设置和锁的选择
此次作业相比与第六次作业的主要改动在于电梯线程结束的判断上。在输入线程结束时，Secheduler并不直接调用等待队列类Container的setEnd方法，而是判断拆分后的请求是否全部完成，之后再setEnd。同时，在电梯释放乘客换乘时也会判断是否结束。Schedule类中的锁的设置不变。
3.2 调度器的设计
第七次作业的调度器形式基本相同，但总调度采用自由竞争模式，因此一栋楼共两个等待队列，一个纵向、一个横向。
3.3 UML类图
3.4 UML协作图
4.分析bug
这个单元，我在第六次作业和第七次作业中均被发现了bug。
但第五次作业性能并不是很好，因为我忘了捎带的方向不同，没有区分，而是直接获取全部请求，导致时间较长。
第六次作业强测全部正确，但互测出了问题。bug主要是横向电梯策略引起的，因为我的横向电梯是由纵向电梯改造而成，策略上未能考虑充分，并且测试不够充分，没有测试所有可能情况，导致出现电梯在两个楼座之间来回移动的情况。修复方法是重新建立策略逻辑，满足正确性需要。
第七次作业强测一个点错误，互测也出现了问题。bug主要是拆分策略导致的，一个请求同层，但当前层的横向电梯不满足要求，需要去其他层换乘时的情况未考虑到，主要还是没有充分测试导致的。
5.发现别人程序bug所采用的策略
策略：自己写代码时的错误+盲测
主要针对自己完成实验时，一些易错情况进行构造数据hack，在第五次作业和第七次作业中hack成功。
6.心得体会
这次作业，我深深认识到了做测试的重要性，尽管相比于第一单元我的测试意识有所提升，但最后仍有松懈。我希望之后的作业中我能继续锻炼自己多种情况测试能力（充分测试）
