第二个单元的三次作业均为多线程电梯的设计,旨在让我们能够理解多线程在面向对象设计时的重要意义,并熟练掌握在保证线程安全和性能高效情况下的多线程协同的设计模式——在本次作业中主要体现在生产者-消费者模式。三次作业从开始简单的傻瓜调度电梯,到加入捎带的ALS捎带算法以及最后多部电梯的组合运行模式,逐步加强了我们对线程设计的深入理解,在要求陆续增多的情况下合理设计,保证线程的高效和安全。

一. 总体设计思路

第一次作业

第一次作业是一个简单的傻瓜调度的电梯,是经典的生产者-消费者模式。生产者每读到一个请求就向托盘放入请求,同时消费者只要托盘中有请求就读取出来进行处理,由于放/取请求遵循先入先出的原则,故托盘可设计为一个队列。生产者和消费者各自只与托盘进行交互,互不干涉,保证多线程。托盘的队列为他们的共享对象,放/取操作不能同时进行,故要对其进行加锁,当放/取操作结束后再释放。

多线程的协同与同步控制方面:生产者线程将读到的请求放入托盘中,当读到null时则中止,其中使用到托盘中的put函数;消费者线程每次读取托盘中的一个请求,将请求执行完以后再继续读取下一个请求,当读到null时则中止,其中使用到托盘中的get函数。其中put函数只要有请求就放入,不存在需要阻塞的情况,而get函数当托盘中无请求时需先进入阻塞态(使用wait()),直到再有程序时就进行唤醒(notifyAll()),两者不能同时进行,故用锁synchronized进行锁住。

第二次作业

第二次作业相比于第一次作业,变成了多线程ALS(可捎带)调度算法的电梯。即当电梯运行过程中,如果托盘中请求队列中有请求到来的时间早于它到达请求出发楼层的时间,且请求的目标方向与电梯的运行方向一致,则可将该请求记为可捎带请求,在运行过程中执行该请求。

主体设计思路是,电梯读入一个请求,开始执行请求。首先建立一个ArrayList存已经进入电梯里的请求,在每一层停下来,建立两个ArrayList分别装从托盘中取出的所有可捎带的请求和目标楼层是这一楼层的请求,分别执行其对应的操作。当最开始的请求执行完并且电梯里无请求时,操作完毕。电梯继续向托盘读入请求。

托盘中除了get()和put()函数外,再新建了一个getorder()的函数来取出其中可捎带的请求,判断是否可捎带的标准与指导书一致。

多线程的协同与同步控制方面:相比于第一次作业增加了托盘中的一个同样取出请求的函数,当托盘中无可取出请求时无需等待,因此不用进行线程阻塞/运行态的转换,但这个函数同样涉及到共享对象请求队列的改变操作,因此也需要通过synchronized进行锁住来防止出现线程安全问题。

第三次作业

第三次作业中增加了电梯的个数,每个电梯都有特定的到达层数,对每个请求可能会使用到不止一台电梯。因此在第二次作业的基础上,可以采用先将每一个请求进行划分,划分的每个部分请求都一定能在一台电梯上执行完,当第一个部分请求执行完以后电梯才可读取第二个部分请求。基于这个思路,只需对调度器请求队列进行处理,并当电梯执行完第一个部分后传递信号给调度器可以读取下一个部分请求,即可沿用第二次作业的设计。

多线程的协同与同步控制方面:相比于第二次作业增加了对请求队列的划分处理和信号传递,都无需等待,信号传递后队列中该请求会将第一个部分请求remove出去,对共享队列进行了修改,故也需要synchronized进行锁起来。

二. 自我测试发现的bug

第一次作业

(1)时间错误

第一次写完以后发现从高层到低层时间会特别快,经检查代码后发现在处理从出发楼层到目标楼层时,忘记考虑结果为负数,加了绝对值后即可。

第二次作业

(1)NULLPOINT错误

在对托盘读到的请求进行判断处理时,一定要将是否为空放在判断的最前面,当多个判断条件用&连接时,也会按照顺序从第一个开始判断。

(2)ArrayList超出长度的错误

在电梯从托盘的请求队列中取出可捎带请求时,同样要将该请求从请求队列中remove掉,此时没有处理好for循环中i的值也要相应的减少,使得最后爆出超出ArrayList长度的错误。

(3)不能停止的错误

在电梯运输逻辑中,判断是否出来时,开始忘记加上了主请求已完成的判断条件,导致电梯会一直停不下来。后来加上条件后即恢复正常。

第三次作业

在处理对请求的划分时没有出现很大的逻辑错误,但最后却因为线程安全问题,出现了很多RUNTIME ERROR和TLE的错误。

(1)处理请求划分时没把握好顺序

开始的时候,我忘记了在请求划分后的第一个部分请求执行完以后再remove掉引入第二个部分请求,导致会出现请求部分顺序混乱的情况。

因此,我将Person Request类增加了一个参数state,当为true时可被电梯读入,为False则不能被读入。划分后第一个部分请求的State为True,其余均为False,当第一个请求被读取后State变为False,当第一个请求执行完之后将其remove掉,再将接下来的请求的State变为True。通过这样达到顺序正确的要求。

