第五次作业后oo开始了多线程的作业，这对我来说是一个不小的挑战。
第五次作业
第五次作业是模拟三部电梯的调度和运行情况。程序情况见下图
代码情况还是有些类的方法太过复杂，其原因还是在开始写代码的时候没有做到全面的分析设计，那些比较复杂的方法大多都是在debug的时候一点一点修修补补变复杂的，这方面还是需要多加练习。对于多线程，在这次作业中我的理解就是，因为多线程中的属性是实时变化的，这时如果要进行数据的交互，比如说获得指令后的电梯调度，就要引入一个“托盘类”，我觉得托盘这个比喻实在是太贴切了，他就是一个静态的类，储存着需要交互的数据，定义着线程安全的方法，在有需要时提供数据交给多线程使用。我觉得这几次写的多线程问题都可以用托盘的思想来解决数据交互的问题。
BUG情况：这次的bug主要是因为对多线程的理解不够深刻在处理冲突时出现了一些问题，导致在有过多指令时运行的结果不正确。
第六次作业
这次作业是有关文件的多线程，总体来说这次的作业应该是难度最大的一次了，因为对有关文件的操作就不是特别熟悉，再加上对多线程操作也不熟练，所以在写的时候可以说相当痛苦了。代码分析情况见下图
这次的作业我觉得类的分工和方法的分工都还比较明确，但是这次的作业得分应该是最低的一次，原因在于其实我的功能没有特别完善，在对于目录进行监控时只实现了modified，其他几种是没有找到特别好的实现方法。
这次作业也是我感受最差的一次，但你不是因为得分低，而是因为作业的测试结果，这次的测试是比较麻烦，麻烦程度因人而异，但是就我而言，还是对我的测试任务兢兢业业测完了的，但是我的测试者，连公测都没有测完就开始找互测bug然后因为3个监控器没有监控目录功能挂了9次bug，就单从规则来说可能并没有问题，但是我觉得oo互测本意是相互监督相互服务，互相发现问题共同进步，但是在这次作业中我感受到的只是测试者眼中除了分数什么都没有了，公测麻烦对他又没有加分他就选择不测，公测外部分发现了错误就竭尽所能地申报bug，而我作为被测试者，除了赤裸裸的恶意什么也没收获到。
第七次作业
这次的出租车作业可以说是近几次作业中我自己完成度最高的一次作业了。一方面是因为多线程写到现在已经是第三次了，另一方面是提供的gui帮了大忙，对于debug太有帮助了。
BUG分析：
这次的问题主要是没有处理好同质请求，因为程序设计原因，读入指令的系统时间难以预估，所以无法准确识别是否为同质请求。
总结：
oo的学习到现在已经过半，不管前面的成绩如何我想我们熬夜写过的代码总是真实的，获益匪浅，继续前行。
原文地址：https://www.cnblogs.com/fakeboom/p/8981525.html
