一、从多线程的协同和同步控制方面，分析总结三次作业的设计策略
第一次作业
多线程的协同：
本次作业采用生产者-消费者模式进行设计，搭建了主线程、电梯线程以及请求队列。
本次作业没有搭建调度器。一部电梯调度个锤子。
主线程读取请求后，直接将请求放入请求队列，电梯线程从请求队列中读取请求并执行，主线程读取请求结束后，电梯线程处理完所有请求自动结束。
多线程的同步控制：
请求队列作为主线程和电梯线程的共享对象，设计为线程安全的，使用 synchronized 关键字进行方法级的同步控制。
第二次作业
多线程的协同：
本次作业在第一次作业的基础上新增调度器，且并未将其设计为线程。调度器负责请求向若干个电梯的分配。
多线程的同步控制：
与第一次作业相同。
第三次作业
多线程的协同：
本次作业涉及电梯种类不同，因此将多部同种电梯和相应的调度器（沿袭第二次作业）封装为一个电梯子系统，同时新增一个主调度器负责请求向若干个电梯子系统的分配。
多线程的同步控制：
电梯子系统的同步控制细节与第二次作业相同。
考虑到新增的主调度器处理的请求来自两方面——主线程读取、子系统上传（人员换乘），因此需要设计为线程安全的，使用 synchronized 关键字进行方法级的同步控制。
二、从功能设计与性能设计的平衡方面，分析和总结自己第三次作业架构设计的可扩展性
功能设计：
第三次作业为多部多线程可稍带调度电梯。
性能设计：
单部电梯，采用 LOOK 算法进行调度。
多部电梯，调度器分析每部电梯由当前所在位置运行至乘客所在位置耗时，并依此作为请求分配依据。由于电梯运动方向何时更改未知，当电梯内无乘客，且电梯运行方向上的更高楼层无乘客等候时，电梯则会更改运动方向，因此仅计算最坏情况（电梯运行至顶层或底层才掉头）下的接客耗时。当多部电梯的接客耗时差别不大时，调度器采取随机分配策略，以保证电梯负载均衡。
人员换乘方面，固定换乘楼层（1/5/15），固定换乘次数（1）。
总体而言，可扩展性一般，针对电梯种类而言，可扩展性较好，针对电梯可达楼层而言，可扩展性一般。
三、度量分析
第一次作业：
方法复杂度：
代码行数：
类图：
第二次作业：
方法复杂度：
代码行数：
类图：
第三次作业：
方法复杂度：
代码行数：
类图：
四、分析自己程序的bug
三次作业在强测和互测中均未发现bug。
五、分析自己发现别人程序bug所采用的策略
由于本人没有评测机，且懒，因此在互测中基本处于隐形状态。人不犯我我不犯人。
六、心得体会