oo第二单元的自白

电梯第一次作业

第一次电梯较为简单，主要目的在于初步接触多线程，可以实现一些简单的操作。

在本次作业中，为了更好的了解多线程，我也阅读了一些代码，并据此仿写完成了第一次作业。

根据生产者和消费者的模式，读入线程即为生产者，电梯与调度器一起为消费者。仓库的容量为1，故两线程相互进行等待（这主要是没有真正的理解其原理，而迫不得已的仿写）。

电梯第二次作业

第二次作业的构造大体与前相同，不过没有开新的线程进行读入处理，而是直接在main方法中进行。

实际调度类似于scanner，但却又比其差了一些。

（其实，我是按照指导书提供的想法进行实现。但我的理解和别人不大一样，当电梯中有人时，即将电梯中第一个进入的人的请求作为主请求，电梯无人，将第一个等待的人的请求作为主请求，而一旦有人进出电梯，立即进行一次主请求的刷新。）

电梯第三次作业

 

 

本次作业最重要的一个问题就是如何进行电梯间的通信（多电梯完成一个request时）和有效的利用电梯资源（优化）。

在此，我进行的处理是，将scheduler作为一个共享的对象，其内的成员变量为三个list，分别对应于三部电梯。

将需要多个电梯完成的任务进行拆分，在人为到达时，将list中的有效位置为false，当人到达中转站时，置为true。

 

三次作业中的问题与一些想法

第一次作业作为入门，几乎完全照抄生产者与消费者模式。

第二次作业，有了第一次的基础后，又理解了一些内容，进行了改进。

1.将读入方法归入到main中

2.仓库容量从1改为无穷大，即删除了读入方法中的wait，由接口提供的阻塞方法来完成wait。

3.第一次作业直接使用synchronized包装run方法，第二次将新写的共享对象类中的方法进行synchronized包装，减小了包装的大小。

第三次作业，实际上大体思路延续第二次，但又有一些问题。

1.在自己课下debug的过程中，发现了电梯停不下来的情况，经过反反复复的debug，发现是关于暂停信息的设置出现了问题。在读入为空时，将唤醒电梯，随后设置结束信号为真。（这实际上就是和第二次作业一模一样的，所以第二次作业存在着问题，只是没有被发现，或者说出现的概率极低）将其更改为先设置结束信号为真，再唤醒电梯即可。

2.关于强测中的炸点问题，出现原因是存在隐式小轮询，第二部电梯会在中转楼层反复判断该请求id是否到达，添加了wait和notify即可解决。

3.关于run方法过长，应该考虑将run中内容打包为方法，在run中直接进行调用即可。

4.关于优化，最初的设想中，将所有可以达成该目的的调度方法分别对用存入到三台电梯各自的请求队列里，但实际情况极为复杂，例如3到-2，包含了C转A和C转B两种情况，在中弱测中，我的调度会将该id进行两次的入电梯C，想要继续进行修改过于复杂，而且即便进行修改，又不知是否会有其他的错误出现，在时间不足的情况下，只好修改为每个id仅有唯一的乘电梯方式。同时，这也告诉了我，在写代码前，一定要有严格的设计，可以减少时间。