BUAA-OO-2024-Unit2

[张珺强-22373215]

OO-Unit2-单元总结

第五次作业

同步块和锁

（1）在Dispatcher类的run方法中，对总体请求队列waitingList加上synchronized块。原因是输入线程和调度器线程共享waitingList，需要上锁。
（2）在Elevator类的run方法中，对电梯的乘客等候队列waitingList加上synchronized块，原因是调度器线程和本电梯线程会共享乘客等候队列waitingList，需要上锁。

调度器设计

第五次作业中调度器不是必须的，因为每位乘客都在输入时分配给了指定的电梯，不过我为了代码的可迭代性还是写了调度器类。
调度器线程与输入线程共享总体请求队列waitingList，输入线程将请求写入waitingList，调度器从waitingList读出请求。
调度策略即为从总体请求队列中逐个取出请求并分配给对应的电梯。

架构分析

UML类图

UML协作图

第六次作业

同步块和锁

新增：

（1）在Dispatch类中的调度方法中，遍历每辆电梯，并对考察的电梯的乘客等待队列加上synchronized块，原因是在调度策略执行时电梯的状态可能发生变化。
（2）在Dispatch类中的方法中加入读写锁，因为其他类在调用这些方法时会共享Dispatch类中的资源，会造成冲突。
（3）在Input类中识别到电梯reset请求后进入的分支中，把要reset的电梯的乘客等候队列加入synchronized块，原因是输入线程会修改电梯的重置状态变量，可能会与电梯的运行状态发生冲突。

调度器设计

调度器线程的设计与hw5基本相同，在Dispatch类中新增了判断一切工作结束的方法，这个方法会在每次循环中执行，若返回true就将所有电梯线程的结束状态设置为End并结束调度线程。
在调度策略上并未选择影子电梯，只根据电梯的实时状态来分配任务。在综合考虑了时间和用电量等重要影响因素后，我选择出了一种调度策略，占权重最大的参数是电梯内部的人数，其次是内部人数和等待队列人数的和，还考虑了最大容量和移速等因素，性能尚可。

架构分析

UML类图

UML协作图

第七次作业

同步块与锁

新增

（1）在新增的FloorOccupiedFlag类中，在方法上添加synchronized，以资源安全。
（2）A和对应的B电梯在尝试到达换乘层时，会尝试获取换乘层占用类FloorOccupiedFlag中方法的锁，以此确保不会相撞。
（3）对hw6中的锁进行略微修改，几乎不影响正确性。

调度器设计

调度器线程的设计与hw6基本相同。
调度策略与hw6基本相同，新增条件为不会将接不到的乘客分配给A/B电梯，因为没有意义。

架构分析

UML类图

UML协作图

稳定与易变

稳定

（1）从三次作业的迭代情况来看，我的整体架构的可迭代性较强，几乎无需修改整体架构。
（2）电梯的运行实现过程的可迭代性强，新增的需求只需要在步骤中添加，而几乎不需要修改原来的步骤。

易变

（1）调度器的调度策略进行了一次大的变化和一次小的变化，不过前者的原因是hw5根本不需要调度策略。
（2）电梯的变量和运行过程发生了较多变化，主要原因是迭代作业的新需求催生了新的状态变量，不过也与我的实现不同电梯的方法有关。
（3）输入线程在每次迭代中都会产生新的分支，是为了满足迭代作业的需求。

A/B不相撞

借鉴了评论区大神的实现方法，让配套的A/B电梯共享一个线程安全的占用类FloorOccupiedFlag，A/B电梯在尝试占用换乘层时会因调用这个类中上锁的方法而产生互斥。

bug分析

多线程bug最大的问题在于大多难以复现，因此会在运行中浪费大量的时间。

出现的bug

（1）线程不安全造成的死锁，是最常出现的bug；
（2）输出语句的位置不当，造成输出的顺序错误产生的WA；
（3）因未处理多部电梯重置时大量请求到来而产生的RTLE。

debug方法

在锁的前后加入带时间戳的输出语句，以此来判断程序执行到哪一步后卡死。

心得体会

线程安全

多线程单元对我来说是困难重重的一次挑战。在这四周的学习中，我深刻体会到线程安全的重要性，但实现线程安全的困难更是数不胜数，只有在理清每一行代码之间的关系后，才可能获得更可靠的线程安全，而更隐蔽的错误和死锁可能还藏在深处。

层次化设计

在第二单元的设计中，我又一次体会到了良好架构带来的方便之处。迭代性强的设计让我在完成新任务时省去了大量的时间，而层次化较好的设计让我对架构了如指掌，从而在修改或新增代码时可以初步预测将要发生的变化，令我收益良多。