OO-Unit2总结

锁的选择

这次作业我并未使用同步块，而是统一使用的方法锁，利用语法规则进行阻塞而保证线程安全，而为了能够唤醒特定电梯，我让每一个电梯都拥有同一个类的不同对象，利用这六个实例对象的方法锁，以及自己所写的唤醒方法，和阻塞方法，实现对单一线程的阻塞和唤醒。

调度器设计

调度器我把它放在主线程中，并采用循环，逻辑是不断从请求队列中取出请求，并通过自己设计的代价计算，找出基于当前情景的优解，然后将这个请求分配给优解电梯的请求队列。而调度算法主要考虑电梯接到这个人的代价，电梯完成自己的请求的代价，电梯核载的代价，电梯速度的代价，电梯是否可捎带。

三次作业架构设计的逐步变化和未来扩展能力

hw5的架构：

hw6的架构：

hw7的架构：

未来的扩展性，由于我把request内容单独提取出来，变为一个我可自行定义修改的类person，以及elevator内部对各种运行参数的储存，单独锁的使用，以及线程数量的可增加性，对于电梯的各种特种功能具有良好的扩展性，但是不足之处在于reset的处理，这导致增加新类型reset会有较多修改，甚至有些依赖reset参数进行判断，所以这部分扩展性欠佳。

线程之间的协作关系

具体来说，就是input不断往等待队列里面塞请求，主线程里面的调度器不断取出请求，计算代价后分配给适合的电梯的等待队列，电梯的等待队列为楼层空间的模拟，可在LOOK算法下，到达某一楼层后，取出符合条件的请求，而reset会导致请求重新返回最顶层的等待队列，等待主线程里的调度器读出分配。

分析自己在第三次作业中是如何实现双轿厢的两个轿厢不碰撞的

为相应公共楼层的move设计锁，并保证每一个电梯完成作业后，不停在公共楼层。

分析自己程序出现过的bug以及自己面对多线程程序的debug方法

出现过的bug：
1.轮询。
2.胡乱加锁导致程序超时（这是我这三次作业最大的问题，甚至直到最后一次作业才反应过来，然后最后一次作业因为没有了胡乱加锁导致的程序异常卡顿，性能也拿了不错的分，但是已是为时过晚。
3.其余的都是些记不得的小bug，多是读题不仔细，或者考虑情况不周全，导致功能实现错误。
debug:
修bug只能瞪眼法和print大法，除非笃定时间不会影响这个bug的复现，不然一般不用断点调试。

心得体会

最大的心得体会是学会了灵活利用公共变量，设计恰当的锁，让线程在wake和wait间切换，保证逻辑上的串行，以及当时不太会设计块锁而取巧的利用特殊对象，达到锁和唤醒特定线程的目的。