第二单元总结
第一次作业
一、设计策略
本次作业采用FAFS算法，可直接用输入线程与电梯线程交互，调度器暂时不需要参与，故一共设计三个类三线程：Main类、elevator类及input类，main线程、elevator线程及input线程。main线程负责启动另外两个线程，input线程负责读入请求并添加至elevator的队列，elevator采用while+sleep轮询，若有请求则按入队时间进行服务。dispatcher类创建但不使用，为后续作业铺垫。
二、程序分析
类图：
度量图：
时序图：
优点：结构清晰，线程各司其职，运行结果稳定，线程安全。
缺点：可复用性差。
SOLID原则：
S:单一功能原则，三个类各有一个明确功能，完成需求。
O:开放封闭原则，不满足，仅支持FAFS算法。
L:里氏替换原则，无子类设计。
I:接口分离原则，无接口设计。
D依赖倒置原则，无抽象类设计:。
三、bug分析
由于作业比较简单，没有发现bug。
第二次作业
一、设计策略
本次作业采用可捎带算法，调度器负责将输入线程的请求调度给电梯，故一共设计四个类四线程：Main类、dispatcher类、elevator类及input类，main线程、dispatcher线程、elevator线程及input线程。main线程负责启动另外三个线程，input线程负责读入请求并添加至dispatcher的inputlist队列，dispatcher队列在每次电梯到达楼层后获得电梯队列的锁，并视情况将请求调度给电梯，电梯只针对自己的队列进行运行。
二、程序分析
类图：
度量图：
时序图：
优点：结构清晰，线程各司其职，线程安全基本实现，暂未发现问题，程序可复用性显著提升，只需更改dispatcher即可更换电梯算法，电梯仅针对自身队列运行。
缺点：架构虽然较为合理，但代码实现时风格有些丑陋，性能也没有进行进一步优化。
SOLID原则：
S:单一功能原则，四个类各有一个明确功能，完成需求。
O:开放封闭原则，基本满足，第三次作业成功使用此框架。
L:里氏替换原则，无子类设计。
I:接口分离原则，无接口设计。
D依赖倒置原则，无抽象类设计:。
三、bug分析
互测时发现遗漏部分代码，导致主请求结束后不会去接等待请求，丢失部分请求。
第三次作业
一、设计策略
本次作业采用多电梯协作完成任务，调度器负责将输入线程的请求调度给三部电梯，每个电梯拥有自己的属性，故一共设计四个类四线程：Main类、dispatcher类、elevator类及input类，main线程、dispatcher线程、elevator线程及input线程。main线程负责启动另外三个线程，input线程负责读入请求并添加至dispatcher的inputlist队列，dispatcher在三个电梯均未操作队列时获取它们的状态并进行任务分配，三个电梯针对自己的队列进行运行。
二、程序分析
类图：
度量图：
时序图：
优点：实现线程安全，cpu时间占用少，架构较为合理。
缺点：算法设计粗糙，性能很差，面临修bug时dispatcher重写。
SOLID原则：
S:单一功能原则，四个类各有一个明确功能，完成需求。
O:开放封闭原则，基本满足，继承自第二次作业框架。
L:里氏替换原则，无子类设计。
I:接口分离原则，无接口设计。
D依赖倒置原则，无抽象类设计:。
三、bug分析
出现两类bug，电梯上人过多超载，以及性能过差超出最长时间，需要重写dispatcher类。
四、互测策略
还没学会搭评测机，手动测试了一些中测时个人准备的数据，并没有成功，准备尽快学习搭建自动化测试。
五、心得体会
通过本单元的学习，我深刻的领悟了线程的相关概念及应用方法，学习了使用多线程交互合作完成任务的方法。本单元最难处理的部分是线程安全，通过阅读网上的博客文章以及实例，我对synchronized的使用已经比较熟练，三次作业中均没有出现线程安全方面的bug。但是对于电梯调度算法设计偷了懒，导致第三次作业性能爆炸，遗憾之余准备好好利用bug修复机会补救，学到更多的东西。
