第五次作业总结
1.分析协同和同步控制
多线程三部电梯，请求接收和调度器写在同一个线程中，一个请求进入之后就根据当前各个电梯的状态进行分配，如果能够分配就分配给1、2、3的编号，如果不能分配就进行阻塞，当有电梯为wait for service时分配给这个电梯。另有三个电梯线程，一部电梯一个线程。每个电梯线程是相互独立的，三个电梯线程、一个请求接收和调度器线程，三个电梯分别返回自己的状态给调度器线程。
2.基于度量来分析自己的程序结构
类图
解释分析：
control类：旧的control，被继承的父类
elevator类：电梯，运行三个电梯线程
floor类：楼层类，没有用到
Main类：主函数类
NewControl类：继承旧的control
Request类：请求，用于记录单挑请求的内容
RequestSimulation类：请求模拟器
Sequence类：linkedlist 请求数组
代码分析
解释分析：
DO方法是调度器中执行电梯调度的方法，went是电梯的主要执行方法。
时序图
3.分析自己的bug
第一个bug：
是判断捎带的时候产生了问题，没有判断电梯外请求想要前往的方向和当前运动方向是否一致。
第二个bug：
开始的时候不知道什么原因，导致自己跑这段测试代码的时候丢了一个请求，后来发现是因为这个请求因为判断的原因被忽略了...
4.分析自己发现别人bug所采用的策略
我查找别人的bug的策略第一步是依靠我自己在写这道题时，写给自己的测试样例，用别人的程序跑一遍，我的测试样例都是我觉得哪些点我可能会出错、或者是哪些不容易被注意的点。第二步是依靠测试树，在测试树的分支上特意写一些代码用作测试代码，给被测程序跑。第三步是阅读被测者的代码，看看还有哪些我觉得有问题的地方，进行测试。
5.心得体会
第一次使用多线程写题目，现在回过头看，发现问题还是很多的。头一次接触多线程，发现多线程真的是比单线程有很多好处，但是同时也存在了许多问题例如安全问题等。第一次多线程的体验还算好，起码没有出现太多的问题导致自己的程序崩溃...三个电梯一个电梯一个线程，请求接收和调控器一个线程，四个线程同时进行，完成多线程电梯工作。希望在之后的多线程作业中能收获更多知识，得到更多的有关多线程的技巧。
第六次作业总结
1.分析协同和同步控制
输入请求完成之后，将已经准备好的所有监控线程一起启动，之后启动测试线程，监控线程会根据测试线程完成的动作返回相应的输出和完成相应的动作。
2.基于度量来分析自己的程序结构
类图
解释分析：
Monitor类：监控线程，完成监控的类
Detail类：写文件detail.txt
Summary类：写文件summary.txt
FileAttributes类：文件属性类，存放文件具体属性
SafeFile类：安全类，重写file的方法，保障线程安全
Snapshot类：哈希Map类，用哈希Map进行快照，存放信息
TestThread类：测试文件所用的线程
代码分析
时序图
3.分析自己的bug
第一个bug：
由于我是先判断后加所以当第是十一个进入的时候，count是10，在第十一个监控请求放进队列之后，count才会变成11，是当时没有考虑清楚，改成count>=10就可以了
4.分析自己发现别人bug所采用的策略
我查找别人的bug的策略第一步是依靠我自己在写这道题时，写给自己的测试样例，用别人的程序跑一遍，我的测试样例都是我觉得哪些点我可能会出错、或者是哪些不容易被注意的点。第二步是依靠测试树，在测试树的分支上特意写一些代码用作测试代码，给被测程序跑。第三步是阅读被测者的代码，看看还有哪些我觉得有问题的地方，进行测试。
5.心得体会
本次作业的工程量相对较大，线程安全的应用也是第一次实践到代码中，更加深一步了解多线程的奥妙的同时，也觉得身心疲惫...我的天，好难啊...随时准备解决程序可能出现各种各样奇奇怪怪的bug...一会更改一个版本push一遍，防止自己改哪个地方改崩了。不过助教和老师说这是最难的一次了，剩下的就简单了（我真是 差点儿就信了），当时一听这话，精神百倍！奋起直追，记忆犹新当时凌晨三点还只有九个人交了，看来大家为了这次作业都肝到了很晚。不过无论如何，能坚持下来就是件好事。
第七次作业总结
1.分析协同和同步控制
一百个出租车，一百个线程，每个请求一个线程。请求线程的生命周期为3S，3S结束请求线程结束。一百个出租车有请求的时候就完成请求，没有请求的时候自由跑。
2.基于度量来分析自己的程序结构
类图
解释分析：
detail类：将出租车完成的动作写进文件
Gui类：提供的视图
Main类：主函数
RequestAndControl类：请求和调度器
Taxi类：出租车类
代码分析
时序图
3.分析自己的bug
第一个bug：
没有判断输入的请求出发地和目的地是否是同一个地方
第二个bug：
没有在readme中说明超过1000条请求会怎么样，并且没有惊醒处理
4.分析自己发现别人bug所采用的策略
我查找别人的bug的策略第一步是依靠我自己在写这道题时，写给自己的测试样例，用别人的程序跑一遍，我的测试样例都是我觉得哪些点我可能会出错、或者是哪些不容易被注意的点。第二步是依靠测试树，在测试树的分支上特意写一些代码用作测试代码，给被测程序跑。第三步是阅读被测者的代码，看看还有哪些我觉得有问题的地方，进行测试。
5.心得体会
这次作业，也没有助教和老师说的难度小，不过相比前几次作业，工程量是少了一些，不过感觉在一些细微的地方，还是有些弯弯绕绕值得我们思考。不过，很感谢助教和老师提供了GUI 能够帮助我们debug，更好的完善自己的代码，不然光靠代码测试，还是十分困难的。通过GUI也能让我们感受到自己的多线程出租车的成果，对于没有过这种经历的人来说真的是激动万分了，能够看到自己的100俩出租车跑起来完成任务，还真是挺高兴的。在完成这次作业的时候，也遇到了一些困难，这是之前多线程没有遇到过的，包括一些十分严重的错误，期望自己接下来的作业中，多学只是，刻苦努力。
原文：https://www.cnblogs.com/zyq16061126/p/8981911.html