OO第二单元总结
一、同步块的设置和锁的选择
设置同步块其实只需要搞清楚哪些资源需要共享即可。我在三次作业设置的共享资源具有同一性，均为输入类Input与调度器类Schedule之间共享的待调度请求队列waitQueue、Schedule类与电梯类Elevator之间的待处理队列processingQueue以及整个电梯系统共享的输出类Output。
为避免线程安全问题，我对上述三个共享资源的方法都加了锁，保证同一时间内只有一个线程访问加了锁的对象。而为了避免轮询，我采用了wait-notifyall的策略，其在各个作业中是如何实现的我将在第三部分详细展开。
二、调度器设置
在我的程序里，调度器起到的作用是接受来自输入类的请求，对请求进行分析，把他送往相应的电梯处理队列中，而其具体实现在三次作业里均有不同点。
hw5：由于第五次作业只有纵向电梯，请求的移动均为纵向且能一次实现，因而调度器的输入来源只有Input类，根据请求出发地所在楼座送往相应的processingQueue，是十分简单的生产者-消费者模型。同时在Input结束时，向Schedule发出结束信号，Schedule判断可以结束后再向各个电梯发出结束信号。
hw6：在第五次作业的基础上增加了横向电梯，调度器需要增加能够识别处理横向请求的能力，但由于请求的出发地和目的地要么楼座相同，要么楼层相同，请求只需一次调度便可实现。使得Schedule类的输入和输出来源与hw5基本一致，只是输出来源在细分为横向和纵向处理队列的区别。
hw7：第七次作业中请求的出发地和目的地的楼座和楼层均可不相同，请求的完成需要进行“换乘”操作。因此我在Input类里对请求进行了分解操作，把大请求分解为具有和hw6请求相同特性的N个小请求。因此调度的识别分配功能仍与hw6保持一致，但当一个大请求中的一个小请求在Elevator类里实现后，若还有小请求未处理完，需要回到Schedule类里再次接受调度，就便使得调度器的输入来源不只是Input类，还有Elevator类。在结束时调度器的结束判断条件会和前两次作业有些不同。
三、三次作业架构迭代和协作
第一次作业：
UML类图和UML时序图如下：
架构说明：
第一次作业中，我的架构里面主要有三种类型的线程，分别为输入类Input、调度器类Schedule以及电梯类Elevator，其中每个楼座的电梯都各自享有一个待处理队列processingQueue，因为有5个电梯，那么就有5个processingQueue，在Input和Schedule之间有个待调度队列waitQueue。当一个请求有Input接收后，输入到waitQueue，再由Schedule接受，Schedule对请求进行解析，把请求分配往相应的processingQueue队列中。
电梯的具体调度策略我采用了LOOK算法，原则是以电梯内及带处理队列中同方向的请求中，目的地最远的请求为主请求，在运输过程中捎带同方向的请求，因此能保证电梯在一次往返中尽可能多地处理请求。若电梯内部无请求，则电梯会以待处理队列里的第一个请求作为主请求。
同时我的电梯采用了决策和运行分离的做法。当电梯要进行下一步操作时，先向决策类提供电梯实时信息，有决策类根据电梯信息以及processingQueue状态做出下一步决策，并将其反馈给电梯类，电梯根据决策做出行为。这种做法使得整个电梯类具有很好的可扩展性，在之后的作业中若需增添新功能仅需更换决策即可。
避免轮询的方法：在这次作业中比较容易出现轮询的两种场景分别为：
（1）waitQueue为空，但Schedule仍反复访问waitQueue想获取待调度的请求。解决方法其实是若无待调度的请求，则让Schedule进入wait状态，当Input输入一个新请求或是输入结束信号时，进行notifyall操作，唤醒Schedule。
（2）processingQueue为空，但Elevator仍反复访问processingQueue想获取待处理的请求。解决方法同（1）。
第二次作业：
UML类图和UML时序图如下：
架构分析：
在第二次作业中电梯系统增加了增加电梯和横向运输乘客的功能。其中增加电梯的请求我在Input类里实现，当接收到该类型的请求时我便新开一个电梯线程，而其中会出现一个楼座会有两个及以上的电梯，因此我在同座或同层电梯之间采用自由竞争的策略，多个电梯共享一个processingQueue，每个电梯去寻找适合自己处理的请求，谁最先抢到谁就先处理。
横向电梯的调度策略不同于纵向电梯，因为横向电梯是环形电梯，周而复始，没有尽头，若采用LOOK算法会出现难以掉头的情况，因而我采用ALS算法，不考虑待处理队列中的请求，仅考虑将电梯内部的请求作为主请求，提高电梯的掉头频率。
而原电梯类Elevator我分为了横向电梯类TraElevator和纵向电梯类ProElevator，分别处理横向请求和纵向请求，但内部具体实现功能及运行机制和hw5差不多，就不细说了。
第三次作业：
UML类图和UML时序图如下：
架构分析：
第三次作业和前两次作业最大的不同应该就是电梯的“换乘”处理以及掩码的使用了，其他不同均只需在小地方改动即可。
虽然掩码看起来高大上，但由于课程组已把掩码使用公式给出，就算不会也只要照着公式使用即可。主要是“换乘”问题的解决具有多样性。而我采用的是最为保守的“静态分解”法，即在Input接受请求时便对请求进行分解，把“(atFloor == toFloor) + (atBuilding == toBuilding) == 0”的大请求分解成N个“(atFloor == toFloor) + (atBuilding == toBuilding) != 0”的小请求，且具有先后顺序，这样请求的处理机制便和第二次作业一致了。当一个大请求的一个小请求完成，若还存在小请求，大请求需返回调度器重新进行调度。
在线程结束机制方面与前两次作业略有不同，前两次作业中Schedule判断可以结束的标志是接收到来自Input的结束信号，以及waitQueue里已无待调度请求。这次作业由于调度器的输入来源新增了电梯类，还需判断电梯之后是否还存在需要调度的请求，因此我设立了两个变量preNum和finishNum来统计进入电梯系统的大请求数量和已处理的大请求数量，只有二者相等，Schedule方可结束。
横向电梯和纵向电梯的调度策略和前一次作业保持一致。
四、分析自身程序中的Bug
hw5：
在第一次作业中我强测未出现bug，互测出现了输出线程不安全的bug导致被hack。解决方法是新增一个共享输出类Output，输出方法加锁，保证每次只有一个线程调用该方法，保证线程安全性。
hw6 & hw7：
后两次作业的强测和互测均未发现bug。
五、分析自己发现别人Bug时采用的策略
（1）检查输出线程是否安全。在同一时间制造多个不同楼座的请求，看其输出的时间戳是否保证单调不减性。
（2）检查各种类型的请求处理情况。同楼层、同楼座、不同楼层楼座的请求处理情况。
（3）检查电梯之间竞争是否会导致死锁或轮询问题，在含有多个电梯的楼座或楼层加入大量随机数据。
（4）电梯的调度策略，这个主要观察代码分析+制造数据分析，寻找调度策略的漏洞。
六、新的体会
说实话，相比于第一单元拆东墙补西墙的状态，这一单元明显要从容得多，我觉得这主要归功于第一次作业的架构设计的好，每个类分工都比较明确，使得后两次作业基本不需要进行大幅度的改动，并且思路和逻辑也清晰多了。
对于线程也有了更加深入的理解，确实很多问题因为多线程的引入速度快了不少。而在线程之间的协作方面要十分清楚哪些资源共享，哪些是写操作，哪些是读操作，wait-notifyall的设计要清晰，必要时才进行notifyall操作，避免无效唤醒。
在debug方面也精进不少，掌握了多线程debug的方法，对于轮询问题可以用printf法找到反复调用的代码段，死锁问题用调试的方法解决。
以上便是我的些许收获。
