HW5
第五次作业是5部电梯独立的在五栋楼中运行。
5.1 UML类图
5.2 类复杂度分析
5.3 方法复杂度分析
5.4 bug & bug分析
- 输出线程不安全
在指导书中有明确指出，官方输出线程其实是不安全的，可能输出时间戳不递增，也有同学在讨论区讨论该如何解决，但是我最后忘加上了（悲
5.5 同步块和锁
第五次作业我借鉴的上机时的方法，将请求托盘RequestTray类打造成线程安全的类，里面每个方法都加上了方法锁，保证对其进行操作的时候一定线程安全的，这样在电梯上下人操作时，只需将请求托盘锁住即可，对wait和notifyall知之甚少。（为下次作业埋下伏笔）
HW6
6.1 UML类图
6.2 类复杂度分析
6.3 方法复杂度分析
6.4 bug & bug修复
- 策略 & 调度有问题
在第六次作业时一开始我还分了横向和纵向电梯的调度器，给了较为复杂的调度策略，但是强测告诉我，我的策略很有问题，在某些时候很慢，因此强测寄了一个点（哎
最终我选择重构，不用那些调度策略，选用最简单的自由竞争策略。（自由竞争真香）
6.5 同步块和锁
由于上次对wait和notifyall了解不够深入，导致这次作业一开始写完很多线程安全错误，在同学的帮助下，花了一个晚上搞懂了该如何加锁，如何将wait和notifyall搭配使用。（发现写的第一版很多时候锁的不准确，应该锁更具体的部分）
然后重构使用自由竞争后，就又去除了很多wait¬ifyall（烦死辣，白整了(；′⌒`)：因为自由竞争最大的线程安全问题都在请求托盘，而我的请求托盘是线程安全的，所以调用其方法就可以了。
HW7
7.1 UML类图
7.2 类复杂度分析
7.3 方法复杂度分析
7.4 bug & bug分析
本次无bug，但是性能失分相当于强测寄了一个点，可能因为采取的最简单的换乘策略，没有考虑最短路等算法。
7.5 同步块和锁
这次作业基本维持上次重构后自由竞争的方法，对同步块和锁没有加什么东西。
线程协作图
架构设计 & 调度器设计
这三次作业都遵循着生产者-消费者模型，都是以第一次上机时的代码为基本框架，再里面加入了一些类以满足题目需求。
第五次作业Input是生产者，Elevator是消费者，中间用一个Scheduler进行调度，调度策略极其简单：将对应楼的请求放到每一栋楼那个电梯的请求托盘。
第六次作业初版同上面，调度器新加了横向调度器和纵向调度器，其作用是根据调度策略，将每一层或每一栋里面的请求放到电梯的请求托盘中，电梯按照自己的策略运行。
第六次作业重构后和第七次作业架构一致，Input是生产者，Elevator和FlrElev是消费者，FreeComp是调度器，其作用是把输入请求放到每一层或每一栋里面的总请求托盘中，ELevator和FlrElev共享了这个总请求托盘，去竞争，看谁先接上这个请求。
总结下：老师在上课说过，调度策略是找不到最优的，你只要找个凑合着能用就行，电梯最重要的是别把人搞不见了。因此我后两次秉持着这种做法，舍弃了一开始设计复杂调度策略的思路，用最简单粗暴的自由竞争代替调度策略，调度器也就只是做简单分类任务。这样代码十分简洁，代码量应该是控制在1k行以内的（删除注释的话）；而同学自己设计调度策略，不仅费时，容易出线程安全问题，代码量还很大，有些人1k5+了。墙裂推荐自由竞争！
心得体会
第二单元我们学习了用java写有关多线程的程序，其中体会最深的就是线程安全和设计原则。
线程安全
多线程最重要的就是要保证自己的线程安全，所以书写代码时不能只按第一单元的思路，对共享对象加入或者删除时，要对其加锁；当有地方wait时，一定要在释放对应锁的地方加上notifyall；各个锁要保证其互斥......
而且由于多线程没法debug（就算把idea里面的断点设成thread也不太好de），因此静态分析代码尤为重要。这单元十分锻炼对着代码干瞪眼，也十分锻炼print debug；基本每周写完，对自己的代码是真的了如指掌。
设计原则
这单元对上课讲的设计原则SOLID应用极多。（仅写用到的）
- SRP：每个类或方法都只有一个明确的职责。比如调度器就干调度的事儿，电梯就只接受请求并运行；电梯里面的方法也各司其职：有根据look算法生成电梯下一步状态的、有上人的、有下人的......
- OCP：无需修改已有实现，而是通过扩展来增加新功能。第七次我就给requestm类新增属性，让其能记录跨楼请求究竟完成没有，而不是再维护一个队列来判断跨楼请求是否完成。
完结感言
一直听闻电梯月会很折磨，4月一开始就给自己做好了心理建设，所以感觉这个月没上个月痛苦：），起码没有熬到2、3点了，感谢助教们手下留情（拜谢）。这个月也比上个月有进步，有两次在A房了，希望下个月能都在A房~
OO，下个月见！去整OS了≧ ﹏ ≦
