前言
本单元作业在优化方面确实有一些想法值得分享，故单开一篇博客分享一下三次作业的优化以及架构。
三次作业的共同之处在于线程之间通讯所依赖的都是一个共享对象，采用生产者消费者模式，共享对象是单例模式。
这样做的好处是框架清晰，迭代起来往往不需要再添加很多类，改调度也是一个函数的事情:D
HW5
第一次作业是单部电梯可捎带，主体上采用的是look算法，电梯在可达楼层上下扫描，当前方向无请求则掉头，两边都无请求则等待，这里用了个小trick，开门等待，小概率能捡一些时间。共享对象“托盘”持有一个Hashmap，以楼层号为键，楼层类为值，楼层类持有上行请求和下行请求两个线程安全队列，与电梯方向相同的队列将会被查询接收请求。托盘负责接收输入线程的输送请求以及向电梯输入请求，托盘这个类的实现是线程安全的，故输入线程和电梯线程无需加锁。
HW6
第二次作业加入电梯的数量可以是1-5台，单部电梯采取的策略还是选择了沿用第一次作业的look，多部电梯每一部一个线程，除了电梯线程和输入线程外还增加了一个主调度线程MasterScheduler，负责任务的分派。
依然采取生产者消费者模式，不过这一次是两级的，输入与主调度之间有一个简单的共享对象Tray负责协调、主调度和每部电梯之间都有一个共享对象Scheduler负责协调，这个共享对象实现了子调度器接口ChiledScheduler。由于主调度器负责任务分派，因此调度函数实现在主调度器中，电梯对于请求分派不可见，只管跑就完事了。
考虑到如果有多部电梯且电梯还有容量限制，请求集中在少部分电梯上会造成忙闲不均浪费资源，因此负载均衡会取得很好的收益，所以电梯与主调度器之间还应共享一个电梯状态对象ElevatorStatus，实例化在子调度器中，调度函数依据此来分派请求，以期取得较优效率。具体来讲，就是根据实际在电梯里的人数，对应楼层已经分派的人数以及电梯获得请求后需要移动的距离作为参考条件计算惩罚值，惩罚值最小的电梯将获得此请求，这几个条件还需要加权，经历了调参之后发现电梯人数所占的比例应该稍大一些，最后取得的性能分还不错。
第二次作业uml协作图：电梯线程只管往子调度器拿人跑，故暂未列入
HW7
第三次作业最大的不同在于动态加入电梯并且有ABC三种可达楼层不相同电梯，有些请求需要电梯之间的协作才能完成。这次基调还是生产者消费者思想，受教学视频点拨，又采用了workerThreads模式，在上一次的基础上将电梯线程创建和启动放置在主调度器MasterScheduler中，同时为每部电梯实例化一个子调度器Scheduler作为“托盘”。
这次的调度还是秉承着负载均衡的原则，事先决定A类电梯作为负数楼层和15-20层之间的高速列车，B类主要负责出发地是偶数楼层的请求，C类主要负责出发地是奇数楼层的请求，当然，笔者首先在主调度器中对请求进行一定粒度的分割，让目的地在相应电梯的可达楼层范围之内，每个子调度器在上一次的基础上增加一个nextStage线程安全队列用于储存被分配到的具有依赖关系的请求，如此一来，换乘问题只需要分割请求、完成先决请求后回调另外两类子调度器（例如B类子调度器通知AC类）、进行下一阶段请求这样的系列操作就得以解决。
同类电梯之间也涉及到调度，笔者直接在子调度器复用了第二次作业的调度函数，最终达到的效果也差强人意。
第三次作业uml协作图
-
主调度器视角：主调度器与电梯线程之间只有create关系，其他联系均通过子调度器协调。
-
电梯视角：getOut的时候有callBack函数查询有无下一阶段任务
