OO第二单元总结——多线程电梯

设计策略分析

电梯1：

任务：单部多线程傻瓜调度（FAFS）电梯

实现：3个线程，单例模式

Thread1:主线程

Thread2:输入处理线程

Thread3:电梯运行模拟线程

构建一个共享对象，用于put、get请求，该对象全局惟一，被Thread2和Thread3共同拥有，给该对象的方法加同步锁synchronized，以确保请求队列的安全。

经过wait、notify，使电梯和输入处理线程交替进入共享对象的临界区执行。

电梯模拟行为：从队列取一个请求，获取其fromFloor、toFloor、personId，一次只进入一个请求、将该请求完成后再进入临界区获取新的请求，当取得请求为null时，表示没有请求了，结束电梯线程。

 

电梯2：

任务：单部多线程可捎带调度（ALS）电梯

实现：整体架构与第一次没有太大变化，只是改了调度器的调度方法和电梯相应的请求处理行为

调度器主要method：

mainGet()：返回请求队列第一个元素，传给电梯，做为其主请求；

passGet()：传入电梯的当前楼层和其主请求，返回可捎带请求队列；

nobody_passGet()：传入电梯当前楼层和其主请求的fromFloor，返回电梯接主请求的途中可捎带请求（至关于一个小优化）；

电梯requestHandler()：电梯为空时，与调度器交互得到主请求，而后从当前楼层出发前往主请求的fromFloor，途中在每一层调用nobody_passGet()，在主请求进入电梯后，执行主请求，在每一层调用passGet()，而且在每一层进行判断，调整主请求为电梯乘客队列中的passger.get(0)。

 

电梯3：

任务：多部多线程智能（SS）调度电梯

实现：电梯架构依然没有太大变化，仍然是单例模式。

对于每一个电梯，采起ALS策略。

给PersonRequest添加一个bool变量canIn，true表明活跃（可进入电梯），flase表明休眠（暂时不可进入电梯），其做用为：因为特殊请求会换乘，所以调度器会将这类请求进行拆分红两条请求，前请求进入电梯，并将后请求的canIn设为false并留在请求队列，在前请求到达换乘楼层并出电梯后，激活后请求（即将后请求的canIn设为true）。

---

OO度量

电梯1：

UML

Complexity metrics

 

电梯2：

UML

Complexity metrics

 

电梯3：

UML

Complexity metrics

 

度量分析：

前两次做业的复杂度都较低，第三次做业中调度器类的总循环复杂度和平均循环复杂度都较高，用于拆分请求的方法复杂度也很高，主要缘由是该method中用了大量的多重嵌套的条件控制语句和循环。

设计原则分析：

因为没有使用接口，只继承了thread类，此处不谈LSP和ISP；

基本上三次做业基本符合SRP原则，每一个类或方法都有一个大体明确的职责，但其实还能进一步明确各方法的职责；

在第一次电梯的基础上，只需扩展调度器的调度方法，便可实现ALS调度，可见符合OCP原则；

在第三次做业中，电梯类和调度器类的交互是依赖于抽象类实现的，并无依赖于电梯类的具体对象进行交互，于是知足DIP原则。

---

分析本身程序bug

前两次做业没有bug，可是第三次做业在强测中几乎爆零，这个bug是因为思惟定式，每部电梯在每层楼都和调度器进行了交互，于是致使电梯在不能停靠的楼层进行了开关门动做，增长一条判断语句便可修复该bug。

---

分析他人程序bug

很显然，本单元因为涉及到了多线程，又因为输入的定时投放问题，传统的hack策略已经不奏效了，因此我使用评测脚原本实现定时投放，并对其结果进行自动化测试。

第一单元的做业，测试数据很容易构造，输出只有一个表达式，对于不太长的数据，基本能够经过肉眼判断其正确性，但电梯做业的输出是十分长的，尤为是第三次做业各电梯的输出相互交叉，难度更大。另外，电梯做业的bug可能很难复现，有时候评测机也会误判。

---

心得体会

本单元设计到了多线程，而多线程很重要的一点就是其线程安全，也是多线程的难点之一，经过对共享对象的方法加同步锁来实现临界区互斥，利用wait()、notifyAll()来调节线程进进入临界区的顺序，固然还有更多的互斥机制，能够弥补synchronized的一些缺点，例如高并发下会损失效率。这三次做业我都采用了单例模式，这使得个人三次做业架构基本相同。在设计层面上，尽可能符合SOLID原则，可加强代码的拓展性、复用性。这三次做业，不只使我接触了多线程，也让我对OO设计层面有了更深的理解。

---

 

最后就是，针对我第三次电梯做业大翻车的状况，告诫本身，千万不要面向数据编程！！！