OO_第二单元总结
第一次作业
架构
我采用的是生产者-消费者模型。有一个读入线程负责读入请求并发送给调度器。用一个调度器当输入请求来临时，由调度器分配给五个楼座的电梯线程去执行运送任务
同步块和锁
输出线程：为保证TimableOutput。println()的线程安全，我创建了一个新的输出类，并对输出方法加了 synchronized锁。输出时将输出内容传给方法，保证输出线程安全
请求队列：新建了一个类PassengerList用来记录请求队列。使用synchronized方法保证进队，出队，查询人数等原子操作的独立性。该类用于输入类到调度器的请求传递，调度器分发给不同电梯的请求等。该请求队列类实用性，可扩展性强。
调度器设计和交互
我是用的加强版的ALS。基准ALS在去往主请求的出发地时不会进行同方向捎带，我把这种情况设置为捎带，实测有一定的性能优化。调度器是通过的PassengerList类与电梯线程进行交互，使用生产者与消费者模型。调度器作为生产者向队列里加入请求，电梯线程作为消费者去执行请求。
UML类图
UML协作图
第二次作业
架构
在第一次作业的基础上做了增量开发，分别增加了如下类：
- Schedule类将数据喂给每个楼座的电梯调度器，再有该调度器分发具体电梯。
- 由于楼座与楼层的电梯许多功能细节不同。故按照楼座电梯的实现方法，更改一些细节后新加入了整套楼层电梯的类
调度器设计和交互
电梯线程的调度方法沿用第一次作业的。楼座（层）调度器采用平均分配的调度策略。通过PassengerList类接收Schedule类输入的请求，再通过该类分发给不同电梯线程。
同步块和锁
本次作业迭代时不需要更改和实现新的同步块和锁
UML类图
UML协作图
第三次作业
架构
此次作业与上次不同关键在于乘客可换乘。由于乘客的路线可拆分成楼座（层）的基本路线。我通过新建乘客请求类PerRequest。在程序读入新的PersonRequest时计算最佳路线，编程PerRequest类喂给Input类。每次进入Input类以后将该请求按照当前基本路线运送。完成后更新目标基本路线后再次进入Input类，直到该请求到达最终目的地。其余调度器线程、电梯线程均不变。
调度器设计和交互
本次作业迭代时不需要更改和实现新的调度器
同步块和锁
本次作业迭代时不需要更改和实现新的同步块和锁
UML类图
UML协作图
Bug的分析与修复
- 第一次作业的输出线程不安全。
修复：便实现了一个类，所有输出均通过此类的的输出方法。并对方法加锁，保证输出线程安全。 - 第三次作业在横向电梯调度器分配给不同横向电梯时没有考虑该电梯是否对于该请求的基本路线可达，导致可能分配给一横向电梯不可运送的请求。
修复：在横向电梯调度器分配给不同横向电梯前进行进行可达性的判断
心得体会
对于生产者-消费者模型中，消费者线程的结束判断要格外注意。该模块的错误和容易导致轮询，提前结束等bug。对于本次作业最终的迭代版本更像时流水线模型。对于这种层次化设计应找到一条主线，便于理清思路。本次任务可以抓住request在整个流水线中每一步要被分配到哪作为主线，去设计流水线的每一环。c
标签：OO,总结,请求,作业,调度,楼座,电梯,线程,单元 来源： https://www.cnblogs.com/ordered-bread/p/16220067.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。