过去三周里,我们完成了多线程电梯的程序设计与构造。这是我第一次接触多线程编程。我感觉最大的困难在于多个线程中的操作,谁先谁后,不是像以前写的单线程程序那样严格确定,所以心里常常会比较慌。尤其是因为多线程运行有一定随机性,常常可能会发生bug无法复现的情况,或者是代码有风险但碰巧测试运行时没有出现问题。

一.设计策略总结

电梯问题的多线程设计,与理论课上学习的生产者消费者模型是比较类似的。请求队列支持插入新的请求和弹出请求(给电梯)。仿照生产者消费者模型,把读线程看作生产者,把电梯线程看作消费者,可以完成多线程的同步控制。

由于我能力有限,对于多部电梯的情形,我的调度方案是只考虑单个电梯的状态,决定是否将请求分配给该电梯,并没有选择综合所有电梯的状态。因此电梯运行性能会比较差,但避免了复杂的多线程协同问题。

二.程序结构分析

OO第二次博客-LMLPHP

OO第二次博客-LMLPHP

第一次作业的需求比较简单,所以各个模块内容都比较少,大概也是因此,各项指标都还不错。电梯类中的working方法是令电梯完成一个请求,由于这次作业没有捎带,也不需要在每一层完成输出,我把所有的内容都混在一起写了,所以指标要偏高一些。

OO第二次博客-LMLPHP

OO第二次博客-LMLPHP

第二次作业加入了捎带,整个电梯类变得复杂多了,主类和读入类几乎没有变化,请求队列类只多了一种取请求的方式,来支持捎带。电梯类的elevatormove方法是让电梯到达目标楼层,分上行和下行两类情况,对途中每一层都调用moveperfloor方法,视情况可能会执行开门,乘客出入,关门行为,以及可能的捎带操作,并完成相应的输出,因此这个方法几乎全是条件循环,指标偏高。

OO第二次博客-LMLPHP

OO第二次博客-LMLPHP

第三次作业的度量结果就比较差了。主类和读入类没有太多变化,但电梯类和请求队列类问题比较大。我的调度器是整合在请求队列里的,而电梯得到请求后会根据自身停靠情况来做请求的拆分,并在执行完前半段请求后,把后半段不能执行的请求送回请求队列,等待其他电梯来获取该请求。我的调度和请求拆分都写的不好,条件判断复杂。此外,由于加入了电梯容量限制,常常需要判断乘客是否进入了电梯,使结构复杂了一些,这也是和前面的两次作业比较大的不同。 OO第二次博客-LMLPHP

OO第二次博客-LMLPHP

OO第二次博客-LMLPHP

至于类图,三次作业基本差不多,主要是电梯类随着新需求的加入,变得复杂了许多。主类创建了读线程和电梯线程,并完成输出时间戳的初始化。读入线程把请求读进来放进请求队列中。电梯线程每当没有请求时,就向请求队列取新的请求,然后按照请求去运行,顺路捎带。请求队列相当于是一个线程交互的平台,在第三次作业中还会参与请求的分配工作,执行最初步的判断。

从SOLID原则的角度分析,我的架构问题很大。首先我并没有利用继承和接口,也就不存在L和I原则。S原则要求的单一功能,我的电梯类感觉比较混乱,各种功能都包含在内了。至于O原则,我的请求队列谁都能添加和取出请求,并没有写成封闭的。D原则感觉好复杂,我不理解具体要写成什么样子才是“依赖于抽象”,大概指的是对象的交互的媒介吧,要写的更巧妙一些。

三.Bug分析

第二次电梯和第三次电梯作业我都出现了bug。

第二次作业的bug是因为我记录了电梯主请求的乘客编号,但是误以为编号是正整数,而实际上指导书上写的是非负整数。弱测并没有出现过编号为0的情形,第一次作业也没有判断过乘客编号,所以我完全没有注意到。强测中出现了乘客编号为0,所以我的代码就出错了。我的捎带方案是电梯达到请求的起点楼层时,就捎带该乘客,乘客会立即进入电梯。因此,只有主请求,它有可能不是被捎带上的请求,它的乘客有可能还没有上车,所以我把主请求的乘客编号单独存下来了。

第三次作业的bug是,电梯在前往主请求的起点楼层前,就由于捎带而把电梯装满了,因此主请求的乘客上不来;但我没有考虑这种情况,我会让电梯继续前往主请求的终点请求,到达后,由于乘客还没上来,自然也不会下,并且电梯主请求不会更换,因此又要去主请求的起点楼层;如果到了以后电梯仍然满员,就会循环下去;特别的,当来回过程中没有乘客离开电梯,就陷入了死循环。最简单的修正方法是如果主请求的乘客上不来,就更换主请求,换成任何一个乘客已经进入电梯了的请求即可。

两次作业的bug都与多线程没有什么关系,而是电梯运行的一些细节考虑失当,而且是设计时完全没有想到过的问题。特别是第三次作业,我对于电梯加入乘客数量限制,会造成多大的影响,分析不够全面。

四.心得体会

线程安全方面,由于我的设计规避了很多风险,并不涉及到复杂的线程安全问题。如果我的调度方案要综合所有电梯的状态,那么就需要处理“先判断后修改”的情形。

多线程的设计原则,应该是尽可能减少线程同步的发生。如果多线程程序中大量出现线程锁,这样的性能是非常差的。我的电梯程序中只有请求队列里出现线程同步,这是比较简单的多线程情形。

程序的设计原则,需要考虑未来可能加入的新需求,提取把架构设计好。好的代码应当具备高的可扩展性。我三次作业的大框架基本是一致的,但是电梯类每次改变都比较大。这点在今后还需要多学习,争取能设计出好的架构。

04-30 11:15