总结分析三次作业中同步块的设置和锁的选择，并分析锁与同步块中处理语句之间的关系
三次作业中，我都把同步块放在队列类和输出类中，其他地方没有锁或同步块。这样缩小了同步的范围，降低出现同步BUG的概率。
进入同步块相当于获得锁，退出同步块相当于释放锁，但使用锁更灵活，可以自由控制获得和释放锁的时机，而不用和代码块结合。
总结分析三次作业中的调度器设计，并分析调度器如何与程序中的线程进行交互
三次作业中，我的调度策略都是各电梯自由竞争请求，各电梯从队列中移除处理的请求。输入线程（主线程）只负责将请求放入对应的队列（楼层、楼座）。
调度器向队列中放入请求时，唤醒所有等待在这个队列上的线程。
结合线程协同的架构模式（如流水线架构），分析和总结自己
三次作业架构设计的逐步变化和未来扩展能力画UML类图
画UML协作图(sequence diagram)来展示线程之间的协作关系
分析自己程序的bug
在评测和互测中均没有测出BUG，但在强测开始前与同学交流时发现一种罕见情况，会导致在某些情况下处理完所有请求且输入结束时程序不能结束。
原因是等待队列中被放入请求的函数的返回不对，导致电梯线程提前退出。而主线程退出条件为：输入结束后，所有电梯线程均处于等待状态。退出的电梯线程不属于等待状态，于是主线程不退出。
改正队列类的返回值之后修复了BUG。
分析自己发现别人程序bug所采用的策略
阅读代码，观察各种判断条件，寻找可能出BUG的情况。
心得体会
要注意一些重要的判断条件，在程序变化了之后，原来的条件可能不再适用。比如我的电梯线程退出条件之前是等待之后队列空，但在多个线程等待时，一个线程等待之后，队列可能已经被其他线程拿空了，于是错误地退出。
