OO第二次单元总结

单元总结2

作业介绍

项目	内容
作业内容	多线程电梯

作业正文

从多线程的协同和同步控制方面，分析和总结自己三次作业的设计策略

第一次作业原本的设计是look算法，用自己理解的方式写了多线程控制。但是交上去发现rtle和ctle。最后选择了使用了官方文档生产者与消费者模型，一个请求一个处理，FCFS通过了。修复时候采用了look算法，可以进多个人，效果不错。只有在get时暂时没有等待电梯的人的时候，电梯线程才会暂停。生产者一直put，put以后notifyall。

第二次一开始使用FCFS秒杀了中测。让消费者线程互相之间竞争。在修复阶段想对第二次作业修改，把托盘从一个请求改为了arraylist，但还是有两个点没过，因为我电梯的人数一直是1；

第三次电梯增加了调度器。因为有3-6个消费者，类型各不相同，所以我让电梯集中从调度器里面get请求，但是调度器内部请求时分为三部分的。生产者put的时候就根据from楼层将请求分为ABC三类。线程结束是根据三个条件（请求输入结束、电梯外请求清空、电梯内请求清空）在处理电梯内请求的时候，因为需要换乘，所以一个电梯处理完一个请求可能会增加一个电梯外的请求，所以必须三个条件都满足才可以结束线程。

从功能设计与性能设计的平衡方面，分析和总结自己第三次作业架构设计的可扩展性

1、电梯内目前只能有一个乘客，还可以扩容。

2、增加乘客位置以后可以增加捎带，针对电梯特点进行调度优化。

基于度量来分析自己的程序结构

以第三次作业为例分析。

作业3

类图
第一次用diagram，还不太会。

分析自己程序的bug

共性问题：效率太低。

作业1 修复后Look算法效率还行。

作业2 电梯内只能有一个乘客。

作业3 电梯内只能有一个乘客。

分析自己发现别人程序bug所采用的策略

依然是根据当前的要求设计特殊情况的测试用例。并未根据代码设计测试用例。

特殊情况包括同时大量请求、请求中包含电梯增加请求、特殊楼层

通过修改生产者类来手动增加请求，如下

waiting.add(new Request(1,1,2))

说实话很慢效率很低。

对比和心得体会

电梯相比求导，在作业有效性的难度上有所降低。

线程安全需要注意状态控制，什么时候wait，由谁notify，能不能正常结束。

设计原则方面，个人觉得电梯部分代码写得还不错，在功能划分、类的封装等方面有进步。在修复时候增加功能、修改代码等的时候，并不会感觉头疼。不过总体规划还是不够。