一、作业分析
总得来说，我认为我在这三次作业中的构思比较清晰。三次作业都是用的是生产者消费者模式进行构造。
三次作业的结构相似，MainClass负责启动电梯线程与输入线程。controller作为模式中的传送带，负责接收请求并分配给消费者电梯，电梯及时将信息反馈给调度器。我认为这个模式思维比较清晰，并且较为简单，很适合用在这样的情景。
第五次作业
第五次设计的设计思路非常简单，电梯类和input类共享controller这个托盘。而在电梯调度方面，首先电梯在无人的情况下会先响应最近能够搭载到的乘客来服务，电梯在负载时寻路机制为选择电梯内人员最快能够到达的楼层进行服务，有点像最短作业策略。而在每到一层的时候电梯会将同一方向有需求的乘客搭载上电梯并重新计算路径。
电梯的停止策略需要判断三个条件，输入结束，调度器中所有的需求都被响应，电梯为空。如果其中一个不满足，电梯将会wait或者进行运输服务。
这次代码可以看出controller中关键的两个方法以及电梯的调度方法严重超标，复杂度非常的高。
第六次作业
第六次作业和第五次的设计思路几乎相同，调度算法也一模一样。只是这次作业出现了多个消费者，并且消费者电梯有人数上限。其中最为关键的就在于调度器的分配上。我采用的策略是需求进入调度器后，调度器通过判断各个电梯的状态来进行分配需求，判断条件为当前电梯人数与电梯已经得到的需求（即已分配但未响应的需求）之和最小。
本次由于有限制人数的要求，所以复杂度较上一次作业升高，仍然是这三个方法的复杂度较高。
第七次作业
本次作业有几个问题值得讨论：
1.首先是换成问题，我采用了消费者和托盘交互的方式，在需求到达调度器时，调度器判断是否可以直达，需要坐哪一类的电梯。在电梯类中，当一个请求进入时，判断他是否需要转乘，若需要，则寻找他最近的转乘楼层作为目的地（这就是为什么我要创建一个newpersonrequest类）并存入一个transform的数组进行保存。当一个人out的时候，检查他是否在transform队列中，将他原来的楼层去出并返回给调度器（此时这个人就是直达类型）。许多判断的方法都在transform类中实现，降低了代码的耦合度。
2.分配策略。在调度器判断他需要坐哪一类电梯之后，在这一类电梯中用第六次作业的策略进行分配。
3.电梯的停止策略。由于本次有换乘，所以上一次的策略就并不管用了，因为如果提前结束输出，电梯中有换乘的人还没有到达换乘楼层的话，其他的电梯会根据需求响应，自身电梯人数和输入结束这三个条件直接结束进程。所以我才去的方法是，电梯在其他电梯都有人的时候停止但并不结束，直到所有电梯都为空，并且输入结束，所有需求都响应的情况下一期结束进程。
代码复杂度方面，由于加入了换乘机制，所以我在判断换乘楼层，是否换乘，以及换乘电梯的几个方法中都使用了枚举的方式，这导致了代码不够简洁、复杂度较高的问题。
二、BUG分析
这三次作业出现的bug都是非常不应该的，均在电梯的停止和等待这个方面出现逻辑错误，导致小部分测试点WA。当然，代价就非常的高了。所以一定要做好充分的测试，考虑各种情况。如果可能的话建议写测评机。
但是！！！！！！！！！！！！！！！！！！！！！！！！
在第七次作业bug修复的时候出现了一个非常非常奇怪的事情：我用同一版代码提交bug修复，发现强测A的点都RE了。本以为是运气不好，结果多次提交后也出现了同样的问题。现在看来可能是强测运气好吧...而提交修改版后互测的bug基本修复，但强测的点依旧RE。我在本地无法复现时，寻求了多位同学的测评鸡结果都没有发现bug。用JProfile检查时发现CPU时间过高，基本上超过3s的点都RE了。而导致这一现象的原因就在于，我的电梯在执行wait之前会等待controller的这把锁，而controller的这把锁又会在很多其他的地方被用上，所以说就导致等这把锁的时间非常长，队列也非常长，CPU时间和内存肯定会很高。虽然不能确定这是不是最主要的原因，但我认为这是我的代码设计的不合理之处。如果可以的话应该每一部电梯都需要有自己的锁，自己wait，通过controller来notify。
吃一堑长一智，这次问题到了周六仍然没有被解决，我已经打算大改一下（比重构还痛苦）。当然，犯这样的设计性错误也和我对于多线程的理解不到位也有关系，我还需要在今后的学习中加强这方面的理解。
三、总结