OO第二单元总结

第二单元总结

• 锁和同步块

主要利用了synchronized锁和Controller调度器解决线程数据冲突问题.

本次作业由于直接将人分配到楼座且一个楼座仅有一个电梯就无需考虑删除人时的读写冲突.

• 调度器设计

controller内部掌管NewMainBuiding类包含了所有楼座的信息,通过getWaiting和getFloorWaiting来获取相应楼座的等待队列和想要楼座指定楼层的等待队列,电梯每接到一个人便将该人信息从调度器队列中删除转移到电梯队列当中,当调度器队列为空且输入停止且电梯当前没有任务即线程终止

第五次作业

代码架构:生产者模型

1. 单独一个线程InputHandler用来接收输入数据.

2. 设立共用调度器Controller用来作为缓冲区对数据进行操作.

3. 电梯elevator作为消费者模型用来向调度器发出指令处理数据.

调度算法:半优化ALS算法

即不仅携带与主请求目的地同方向的乘客,且携带能够在接主请求途中完成到达请求的乘客

类图:

bug修复:

本次作业未发现bug.

• 锁和同步块

主要利用了synchronized锁和Controller调度器解决线程数据冲突问题.

本次作业由于有多个电梯竞争需要考虑删除人时的读写冲突所以将电梯接受人对于缓冲区的操作都挪到了Controller调度器中.

• 调度器设计

controller内部掌管NewMainBuiding类包含了所有楼座的信息,通过getWaiting和getFloorWaiting来获取相应楼座的等待队列和想要楼座指定楼层的等待队列,电梯每接到一个人便将该人信息从调度器队列中删除转移到电梯队列当中,当调度器队列为空且输入停止且电梯当前没有任务即线程终止.

第六次作业

代码架构变化

1. 由于本次作业新增了横向电梯以及会出现增加电梯的请求,所以对Controller进行了改动

2. 按理说应该使用工厂模式将横向电梯和竖向电梯分开,但为了防止一些隐藏的bug,所以我将两类电梯通过type分开在elevator的方法类重定义了两类电梯的运行方式.

调度算法:自由竞争

即一起去接主请求谁先接到主请求则主请求归谁

类图:

bug修复:

修复了横向电梯由于休眠后接人未更换主请求导致电梯无方向把人锁在电梯里的bug.

• 锁和同步块

主要利用了synchronized锁和Controller调度器解决线程数据冲突问题.

本次作业对于同步块的方法类无改变,但Controller调度器对于终止进程的条件发生改变.

• 调度器设计

controller内部掌管NewMainBuiding类包含了所有楼座的信息,通过getWaiting和getFloorWaiting来获取相应楼座的等待队列和想要楼座指定楼层的等待队列,电梯每接到一个人便将该人信息从调度器队列中删除转移到电梯队列当中,当调度器队列为空且输入停止且所有电梯为空即线程终止.

第七次作业

代码架构变化

1.新主楼增加一个int数组用来储存哪一层拥有横向电梯.

2.人员下电梯时检测是否到达目的地,未到达则更新人员信息添加回新主楼中等待下一次运送.

3.判断停止条件更新为新主楼为空且所有电梯为空

4.canOut和canBring的判断条件有所更改

5.调度器的Canchange利用了elevator的容器遍历读取哪个电梯可以完成运送任务来调度电梯

调度算法:自由竞争

即一起去接主请求谁先接到主请求则主请求归谁,调度算法未发生变化

类图:

bug修复:

互测时修复了可自定义横向电梯因为获取新人后未更新主请求的bug.

UML协作图:

心得体会

多线程单元其实主要需要考虑的是线程之间的冲突问题,所以在第一次作业框架基本已经固定的情况下其实每一周的迭代工作并没有多累,基本上只是在原有的基础上增添十几二十行代码就足够通过新的测试,但是因为自己偷懒所有没有按照工厂模式将横向与竖向电梯分开的缘故,还是产生了一些我认为没有bug但是实际上会出现bug的情况,偷懒一时爽,互测火葬场,多线程的开发思路比写要更重要,没思路的时候一行都写不出来,但是突然有一瞬间你想到怎么做合适,就可以一次写很久,所以不需要和代码死磕,可能灵感就来源于一瞬间,紧绷的时候适当放松一下就会突然迸发灵感.