其他分享
首页 > 其他分享> > 北航面向对象2022第二单元总结(Elevator.exe已停止运行...)

北航面向对象2022第二单元总结(Elevator.exe已停止运行...)

作者:互联网

您的电梯已停止运行(NO!)

这里是BUAAOO第二次单元作业总结博客。第二单元是BUAA的电梯模型,今年的电梯比起往年看起来友好很多。在第五次作业上手时,因为是第一次搭建相关逻辑,并且对于多线程构造和运行状态处于懵懂阶段,可能会遇到一些麻烦。(看到往年第一次的作业是傻瓜电梯的时候,我还在想今年的电梯上手真困难)不过在第六、七次作业中,一些增量迭代显得不那么困难,仅仅只是从单纯的纵向电梯转为了横纵交错的电梯,最后实现了可换乘的电梯运行mode。总而言之,三周的作业写的十分充实,并且让我感受到了多线程别致的“魅力”。


HW_5

本人的三次电梯架构基本完全基于第五次作业的base,即使增量也没有进行大规模的重构。因此在这里,我先进行电梯整体架构设计的阐述。

同步块选择及锁的设计

首先是同步块的设置和选择,在没有参考实验代码时,我尝试自主设计同步块和有关锁,然后在自信满满地上交后,发现电梯光荣地死锁了。之后,我好好研究了一下第三次实验的代码,发现一个很有意思的事情:所有的操作线程wait和notify的内容都放在了RequestQueue中,在这样的设计下,同步块和锁集中于此,各个线程相当于把这里作为了一个公共空间,在想要访问该内容时便采取“等待”、“进入”、“使用完让行”的操作。这样的设计可以很好地满足线程安全的原则,并且也能解决我的设计问题。因此,我将每个电梯内的服务队列所在类设置为同步块集中区,并且使用synchronized关键字进行互斥维护,此时,对每个电梯来说,线程安全就得以满足。

调度器设计

在任务分配,也就是调度器方面,我直接用主线程来进行任务的输入操作,并没有单独的设置一个新的线程来进行处理。任务的处理以及调度的策略集中存放在TaskTower这个类内,用任务塔作为一个中介,将任务由输入线程转入电梯运行线程。

整体框架

首先是hw5的UML类图:

由于第二单元刚开始,大家提到生产者-消费者模式比较多,因此我也对应着做了一点调整。具体来说,输入作为生产Passenger,也就是任务的生产者;电梯内Strategy存有待做任务和正在做的任务,对应两个队列,电梯运行时会获取内部的Passenger加以送达,也就是任务的消费者。具体到电梯内部运行,和标准流程一样,用ALS策略,在上升下降的过程中,如果电梯没有人,就指定在本电梯外部等待的第一个Passenger为主任务对象,以它为目标。如果内部存在任务,就更换主任务对象为内部第一个存入的任务。

程序BUG

本次在公测互测中分别出现了一个bug,一个对应线程永久等待不会结束的问题,导致最后rtle。主要原因是在输入线程结束,setEnd位时,没有处理好互斥原则,导致设置End位在等待以前结束,而唤醒结束后才进入wait。另一个对应输出线程不安全的问题,导致时间戳获取与实际输出顺序颠倒。

由于第一次互测经历了重测,我在互测中总共发现了其他人的两个bug,刚好对应我自己的两个问题(同组人没想到也犯了一样的错误)。在互测中,我自己使用数据生成器生成数据来进行hack,不好构造数据时,压力测试还是很好的选择,毕竟没有重测之前,本组就只有我测出了一个bug。


HW_6

第六次作业主要增加了在楼座间可以循环运行的横向电梯,以及可以新增电梯的操作,需要采用新的设计思路来管理。但总体上来说,可以和hw5采用一样的方法来处理。

调度器增量

由于我们需要满足新的请求:增加电梯请求。因此,我们要在调度方面采取一定的策略来选择新加入的电梯。我并没有采用电梯自由竞争的方式,而是按照课程组给出的标程,直接顺序循环遍历可以处理任务的电梯,保证均匀分配。事实证明,在强侧中我使用标程也取得了很不错的效果,不仅完全不存在超时的问题,在个别任务上还达到几乎满分的速度。

框架升级

接下来是hw6的UML类图:

可以发现,我改进了电梯管理类来方便新增的电梯管理。这里主要谈一谈新增横向电梯的设计策略。总的来说,从UML图中也可以看出,我设计时基本参照了纵向电梯的设计思路。主要区别在于,横向电梯把顺时针看作上升,把逆时针看作下降。同时,用起始楼座之差的绝对值和符号来判断向哪个方向走最近。具体如下:

