oooo第二单元总结

王书勤-22373507 学生 2024-04-20 15:30:10

同步块与锁

可以选择对方法上锁，也可以选择对对象上锁。这里本人采用的是对方法上锁，在调用RequestTable对象的任意读写方法都用synchronized上锁，保证最多只有一个线程访问或修改读写队列。其实这个在第二次实验之后发现可以改成读写锁，但并不知道如何封装。原有的对RequestTable加锁方法对外是透明的，在其他地方不需要过多地考虑锁和同步问题，于是没改。

调度器设计

需要设计的策略细分下来应该有两种，一个是调度器如何将请求分配给电梯，另一个是电梯面对分配给自己的请求采用怎样的方式处理。

先说第二个，这个是沿用往届的LOOK算法，具体实现如下：

首先为电梯规定一个初始方向，然后电梯开始沿着该方向运动。
到达某楼层时，首先判断是否需要开门
- 如果发现电梯里有人可以出电梯（到达目的地），则开门让乘客出去；
- 如果发现该楼层中有人想上电梯，并且目的地方向和电梯方向相同，则开门让这个乘客进入。
接下来，进一步判断电梯里是否有人。如果电梯里还有人，则沿着当前方向移动到下一层。否则，检查请求队列中是否还有请求（目前其他楼层是否有乘客想要进电梯）——
- 如果请求队列不为空，且某请求的发出地是电梯"前方"的某楼层，则电梯继续沿着原来的方向运动。
- 如果请求队列不为空，且所有请求的发出地都在电梯"后方"的楼层上，或者是在该楼层有请求但是这个请求的目的地在电梯后方（因为电梯不会开门接反方向的请求），则电梯掉头并进入"判断是否需要开门"的步骤（循环实现）。
- 如果请求队列为空，且输入线程没有结束（即没有输入文件结束符），则电梯停在该楼层等待请求输入（wait）。
- 如果请求队列为空，且输入线程已经结束，则电梯线程结束。

（摘自Hyggge‘s Blog调度策略）

第一个调度器分配，其实根据题目不同会有不同的“最优”调度方法。本人调度器分配方式从调参变到均分，尝试影子电梯未遂。

第一次作业

第一次作业中，由于题目非常贴心地给出了电梯id，所以不存在调度器的说法，直接由InputHandler交给电梯即可。

UML类图

时序图

这里RequestTable又是ArrayList又是HashMap是因为一开始用ArrayList发现RTLE了，以为是数据结构问题于是改成：处理总队列的时候按照ArrayList先进先出，在电梯处理的时候按照HashMap，人在外面则以FromFloor作索引，人在电梯里则以ToFloor为索引。

bug

RTLE实际上并不是数据结构的问题，而是策略问题导致电梯在同一个楼层重复开门关门开门关门
一开始由于对多线程理解不够深刻导致出现很多次轮询……
本人自以为有效（实际完全错误）地修改了电梯策略，如果电梯是空的就不检查人的方向和电梯方向是否一致，把电梯方向改成人的方向。这样电梯跑一趟可能不能把所有人给接上，加上等待的人是用HashMap忽略了等待时间这一衡量因素，导致可能会让先来的人等很久才能被接到，所以很简单的第一次作业性能分奇低无比被分到了B房……

第二次作业

第二次作业意料之中地取消了宝宝椅，请求到来时不给指定电梯id，并且意料之外地ban掉了自由竞争，电梯必须输出Receive有明确的目标才能移动。

架构设计

本人在该作业中采用调参策略，简单来讲就是衡量各个电梯当前所在的位置、方向和容量进行评估，分配给得分最高的电梯。

主要修改及新增：

RequestTable数据结构仅保留ArrayList。
增加Person类，电梯接到Reset指令后会把人放出，此时修改Person的FromFloor属性
增加Scheduler类进行调度
Main中增加对电梯列表的管理

UML类图

时序图

bug

强测没有什么问题但在互测中被狠狠攻击了：如果在初始同时给大量相同请求，由于本人设计中未考虑电梯待处理队列的数目导致所有电梯得分会相同，默认分给一号电梯导致被挤爆。
本人的调参电梯并没有设计过多的安全保护，可能会出现调度器查询时电梯在x楼，但实际分配时电梯已经跑了的情况。当时写的时候觉得不会出现错误，只是会对性能造成影响。再加上这种情况发生概率相对较低，于是没有进行过多处理。实际上为了安全保护，可以新增一个电梯信息类，让电梯和调度器访问和修改的操作都是不可中断的。然而电梯本身会需要查询很多次且修改很多次属性，这样设计似乎又有些愚蠢。故也放弃了。
哦不对强测也有问题，没能保证先输出OUT再分配给其他电梯所以出现了WA。