(2)线程安全错误

在处理wait()和notifyAll()时没有梳理清关系,导致有些情况线程不会被唤醒,有些情况线程不会进入等待状态而是直接结束,因此出现了很多运行时间的报错。

三、代码分析

五个总结程序结构的度量参数具体含义如下:

(1)ev(G):基本复杂度,用来衡量程序非结构化程度的,范围在[1,v(G)]之间,值越大则程序的结构越“病态”。非结构成分降低了程序的质量,增加了代码的维护难度。

(2)Iv(G):模块设计复杂度,用来衡量模块判定结构,即模块和其他模块的调用关系。软件模块设计复杂度高意味模块耦合度高,这将导致模块难于隔离、维护和复用。

(3)v(G): 循环复杂度,用来衡量一个模块判定结构的复杂程度,数量上表现为独立路径的条数,即合理的预防错误所需测试的最少路径条数。

(4)OCavg:类方法的平均循环复杂度。

(5)WMC:类方法的总循环复杂度。

部分设计原则如下:

(1)单一功能原则:一个类只承担一种类型的责任,即只有单一功能,以避免同一个类中职责间的影响。

(2)里氏替换原则:子类可在任何父类能够出现的地方替换父类,且经替换后代码还能正常工作。

(3)依赖反转原则:代码应当取决于抽象概念,而不是具体实现,即依赖于抽象而非实例。

(4)接口隔离原则:多个专门的接口优于单一的总接口。

(5)开闭原则:对扩展开放,对修改封闭。

参考博客链接:https://www.cnblogs.com/qianmianyu/p/8698557.html

https://www.cnblogs.com/panxuchen/p/8689287.html

https://www.cnblogs.com/huangenai/p/6219475.html

第一次作业

(1)类图

(2)方法度量

(3)分析

1.复杂度分析

可以看得出来本次作业中各个类及各方法的复杂度都控制得较好,结构也比较清晰直观,方便在后面的作业中进行扩展。

2.设计原则分析

根据查找资料,从线程所需的依赖反转原则和开闭原则的角度来看,本次电梯类只是单纯的根据输出信息进行操作,而没有真实抽象的模拟上下楼层及开关门的情况,显得比较实例化。

第二次作业

(1)类图

(2)方法度量

(3)分析

1.复杂度分析

相比于上一次作业来说,结构基本保持,比较清晰。可以看出ElevatorOperate类的Operate方法复杂度非常高,其中由于对电梯运行请求的处理过于繁琐,含有多个if/else嵌套以及复杂的判断条件,使得其复杂度大大提升。

2.设计原则分析

从单一功能原则角度分析Operate方法,可以发现,在这个方法里放的功能过于繁多,例如完成从当前楼层到出发楼层以及出发楼层到目标楼层两个步骤,分别每层的运行,捎带人进来,结束的判断……功能过于复杂,因此导致了设计结构很冗长。

(1)类图

(2)方法度量

(3)分析

1. 复杂度分析

本次作业沿用了第二次作业的Operate方法,因此其复杂度原因一如上面描述比较高。同时在其他方法中同样存在大量if/else的判断条件,嵌套复杂,因此复杂度也很高。

2. 复杂度分析

依旧从单一功能原则来看,依旧存在在一个类里放多个功能的情况,尤其体现调度器Tray类,作为生产者和消费者之间的桥梁,取放请求、拆分请求、获取可捎带请求等功能都在这里实现,因此调度器的效率极为低,且很容易炸CPU。

四、to hack or not to hack

三次作业的互测环节,均是拿一些自己构造的样例对某一个或某两个人的代码进行检测,遇到错误则提交。尽量保持hack的次数不要太多。

第一次作业

这一次作业比较简单,大多数人都不会有错误,因此没有发现bug。

第二次作业

考虑采用了对一些当电梯刚离开当前楼层例如一层,就传来出发楼层为一层的请求,如此往复,若完全按照指导书的ALS调度,则会出现类似傻瓜电梯一样的送完一个人再送下一个人的情景,可能出现tle错误。同时根据代码寻找可能出现的特殊样例bug。

第三次作业

这次作业较为复杂,可多次选用一些需要不停调换的请求进行hack。

五、感想

一定要掌握线程安全的思想!线程安全思想还比较薄弱的我,在第三次作业几乎遭到了毁灭的打击,差点用光所有的评测机会才堪堪交上,而且还是极度不安全的可能过可能不过的状态。线程不安全一时爽,提交火葬场。在研讨课的时候,很多大佬们也分享了关于线程安全的思考和如何判断线程安全问题症结的方法,在之后的学习里也要合理利用这些方法,设计一个安全又高效的线程!

同时印象很深刻的是,如果掌握了线程安全的思想,在设计时就会轻松很多,合理安排每个线程与彼此的交互,这样对每个线程来说只要专注于眼前的任务即可,设计也会更加的轻便简洁。

