作业策略分析
这三次作业我的架构几乎没有变动，都是一个主类，一个电梯类，一个调度器类。
电梯与电梯之间互不影响，相应的参数在生成实例的时候传入，调度器只负责给电梯发送指令，电梯只负责根据自己指令队列里的指令进行移动，调度策略统一使用最简单的look，不做任何优化。
第一次作业
公测
公测没有出现任何bug
互测
互测什么都没有发生
第二次作业
UML图
公测
公测没有出现任何bug
互测
互测什么都没有发生
第三次作业
UML图
公测
公测时CTLE，因为我写代码的时候为了最后让电梯停下来，疯狂notifyAll()，写成了一个暴力轮询。
互测
互测时候使用了队友的评测机，发现了同组很多bug，有电梯关人的，但主要还是没有停下来的。
同组的同学几乎每交一组数据我都能CTLE一次，而我在修复bug的时候因为脑残点成了非合并修复导致我出现了44个bug，原地爆炸，希望大家引以为戒。
心得体会
总的来说还是很休闲的，第一次接触了多线程，其不确定性实在是刺激，特别是我代码里还有随机的时候，bug的复现变得困难。
在架构的时候最开始一定要架构好，类之间耦合度不能太高，三个电梯我也能只用一份代码，有的同学把代码复制了三遍，这样不仅效率低而且很危险，因为一旦一个地方出问题，有三份代码都要改，很容易改漏导致出错。
以及一定要自己对代码做好分析，避免出现假的wait与notify，在windows环境下的本地测试没有找到自动测试CPU TIME的方法，如果有哪位大佬知道的话求指点QAQ。现在的方法只能是多开几个线程跑程序看CPU的利用率，如果异常的高意味着可能写出了暴力轮询。
不得不说，多线程有评测机能测试是一件非常棒的事情，感谢OO课程给我带来良好的OO体验，希望OO越来越好！