OO第二单元总结

OO第二单元总结

OO第二单元总结

作业要求：

(1)总结分析三次作业中同步块的设置和锁的选择，并分析锁与同步块中处理语句直接的关系

(2)总结分析三次作业中的调度器设计，并分析调度器如何与程序中的线程进行交互

(3)从功能设计与性能设计的平衡方面，分析和总结自己第三次作业架构设计的可扩展性

画UML类图

画UML顺序图(sequence diagram)来展示线程之间的协作关系（别忘记主线程）作业

(4)分析自己程序的bug

分析未通过的公测用例和被互测发现的bug：特征、问题所在的类和方法

特别注意分析那些与线程安全相关的问题（特别要注意死锁的分析）

(5)分析自己发现别人程序bug所采用的策略

列出自己所采取的测试策略及有效性

分析自己采用了什么策略来发现线程安全相关的问题

分析本单元的测试策略与第一单元测试策略的差异之处

(6) 心得体会

从线程安全和层次化设计两个方面来梳理自己在本单元三次作业中获得的心得体会

同步块与锁

总结分析三次作业中同步块的设置和锁的选择，并分析锁与同步块中处理语句直接的关系

先给出三次作业大体上的架构：

输入线程将乘客放到unsignedRequestQueue里，表示得到了，但是未被“分配”的乘客；

调度器Schedule将乘客“分配”给每个电梯，具体操作是将Request放到和电梯共享的一个队列requestOutElevator里；

电梯将自己被分配到的Request接到内部，表示这些Request进入了电梯，然后到目的地送出去。

具体的架构如下：

第一次作业

第二次作业

第三次作业

同步块的设置和锁的选择

首先要确定哪些东西是要被共享访问的，分别是unsReqQue,reqOutElev，然后确定访问它们的对象要做哪些操作，如InputThread的add方法，Schedule的move等。对于这些要访问共享对象的方法，就要给它们加一把锁。

以第一次作业的InputThread的对unsReqQue的操作为例：

 synchronized (unsReqQue) {
    if (request == null) {
       unsReqQue.close();
       unsReqQue.notifyAll(); // wake up every thread
       return; // terminate the InputThread
     } else {
         if (arrivePattern.equals("Night")) {
            unsReqQue.addReq(request); // 不要提醒线程，
         } else {
             unsReqQue.addReq(request);
             unsReqQue.notifyAll();
         }
     }
}

好了，同步块的设置和锁的选择分析完了。

锁与同步块中处理语句的关系

同步块中的处理语句要对这个被上了锁的对象进行添加、删除或者读取，这就是锁和同步块最直接的关系。

调度器设计

总结分析三次作业中的调度器设计，并分析调度器如何与程序中的线程进行交互

调度器运行流程如下：

 lock(unsReqQue) {
    for req in unsReqQue:
        generate a strategy
        select an reqQueOutelev by strategy
        lock(reqOutElev) {
            put req into elev.reqOutElev
        }
}

调度器设计

调度器设计的关键是调度算法的设计，即select an elevator，在我的架构中，说得通俗点就是，调度器Schedule面对一个“未分配”的人，该放到哪一部电梯里，可以使得所有电梯的运行时长最小。

第一次作业非常简单，因为只有一部电梯，所以直接放里面就好了；

第二次作业我的方法并不高明，直接根据reqOutElev.size()判断，哪个电梯外面的人少就分配给谁，优点是这样较为均衡，缺点是没法结合电梯自身运行情况、电梯内部人员的属性进行判断。

第三次作业要处理换乘，我的策略是，当乘客的路线符合一定条件，那么就会触发换乘机制。为要换乘的乘客设置toFloor和nextToFloor两个成员变量，对其进行修改。修改之后，再选择reqQueOutElev进行投放。选择时，策略和第二次就一样了，挑个人少的电梯进去。

和线程交互

这是个比较简单的事情。

首先呢，在创建线程的时候，就要把共享的对象传入进去，

运行的时候呢，Schedule锁住俩队列，然后一个remove一个add就完事，

InputThread和Elevator在需要访问这些共享对象时上锁就行了。

而且在我的架构中，调度这一部分不用考虑死锁，因为Elevator对reqQueOutElev和unsReqQue的访问是分开的，没有“锁中锁”的情况。

可扩展性分析

从功能设计与性能设计的平衡方面，分析和总结自己第三次作业架构设计的可扩展性

画UML类图

画UML顺序图(sequence diagram)来展示线程之间的协作关系（别忘记主线程）作业

各种图

第一次作业

类图如下：

顺序图如下：

通过各个类之间的依赖关系，可以看到，这一次作业架构清晰，简单明了。不过电梯类十分地臃肿，因为那个调度算法十分地面向过程。

第二次作业

类图如下：

顺序图如下：

本次作业封装了PersonRequest类为MyReq类，可以实现更多的其专有功能，如判断方向等，更体现面向对象的思想，但是给它的方法太多了。

除此以外，还在InputThread中添加了新建电梯的代码，这也是作业所要求的。

第三次作业

类图如下：

顺序图（ $Sequence \ Diagram$ ）如下：

相较于上次，多了乘客换乘部分。

部分度量分析如下：

分析

让我们来看看这几个泛红的方法，它们集中在Elevator和SolveReq内部，功能是实现捎带和调度，主要问题是if-else分支太多。

我将电梯的运行分成5个部分：

调整边缘楼层方向
选择目标楼层
向目标楼层移动
放出乘客
接收乘客

最复杂的地方就是选择目标楼层，因为我自己写了一个算法来实现捎带，我需要考虑电梯内部是否为空、电梯里的人是不是往同一个方向走，电梯既能上、又能下时，怎么抉择……

为了防止考虑遗漏，所以采用了类似于遍历真值表的方式。

性能还可以，在进行了Morning、Night和Random调度策略区分的情况下，强测能拿到97分左右。

对扩展性而言，可以对调度策略，捎带策略和电梯类型进行分析。

调度策略一般般吧，就区分了Morning、Night和Random，以及专门弄了个SolveReq类进行调度，要换策略不是很难。

至于捎带策略，我自己在写完电梯的捎带算法以后，就几乎没动过，一来是算法性能尚可，二来是改动的话，还是会在Elevator里面进行修改，Elevator类的最终结果还是臃肿（虽然已经很臃肿了），所以扩展性不强。

如果有新的电梯类型加入，会导致我捎带策略的改变，这并不优雅。因为在我的架构中，Schedule保证给Elevator添加的Request的toFloor和fromFloor在电梯的停靠楼层内。电梯不关心自己可以在哪些楼层停靠。

从现在来看，将工厂模式应用到本次作业会是一个不错的选择，同时，各个电梯本身的属性也可以专门做一个迭代类来实现，这样能避免电梯类的臃肿。

所以本次作业扩展性比较差。