单元总结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，能不能正常结束。
设计原则方面，个人觉得电梯部分代码写得还不错，在功能划分、类的封装等方面有进步。在修复时候增加功能、修改代码等的时候，并不会感觉头疼。不过总体规划还是不够。