BUAA_OO_第二单元总结
锁统一选择了sycronized，同步块设置在了三个地方。
第一个是放在了queue这个共享对象里边，以此来保证线程安全。
第二个是输出类output里面，以此来保证输出线程安全。
第三个是全局调器类里面。
同步块中处理语句都是被多个线程共同访问的。
(2)总结分析三次作业中的调度器设计，并分析调度器如何与程序中的线程进行交互
本次作业直到第三次才真正加入了调度器，存储的信息主要有不同楼层，不同楼座的电梯以及相应队列。承担了在程序一开始创建并运行电梯，以及得到加入电梯请求时创建并运行电梯的任务。也承担了将请求分派给不同楼层和楼座的队列的任务。
在楼层与楼座内部，由于采用的是自由竞争模式，请求队列就相当于调度器，电梯本身采用主请求驱动的look算法，当一个方向的look结束而且电梯里没有乘客时，就会访问队列来获取下一个阶段的运行方向。
调度器作为一个超级共享资源，内部的方法肯定要加上sycronized
调度器为单例模式，通过getInstance()来实现与外界的交互，无论在程序的什么地方，都可以访问到调度器。
具体的交互有InputThread类会向其中加入请求和加入电梯，elevator类会向其中加入请求，elevator和queue类会访问它的电梯信息。
(3)结合线程协同的架构模式（如流水线架构），分析和总结自己
-
三次作业架构设计的逐步变化和未来扩展能力画UML类图
-
画UML协作图(sequence diagram)来展示线程之间的协作关系（别忘记主线程）
第一次作业
本次作业逻辑比较简单，共享资源只有RequestQueue，运行的线程是Elevator与InputThread还有主线程，Elevator与InputThread线程交替访问这一个共享资源，在Elevator和RequestQueue内部，为了优化（虽然后来发现几乎不起作用），抽离出了ArriveTable与WaitTable两个类，内部使用树状数组来实现。建立了一个Passenger类，请求进入电梯之后就转化成了一个乘客，乘客可以根据楼层来决定自己是否下楼，也保留了自己目的楼层的信息。个人感觉是很好用的，感觉一是比较符合人的思维，二是省去了请求很多不必要的信息存储，比如出发地点。
与此同时，为了输出安全，也建立了一个Output类。
第二次作业
如果采用自由竞争的策略的话，横向电梯就是纵向电梯的镜像，因为不能中转，所以横向电梯和纵向电梯之间没有关联，所以可以完全模仿纵向电梯的模式来构建横向电梯。
对于多部电梯的问题，为每个电梯分配一个请求队列，通过合理分析进行有针对性的调配，固然不失为一种很好的思想，但是优先的时间和精力导致这往往是事与愿违，我们很难想出一个策略保证一切都是完美的，甚至很难想出一个策略保证一切都是较好的，所以为每个楼座建立一个请求队列，各个电梯平权竞争，是权宜之下的最好选择。
第三次作业
本次作业是这一单元最难的一部分了，中转电梯是第一个难点，一个中央调度器在所难免，因为一个请求无法在一步完成，所以需要多次进入请求队列。这比较别扭，主要由于自己真的不愿意实现为每个楼座的每一层建立一个请求队列，现在看来有了中央处理器之后这并不难，而且这似乎是一个很不错，用起来很方便的模式（和现实很像）。因为我没有建立，所以我只能在每一次Elevator类outPassengers时进行一次判断，如果已经到达目的地，那么就此结束，如果没有，就返还给中央处理器，进行二次分配。
第二个部分是可达性问题，个人感觉这个比较反人类，电梯怎么还有能不能开门（bushi），所以这一个呢最好是专门找一种一劳永逸的处理方式来处理，这个不止对于电梯能否开门有影响，也对于电梯可不可以完成某个请求有影响，所以就对于judgeIfStop与inPassengers有影响。（自己就是没考虑inPassengers有影响错的）
协作图如下
(4)分析自己程序的bug，分析自己发现别人程序bug所采用的策略
几次互测中都没有去发现别人的bug，自己在第一次作业中有一个输出线程不安全的bug，在第三次作业中在乘客进入时没有判断可达性，导致会有电梯装满人之后来回走但是放不下人。
(6) 心得体会
从线程安全和层次化设计两个方面来梳理自己在本单元三次作业中获得的心得体会
首先是对于线程安全，线程安全只存在于被共享的资源，而且线程安全并不干涉正常的编程，比如如果一个sycronized方法里出现了可以抽取出来作为一个新的函数的部分，那么这一部分可以正常抽离出来，加上sycronized，完全没有问题，不会出现感觉上可能出现的死锁。
其次是层次化设计，层次化设计是一个永恒的主题，本次作业中秉持着一切从简的原则，没有设置过多的类，一个电梯类，一个队列类，构成了程序的基本骨架。在第三次作业中，为了更好的实现中转功能，设置了中央调度器类。感觉好的架构没有所谓的标准答案，个人感觉能被自己理解，能完成任务要求的基础上，尽可能的简洁的架构，就是一个好的架构。
