OO_第二单元总结

第一次作业

乘客的请求信息：起点层和终点层不同，起点座和终点座相同。如1-FROM-A-1-TO-A-2
思路：采用LOOK策略。若同方向上没有请求且电梯里的乘客的目的地都在反方向，则转换电梯运行方向。（捎带前往目的地与电梯运行方向相同的乘客）

UML类图

自己程序的bug

输出时间戳没递增

第二次作业

乘客的请求信息：[起点座 == 终点座] + [起点层 == 终点层] == 1，即楼座和楼层两者中有且仅有一个相同。如1-FROM-C-7-TO-A-7
思路：横向电梯的调度策略与LOOK策略类似。（优先捎带前往目的地与电梯运行方向相同的乘客，再捎带在当前层等待进入电梯的乘客）
采用自由竞争。纵向电梯加上横向电梯，总共有15种电梯。调度器根据电梯的类型分别把同类型的电梯请求分配进同一个processingQueue，再由同类型的几个电梯竞争同一个processingQueue的请求。

UML类图

自己程序的bug

终于没有bug了，高兴TvT

第三次作业

乘客的请求信息：[起点座 == 终点座] + [起点层 == 终点层] != 2，即楼座和楼层不会同时相同。如1-FROM-A-4-TO-C-3
思路：将请求分成好几段（最多三段），当完成一段请求后，就根据该请求的下一段请求信息put进相应的processingQueue，直到完成所有段则完成了一个乘客请求。
需要用Counter来记录完成的请求数量，所有的请求完成后，才结束所有电梯线程（记得notifyAll）。

UML类图

自己程序的bug

忽略了可达性问题，强测和互测都被hack烂了，快乐的时光总是那么短暂

UML协作图

同步块的设置和锁的选择

明确共享对象以及哪个线程对共享对象进行写操作，哪个线程对共享对象进行读操作，在这些操作中访问共享对象时需要加上锁，确保在同一时刻只有一个线程在访问共享资源。（使用synchronized加锁）
在第一次作业中创建了共享类对象，所以在加锁的时候，只需要在该类的方法上加上synchronized就可以了，这样方便了很多，也比较难出错。
三次作业中的共享对象都是waitQueue和processingQueue，所以在对它们俩进行操作时要多上点心。
锁与同步块中处理语句之间的关系：若线程A进入同步块获取锁后，其他线程还想要进入同步块获取同个锁是不行的，只能阻塞在外面，直到线程A退出同步块释放锁，其他线程才可以获取锁。

调度器设计

第一次作业：只有纵向电梯，所以只需要根据电梯的楼座ID调度。
第二次作业：引入了横向电梯，根据横向电梯的楼层ID或纵向电梯的楼座ID调度。
第三次作业：和第二次作业一样。

发现别人程序bug所采用的策略

用测试自己代码的数据拿去测试别人（重复利用

标签：OO,总结,请求,乘客,作业,电梯,线程,bug,单元
来源： https://www.cnblogs.com/huiqin1015/p/16218108.html