OO第二单元总结

第一次作业：

因为电梯每次只执行一次指令，所以可以通过暴力轮询向控制器请求指令

输入线程即为控制器，接受指令，并且储存进控制器链表。

主要有三类，输入线程inputhandler和电梯线程elevator以及电梯中的乘客类innerperson

uml类图如下：

 

 写的时候线程没有停止导致运行时间一直超时。一开始用的是Array队列没有使用Concurrentlinkedqueue导致线程不安全。

第二次作业：

第二次作业禁止暴力轮询，所以虽然整体上还是上面的策略，但是还是做了些改变。

输入线程中对访问待执行命令的链表的访问进行了锁定，如果链表为空，电梯进程就进入阻塞态。

电梯的捎带则是在每次到达新的楼层先进行是否有下电梯的人，然后再判断是否有人需要上电梯。

若有人需要上电梯则进入电梯，若已到达目的楼层则选择一个同向toFloor楼层作为目的楼层，若没有，则选择第一个反向toFloor作为目的楼层

UML类图如下：

本次作业类的设计上和上次作业基本相同

度量分析：

第二次作业其实跟第一次作业没什么很大的区别，主要难点就是一个捎带功能。在写的时候没有注意不能暴力轮询导致浪费了很多时间查找错误。

第三次作业：

该次作业与前两次作业的不同点主要有以下几点：

一是每部电梯的速度不同，二是电梯停靠楼层不同，三是有些用户请求不能被任何一个单电梯执行，要考虑换乘的问题。

我的设计思路是尽可能使乘客不需要换乘，且换乘的路线最近。如果电梯不换乘就到达，则将乘客分配给这部电梯。

乘客换乘最多换乘两次。优先分配给速度快的电梯。加入一个TransPerson类用来记录需要换乘的乘客

UML类图：

复杂度分析：

复杂度最大的方法是判断是判断目的楼层和判断是否需要开关门。

本次作业的代码量比上次增加一倍左右

这次作业加深了我对wait和notify的理解，前两次作业对wait和notify一知半解导致刚开始写时出现了很多线程同步的bug

总结：

因为是多线程，并且输入输出都是与时间有关，所以debug的难度比较高。我所使用的调度算法都还不是很智能，需要进一步优化。每次作业都会在上一次作业的基础上细化成员和方法，通过这几次作业，学到了很多设计多线程的思想，比如如何避免死锁、生产者-消费者思想、one to workers等思想。通过这些能够快速构建出线程安全的多线程程序。但是在锁的用法上和多线程的方法上，我还是有一些不太明白的地方需要进一步学习。