boolean upOrDown =  !(endID - stID > 2 || (endID - stID < 0 && endID - stID > -3));

程序BUG

本次在公测互测中没有出现bug,本次测试中,同组的大家基本都考虑到了第一次出现的各种线程安全问题,并且在线程结束方面也下了狠手。并且新加电梯的个数有限,不太容易发现bug。我还是采用随机生成数据的方式来进行hack。但是我采用了“新的实践方式”,我把自己前几版错误的代码拿出来进行错误代码认证,并且将产生错误的生成数据归纳到对应的bug下。果然“实践是检验真理的唯一标准”。


HW_7

第七次作业主要增加了电梯可设置参数的要求,以及乘客可以跨楼座跨楼层移动的请求。实际上前者在我们的设计中很好体现,只需要添加对应的参数输入即可。后者我虽然参考了课程组给出的流水线代码,但是实际上做出来是一个分段式的三段请求链结构,分成纵向—横向—纵向来进行任务运行。

调度器改进

由于我们需要满足电梯换乘,在我的设计中,我在调度器中增加了换乘逻辑。具体来说,我将请求分为两部分,一部分对应直上直下的固定请求(hw5),一部分对应跨楼座的请求。对于后者,每当有新任务进入调度器,就分析在何处跨楼层,并让乘客记住自己将换乘的电梯及楼层,并进行任务投喂。(我不是采用的电梯获取请求,而是调度器投喂请求的方式,也就是不会自由竞争,单纯进行均衡分配)

框架进一步升级

接下来是hw7的UML类图:

可以发现,我改进了电梯管理类来方便换乘时的电梯管理,并且增加了一个单例对象来方便换乘。事实上,对于乘客来说,如果需要换乘,他总共会有三个运动阶段,在每一次被投喂给电梯前,我会先更新乘客的运行状态,修改好起始、终止楼层,起始、终止楼座。因此,当所有阶段完成后,乘客就会被移除任务清单。

另外值得一提的是,我借鉴了实验exp4_2中的请求清算结束方案,在输入线程结束输入任务后,被视为新的结算线程运行。每当有乘客请求投入时,RequestNum自增1,每当类似上述所说的乘客被移除任务清单后,触发任务结算,并将RequestNum自减1,最后,所有任务都被处理完,并且输入的线程显然也消亡了,就会触发整体模块的结束,顺利退出程序。

我们把最后设计好的情况的四个时序图展示如下,分别对应主线程(启动线程)、输入调度、以及横、纵电梯的运行逻辑,最后是请求结算逻辑。

程序BUG

本次在公测互测中出现1个bug,但我自己在之后又整理出一个bug.前者是致命性bug,由于单元测试不充分,发现只要来同座运输请求(hw5),就会由于强行调用第二部分的方法导致空指针异常(很心痛,很值得反省)。后者是由于换乘导致的线程互斥问题,主要是对于迭代器遍历同时修改,造成了不可知的影响。

在互测中,我针对代码运行逻辑试图卡运行时间来hack,构造了边界情况:在输出截止时间输入最大数据量最远抵达路径的乘客。成功造成了两次hack;另一方面,和hw6一样针对自己的代码生成了错误数据代码,又造成了两次hack。最后总计造成了4次不同的逻辑hack,有比较好的效果。


心得体会

通过本单元学习,可以感受到助教们的满分热情(bushi)。我们在第一次作业就直接采用ALS策略电梯,构建起对多线程的整体框架认识,快速上手。后面两次作业看似加了不少新内容,但做起来也并不复杂,只要有了第一次作业迈上台阶的基础,就能很好地处理多线程中的各种问题了。(被hw5暴露的各种bug很好地让我认识了多线程中可能出现的各种问题)

另外,我本人不太擅长自己构建一些新鲜的策略算法来进行处理,于是按照课程组给出的标程逻辑一步一个脚印走完了全程。总的来说,由于多线程调度的不确定性,我使用标程的代码最终取得的效果并不赖,完全不存在超时的问题,也从未产生过轮询的现象,没有出错的得分点分数也不错,这让我感到一丝丝自己完成一份任务的成就感。

撰写本总结博客时,回味整个月的思考、迷茫、再建、讨论、测试、修复,真是百感交集。留下的,不只有经验教训,更有继续勉励的信心。

精感石没羽,岂云惮险艰。”OO课程已过半,后面就,再接再励吧。

标签:...,exe,请求,任务,Elevator,调度,电梯,线程,bug
来源: https://www.cnblogs.com/2037hanzhe/p/16191866.html