BUAA_OO 第二单元总结

写在前面

? 多线程(multi-threading)是指从软件或硬件上实现多个线程并发执行的技术。现代处理器普遍具有多核的特点，支持同一时间执行多个线程，使用多线程技术可以提高程序并发度，整体提高处理性能。因此掌握多线程程序设计技术是CS学习必不可少的一部分。

? 多线程程序设计包括线程协同控制、线程安全保证以及线程程序设计模式等。本文主要总结OO课程第二单元所学的有关多线程程序设计的知识，实践体会，以及技术注记，以备后用。

第五次作业

? 第五次作业实现了一个单部多线程傻瓜调度（FAFS）电梯，目的在于初步掌握JAVA语言有关多线程的语法特性，同时进行初步的可拓展的框架设计

一、类图

? 第一次作业主要是让我们初步熟悉JAVA的多线程相关语法，主要考察的知识点是简单的线程协同控制，对于其他诸如线程安全问题等没有太多要求，因此整体比较简单。

1.1 代码结构分析

? 由上述类图可以知道，整个电梯系统可以分为以下模块：

InputHandler: 指令输入管理器。负责接收指令输入，并将指令解析成PersonRequest对象，传给调度器Scheduler
Scheduler:调度器。负责接收输入管理器传入的请求，同时进行调度管理（在这次作业仅是将请求传给该单部电梯）
Elevator:电梯。负责接收调度器传入的请求，并通过一定的逻辑执行请求，具有电梯属性和行为特征（如开关门，上下楼等）
OutputHandler：信息输出器。负责信息输出。如开关门、上下楼、乘客进出等信息输出。

? 除此之外，还有与电梯系统相关的数据结构：

RequestQueue:请求队列。负责存放请求，由ConcurrentLinkedQueue实现，作为InputHandler和Scheduler、Scheduler和Elevator的共享对象存在，是线程安全类。
ElevatorConfig:电梯属性类。负责初始化电梯属性，具有拓展性。

1.2 优缺点分析

优点
- 框架简单明晰：输入管理器->调度器->电梯的大体框架较为简单易懂且易实现。
- 使用线程安全集合：使用了ConcurrentLinkedQueue线程安全队列，一定程度上简化了读-写实现，减轻了对线程不安全的考虑负担。
- 初步考虑了拓展：将电梯属性单独抽象为一个类，并尝试使用了单例模式进行获取，使电梯属性具有拓展性；在调度器中设置了一个HashMap作为调度器->电梯的映射，出于后续作业可能的多部电梯的考虑。
缺点
- 类抽象可进一步细化：Elevator类的逻辑可以进一步简化，特别是在后续作业中电梯功能进一步增多时，这一点可以帮助降低Elevator类的复杂度，降低bug出现的概率。
- 未能提前改善电梯调度算法：仅实现了傻瓜调度，效率不高；可以提前尝试ALS、C-SCAN、C-LOOK等电梯调度算法。
- 未使用wait/notify来避免无谓的轮询：仅使用了暴力轮询来完成功能，导致CPU负载较高（虽然本次作业并没有对此做出要求）。

1.3 设计原则检查

Single Responsibility Principle：类/方法的功能行为单一，符合该原则。
Open Close Principle：一定程度上考虑了可拓展性，但依照开闭原则应该进一步增加框架弹性。
Liscov Substitution Principle：无子类无继承，满足里氏替换原则。
Interface Segregation Principle：无接口设计，满足接口分离原则。
Dependency Inversion Principle：对楼层建模不够细致，需要进一步改进一满足本原则。

二、代码度量

? (度量符号说明参见注记，下面对个别新增度量进行注释)

? LOC:Lines of Code: 类/方法代码规模

? NAAC:Number of Attributes: 类属性个数

? NOAC:Number of Methods:类方法个数

? CONTROL:Number of Control statements:控制分支个数

代码统计
类度量
类复杂度度量
方法复杂度度量

类整体复杂度较低，方法整体复杂度较低。

三、UML协作图

四、Bug分析

? 在中测和强测均得到满分，暂时未发现bug

? 补充说明：（自测过程中的发现）

线程安全问题：

在本次作业的实现过程中，由于使用了ConcurrentLinkedQueue线程安全队列，以及使用暴力轮询，因此并没有显式使用synchronized或Reentranlock等JAVA锁机制来保证线程安全。由于任务简单，因此没有出现bug，但事后来看还是应该进行显式使用锁机制，一是为了避免未知不定的线程不安全，二是在可读性和代码含义上显式使用锁机制能够起标识警示作用。
测试问题：
多线程程序设计的另一大难点就是调试。由于线程执行的不确定性以及程序调试断点的特殊性（断点的设置可能会影响线程的行为），因此多线程程序的测试比单线程程序更加繁琐。