OO第二单元总结之线程大冒险第一关的更多相关文章

  1. oo第二单元作业总结

    oo第二单元博客总结 在第一单元求导结束后,迎来了第二单元的多线程电梯的问题,在本单元前两次作业中个人主要应用两个线程,采用“生产者-消费者”模式和共享数据变量的方式解决问题.在第三次作业中加入多个电 ...

  2. 【OO学习】OO第二单元作业总结

    OO第二单元作业总结 在第二单元作业中,我们通过多线程的手段实现了电梯调度,前两次作业是单电梯调度,第三次作业是多电梯调度.这个单元中的性能分要求是完成所有请求的时间最短,因此在简单实现电梯调度的基础 ...

  3. OO第二单元小结

    OO第二单元小结 一.三次作业代码分析. 1.第一次作业 第一次作业是单部电梯的傻瓜调度,由于其过分傻瓜,所以第一次作业我只有两个类,一个main,一个电梯,main类负责不断从输入流中读取命令,如果 ...

  4. OO第二单元多线程电梯总结

    OO第二单元多线程电梯总结 第一次作业 设计思路 Input为输入线程,负责不断读取请求并将读到的请求放入调度器中. Dispatcher为调度器,是Input线程和Elevator线程的共享对象,采 ...

  5. 电梯也能无为而治——oo第二单元作业总结

    oo第二单元作业总结 一.设计策略与质量分析 第一次作业 设计策略 在第一次作业之前,我首先确定了生产者--消费者模式的大体架构,即由输入线程(可与主线程合并)充当生产者,电梯线程充当消费者,二者不直 ...

  6. OO第二单元——多线程(电梯)

    OO第二单元--多线程(电梯) 综述 第二单元的三次联系作业都写电梯,要求逐步提高,对于多线程的掌握也进一步加深.本次作业全部都给出了输入输出文件,也就避免了正则表达式判断输入输出是否合法的问题. 第 ...

  7. 2020北航OO第二单元总结

    2020北航OO第二单元总结 前言 本单元考察基于多线程的电梯调度问题,成功让我从一个多线程小白到了基本掌握了使用锁来控制线程安全的能力,收获颇多(充分体验了迷茫地de一个又一个死锁bug的痛苦). ...

  8. OO第二单元优化博客

    OO第二单元优化博客 第五次作业没有性能分,但是,我在这一单元的宗旨就是写一个日常生活中 最常见的那种电梯,所以第五次我没有写傻瓜电梯,而是直接写了个\(look\),和第六次基本相同. 总计一下lo ...

  9. OO第二单元电梯线程系列总结作业

    电梯系列第一次作业 功能描述: 傻瓜电梯无需考虑超载捎带 线程模式: Producer-Consumer Pattern 思路: 第一次作业是一个傻瓜电梯,分别有一个生产者生成电梯指令(也就是Inpu ...

随机推荐

  1. WEB API系列(一):WEB API的适用场景、第一个实例

    在我前一篇博客中已经给各位简单介绍了HTTP协议与RestFul API的关系,以及一些基本的HTTP协议知识,在这些知识的铺垫下,今天,我们一起来讨论一下WEB API的适用场景,然后写我们第一个W ...

  2. glom初级教程

    1.glom介绍 通常对于字典和json的提取我们都是使用如下方式 >>> data = {'a': {'b': {'c': 'd'}}} >>> data['a' ...

  3. linux如何查看所有的用户和组信息?

    cat /etc/passwd cat /etc/passwd查看所有的用户信息,详情如下图   [步骤二]cat /etc/passwd|grep 用户名 cat /etc/passwd|grep ...

  4. How Many Zeroes? LightOJ - 1140

    #include<stdio.h> #include<string.h> #include<math.h> #include<time.h> #incl ...

  5. Asp.net core 学习笔记 Razor Page

    更新 2019-04-27 最近做了更多的 research 发现微软视乎有意发展 razor page. razor page 的定位是 mvvm, 现在还有个叫 blazor 的东西, 类似用 c ...

  6. ape 文件 转化为mp3 文件

    试了很多软件,最后才发觉 any-audio-converter最好用. 可以吧ape 按 cue切割好,然后转化成 MP3 官网可以免费下载: https://www.any-audio-conve ...

  7. 提升 Hive Query 执行效率 - Hive LLAP

    从 Hive 刚推出到现在,得益于社区对它的不断贡献,使得 Hive执行 query 效率显著提升.其中比较有代表性的功能如 Tez (将多个 job整合为一个DAG job)以及 CBO(Cost- ...

  8. flutter -------- ListView的使用

    学习了Flutter,来分享一下学习的一些常用的知识,先来说说ListView 案例效果: ListView是一个类似列的widget,它的内容对于其渲染框太长时会自动提供滚动. ListView 摘 ...

  9. 关于最新create-react-app使用react-app-rewired2.x添加webpack配置

    使用过create-react-app(以下简称cra)的朋友都知道,这是react官方的一款脚手架工具,内部集成了babel,webpack,webpack-dev-server等等. 以前我们要在 ...

  10. linux-基础命令篇-01

    基本命令: who:目前有谁在在线 netstat -a:网络的联机状态 ps -aux:背景运行的程序 sync:将数据同步写入硬盘中的命令 shutdown:惯用的关机命令 reboot, hal ...