OO第二单元博客
三次作业的设计策略
第一次作业
多线程协同控制
第一次作业只需要两个线程和一个公共缓冲区:
- 负责读取输入并把它添加进命令队列的线程,即生产者
- 负责从命令队列中取出命令执行的线程,即消费者
- 再加上一个缓冲区:命令队列
相对应的线程之间的互斥和同步操作及对应的处理方法
互斥操作:
- 互斥1:对命令队列的读-写操作和写-写操作之间的互斥:
- 我采用的方法是使用Java的
ReadWriteLock
来实现互斥操作,通过封装Vector类为自己的线程安全的命令队列类,实现读-写互斥和写-写互斥。
- 我采用的方法是使用Java的
- 互斥2:为了实现当生产者线程结束后,消费者线程再结束,必须使用一个公共指示变量,对于这个指示变量,同样需要相应的读写互斥和写写互斥
- 同样使用
ReadWriteLock
实现互斥操作
- 同样使用
同步操作:
- 同步1:命令队列空时,消费者线程需要等到生产者线程添加了命令后才可以执行
- 对于线程之间的同步操作,因为互斥操作已经使用了
Lock
实现没有使用synchronize
关键字,所以我并没有使用wait
和notify
方法,而是采用更加灵活的Java的Semaphore
信号量类,因为信号量并不需要在synchronize
语句块内使用。
- 对于线程之间的同步操作,因为互斥操作已经使用了
- 同步2:同时还有当生产者线程即输入线程结束后,消费者线程才可以结束
- 这里使用公共的指示变量来实现,检测到指示变量被设置并且此时命令队列为空,那么电梯调度线程结束
分析程序结构
由于每一次作业都是在前一次作业的修改上进行,所以对uml图的分析放在第三次作业那一块,这里简要分析一下第一次作业的类及其作用。
对于第一次作业,我写了五个类
Constant
,专门用于存储一些多个类都可能用的上的全局常量,比如电梯的最低楼层,最高楼层,这样写对之后程序的修改也方便Main
,main类RequestQueue
类,自己使用Vector
和ReadWriteLock
实现的线程安全的命令队列类,可以实现读-写互斥和写-写互斥Lift
类,电梯类,实现电梯的基本运行方法,包括开关门和上下楼Handler
类,调度器类,实现对电梯的调度策略
SOLID原则检查
- 单一责任原则遵守的自认为不错,每个类都只负起自己该负的责任
- 开放封闭原则遵守的自认为不错,代码更新无需删除原来的代码。
- 里氏替换原则:没有使用继承
- 接口隔离原则:没有定义接口,也没有必要定义接口
- 依赖倒置原则:未使用抽象类
分析bug
公测和互测均未出现bug
第二次作业
多线程协同控制
第二次作业相比第一次作业,在多线程的设计上并没有什么太大的变化
调度策略设计
只是在调度策略上进行了改进,所以这里简要阐述我的调度策略。
作业指导书上推荐使用的是捎带算法,但是自己在实现捎带算法时感觉逻辑很复杂(也许是我想的太复杂),故权衡之下决定使用扫描算法
,即电梯通过不断的从需要到达的最低层一直到需要到达的最高层,再从最高层到最底层,按照这样的次序依次扫描直到输入线程结束。
类结构分析
这次作业我在前一次作业的基础上增加了一个类:Request
类,即是对输入接口中的PersonRequest
的封装,因为对于扫描算法来说,在到达某个指令的目标楼层时,需要检查当前指令是否已经走过初始楼层,所以需要记录指令的state
metric分析
可以看出Main类中,因为放入一些无关的逻辑,导致复杂性增加
bug分析
在公测和互测中都没有发现bug
但是在写作业的过程中,犯了一个致命的错误,就是竟然使用了轮询,而且我一开始还没有意识到使用了轮询,于是在公测中出现了CPU_TIME_EXCEED的错误。当时我对于wait和notify的使用还不清楚,对于线程间的协同控制也没有理解太到位才导致了这个错误,修改后我对wait和notify的作用理解更深了。
第三次作业
第三次作业相比于第二次作业,大的不同点有两个
- 首先有三部电梯,这样在调度策略上就需要改进,不仅考虑单个电梯如何调度自己的请求,更要考虑请求如何更好的分配到三部电梯
- 一些请求靠一部电梯无法执行,需要两部电梯协同执行,这一点比较难
多线程协同控制
这一次作业因为需要两部电梯协同执行,所以我选择把一些不能用一部电梯完成的命令拆分,这样我在输入处理和三部电梯的调度器之间又增加了一个总调度器,如图
这样做逻辑更加清晰,但是因为增加了一个公共缓冲区,所以需要的同步互斥操作更多了,不过使用之前的同步互斥方法就可以解决它。
调度策略
这次有三部电梯,所以调度算法的设计有很大的空间,但是我因为时间关系,没法设计出更好的调度算法,所以简单采用了平均分配的方法,即对于一部电梯就可以执行的指令,如果三部电梯都可以执行,那么就按照电梯1,电梯2,电梯3,电梯1...的顺序分配。
拆分策略
第三次作业涉及到了两部电梯的协同,我一开始想到了两种方法:
- 利用图寻路算法,这样无论它怎么改变每个电梯的可停楼层,都可以通过寻路算法得到最优的协作办法
- 硬编码,利用多层if else把情况分类
这里我选择了第二种,第二种编写起来逻辑简单,不过扩展性差。
类结构分析
这次类相对于上次作业,增加了MainHandler
类,即控制位于输入线程和三个电梯线程之间的公共缓冲区,以及分配命令给三个电梯线程
下面是这次的UML图
度量结果
这里只给出有红色字体的分析图,可以看出main函数的嵌套深度大,代码复杂性高,究其原因是我把拆分命令的逻辑放在了这里,正确的设计应该把它单独写到MainHandler
类中
SOLID原则
- 单一责任原则:每个类都只负起自己该负的责任
- 开放封闭原则:代码更新无需删除原来的代码。
- 里氏替换原则:没有使用继承
- 接口隔离原则:没有定义接口,也没有必要定义接口
- 依赖倒置原则:未使用抽象类
bug修复
在这次作业中,一开始的公测没有测出我的一个bug,这个bug可能导致ArrayIndexOutOfBounds这个异常,因为我把每个电梯的可用楼层用数组的形式存着,但并没有做上限检查,导致出现这个bug,目前已经修复
心得体会
线程安全
我认为线程之间的协同,总的来说就是要考虑两个方面:
- 同步控制,即线程的执行顺序需要控制,在命令队列为空时,消费者线程 是不能从中取命令的,必须要等待生产者线程放入命令后消费者线程才可以继续执行。
- 互斥控制,即读-写互斥和写-写互斥。
对于这两个方面:
- 同步控制我使用了Semaphore
- 互斥控制我使用了ReadWriteLock
在线程安全方法,只要分析出需要的同步和互斥这两方面的操作,并分别针对性的进行控制,线程安全就没有太大问题
设计模式
- 我看了HeadFirst设计模式这本书,越看越觉得设计模式是很灵活的,就和倚天屠龙记里的太极拳法一样,把该忘的都忘了,只记住一些必要的原则,就可以在设计时找到最适合的那个模式。
- 好的设计模式可以在重构程序时事半功倍