BUAA_Unit2单元总结

齐欣宇22371342 学生 2024-04-20 10:31:17

主线程启动Input输入线程，
启动Controller请求分配线程，
启动六个Elevator线程并完成初始化；
Controller接受Input的输入信息并分配给Elevator，完成输出。
其中对输入请求使用RequestQueue类进行管理
对电梯行为使用枚举类Action进行描述
对电梯策略使用Strategy类进行判断

如下UML类图：

hw6

相比于hw5，这次作业新增了reset指令
我对Reset的实现方法为：
设置一个Reset变量，若接收到Reset则赋值
当Reset!=null，标识进入reset
此时对可能的接受请求暂存在resetWait队列
同时在下一次操作时，不进行正常Action
而是将所有乘客放出，重新进入等待队列
同时重置电梯参数
reset完成后将Reset赋值null
再清空resetWait队列即可

如下UML类图，本次只新增了几个属性和方法：

hw7

对于双轿厢电梯，设想的处理方式为：
在接收到第二类重置后，对该电梯的ID进行重写，
改为“id-A”，
同时新克隆一个相同的电梯，ID为“id-B”
这两个电梯只在Type属性上不同
0代表单轿厢，-1代表下轿厢，1代表上轿厢
两轿厢共享一个RequestQueue
只在接受请求时判断谁来Receive
并且限制轿厢只在自己半区移动即可

UML协作图

调度策略

本次作业调度策略较简单
首先判断是否有空闲电梯，若有则从近到远选择合适电梯Receive
若无则选择最近且同向的电梯
若还无则随机分配

三次作业中稳定/异变的内容

稳定内容

整体框架保持稳定，同时电梯部分行为稳定

异变内容

在Strategy策略中，由于出现多轿厢和交换层，电梯行为判断策略需要发生变化
其次，电梯Reset行为是重要异变
电梯在行动时需要先判断是否Reset
最后，在Controller请求分配中，也需要加上对第二类重置的判断

同步块的设置和锁的选择

同步块的设置

在三次作业中，同步块基本都在RequestQueue类中设置，保护共享变量。

锁的选择

在Controller和Input中实现了共享变量waitRequest，对输出进行处理
在双轿厢电梯间实现共享变量requests

如何实现双轿厢不碰撞

当某个轿厢进入共享层时，对共享层属性进行设置，退出时清空
在轿厢进入共享层时先查询这个属性，若被occupied，则等待直到unoccupied

分析bug和debug方法

在本次作业中，基本未出现任何bug
但是性能方面由此牺牲很多，尚有很多优化空间

debug方法可以更多地关注异常原因
对可能产生的数据越界，空指针多留个心眼即可

心得体会

线程安全

在多线程程序中，为了实现线程安全，我们应该使用synchronize语句，对共享对象进行保护
但也要注意notify的使用防止死锁的产生
以及，synchronize块应该尽量少地使用，对并不在共享的部分不应包括，避免性能浪费

层次化设计

在本单元作业中，大致可以分为三层
第一层为支配层，也就是Controller和Input，这一层主要是完成上层操作，对请求进行处理分配
第二层为行为层，也就是Elevator，这一层主要是对请求进行响应，并完成相应输出
第三层为逻辑层，也就是Strategy和RequestQueue，这一层主要是对请求和需要进行的行动进行管理判断，并提供给行为层
三层之间保持一定的独立性，层次化设计使代码结构更加清楚，同时也方便寻找可能出现的问题

...全文