五、反思

? 第一次作业比较友好，主要是起铺垫作用，整个实现过程也比较顺利，耗时较短。同时自己也初步尝试了多线程模式进行程序设计，但整体来看对线程安全以及CPU使用考虑不够。特别是在拓展方面，其实应该提前考虑电梯调度算法，减轻后续作业的负担。不仅如此，在测试方面可以做得更好，毕竟多线程的debug没有单线程那么简单易行，涉及到时序，使用脚本对拍是一个更好的方法。

第六次作业

? 第六次作业要求实现一个单部多线程可捎带调度（ALS）电梯，目的在于进一步拓展单部电梯的功能，加强面向对象设计与并发设计训练，重点关注代码逻辑复杂情况下线程并发控制与线程安全保护。

一、类图

? 第六次作业的基本框架沿袭了第五次作业，同时针对新增的捎带功能进行了一定的拓展。

1.1 代码结构分析

? 新增了以下类：

ElevatorController：电梯控制类。封装了部分电梯执行逻辑，如返回下一楼层，返回运动方向，捎带检测等逻辑。

? 修改了以下类：

RequestPack:用于下面的楼层建模，为捎带功能服务。主要包含两个队列，一个为进入队列，一个为离开队列，对应于某个楼层。即当前在某楼层有多少要进入电梯，有多少要离开电梯的人。
Elevator：对电梯的行为进行进一步细化与拓展；增加了与捎带策略有关的数据结构，具体如下：
- RequestQueue:请求队列：与调度器共享，负责接收调度器传入的请求，需要保证线程安全。
- MainRequestQueue:主请求队列：用于存放主请求，属于对象内部变量，不需要保证线程安全。具体作用是，当请求不能被当前主请求捎带时则先加入该队列暂存。
- packMap:捎带映射Map：相当于楼层建模，key为楼层号，value为RequestPack类。

? 总体来说继承了第五次作业的代码框架，同时进行了一定的拓展，重点在于捎带功能的实现。捎带主体逻辑可以拆分成相关数据结构和相关算法：

数据结构：
- 调度器-电梯共享请求队列：沿袭了第五次作业的共享队列，调度器行为与电梯行为在该队列上与第五次作业保持不变。
- 电梯楼层map：作为楼层建模服务于捎带逻辑。具体来说，对每一有请求（进入请求、离开请求）的楼层设立进入请求队列和离开请求队列。对于某一时刻可捎带的请求，将其放入对应楼层的进入队列；对于当前楼层的进入队列请求，将其放入请求对应楼层的离开队列；电梯每运行一层，则检查当前楼层队列是否有需要处理的请求。这样可简化捎带逻辑。
- 电梯主请求队列：用于存放主请求候选请求，即是将不能由当前主请求捎带的请求放入该主请求队列中，当主请求及其捎带请求全部执行完毕后，再从该主请求队列中挑选请求作为新的主请求。
调度算法：
- 电梯捎带请求查询：每改变一次楼层，则立即扫描一次共享请求队列，将可捎带的请求放入相应楼层map，将不可捎带的请求放入主请求队列中。
- 电梯主请求设置：当主请求及其捎带请求执行完毕后，从主请求队列中挑选（未优化则是直接取队头请求）一个请求作为新的主请求，然后扫描一次共享请求队列，将可捎带的请求放入相应楼层map，将不可捎带的请求放入主请求队列中。

1.2 优缺点分析

优点
- 利用了代码的可拓展性：继承了第五次作业的代码框架，将诸如InputHandler、OutputHandler等与新增功能无关的模块重用，仅在Elevator类中增加逻辑，整体改动较少。
- 使用wait/notify代替暴力轮询：本次作业限制了CPU运行时间，因此需要使用wait/notify来实现线程间通信，同时减轻了CPU负担。
缺点
- 捎带逻辑实现略显复杂：判断是否为可行捎带请求的逻辑条件分支过多，导致debug难度增大，可读性变差。
- 未使用效率更高的调度算法：对于单电梯系统而言，捎带（ALS）算法显然不是平均意义下的较优算法，诸如C-LOOK，C-SCAN等算法可以提高电梯运行效率。

1.3 设计原则检查

Single Responsibility Principle：类/方法的功能行为单一，符合该原则。
Open Close Principle：相比第一次作业增加了拓展性，较符合开闭原则。
Liscov Substitution Principle：无子类无继承，满足里氏替换原则。
Interface Segregation Principle：无接口设计，满足接口分离原则。
Dependency Inversion Principle：对楼层进行建模，较符合本原则。