OO unit2 总结

21231110-司亦菲 2024-04-20 17:12:50

一、同步块的设置和锁的选择

对这些内容的了解较少，仅用了synchronized锁。

public synchronized void method() {
 // code
}

二、架构设计

沿用了实验的架构与设计，其中InputThread类、MainClass类、Requst类、RequestQueue类、Schedule类均改自（去年）实验代码，只有Process类几乎完全不同。

调度器设计与调度策略

在hw5、hw6中，主要用了随机均匀分配的方式，通过一个生成1--6之间随机数的函数，将所有乘客随机分配到六部电梯中，由于随机数生成概率近似是平均的，所以可以认为是均匀分配。对于hw6中因维修而送出的乘客，将其看做新的乘客继续分配。

对一部电梯中的几名乘客，将第一名乘客，也就是接受到的第一条请求看做主体，将其起点和终点看做电梯此次运行的起点和终点，在此过程中，若电梯未满&&经过新请求的起点，则将新请求加入电梯，若经过某电梯内请求的终点，则将其移出。运行到终点，即主体下电梯后，将第二条请求看做主体，重复该过程。

优点：

该分配方式的代码量较少，实现简单

因为在电梯开始接送乘客前就已经进行分配，不会出现由于编程逻辑疏漏而导致的乘客无人接应的情况。

人梯对应，避免多部电梯抢一个人的情况发生，耗电量小。

缺点：

由于硬性要求每名乘客必须等待特定电梯，乘客等待时间较长，运行时间较长，易超时。

可扩展性不佳，当Hw7加入电梯可达性之后就不太能满足要求。

效率低，性能较差。

一些问题

该分配方式在hw7中遇到了不少问题，由于对开门数量的限制，再加上有的乘客必须换乘，这个简单粗暴的分配方式有些难以招架。后期实在难以解决这个问题，试图对代码进行重构，采用研讨课中同学分享的自由竞争方法，但最终也没能成功。

UML协作图

三、bug分析

最初感觉随机均匀分配的方法是个简单粗暴的好写方法，因此忽视了很多细节。

最典型，也最傻的一个问题是下电梯问题。比如，一部电梯中有3名乘客，第一名乘客，即主体的请求为2-----8，第二名乘客的请求为3----9，第三名乘客的请求为4--6，那么在以2——8为主体的运行过程中，第三名乘客是可以下电梯的，但我并没有一个方法让他下去，接着在第二名乘客的回合也没有让他下去，直到他自己的回合才成功下电梯。这对等待时间、运行时间和耗电量都有很大负担，导致一直超时，后来才发现这个问题。

还有一个问题是结束条件，最初设置的结束条件是“所有电梯都没有乘客”，但最终无法结束。后来经过反复尝试，将结束条件最终完善为“所有输入结束&&请求队列为空&&所有电梯都没有乘客”。