标签：导致 除了 判断 size 资源 经历 inf 理解 方式
面向对象程序第二阶段总结
在第一阶段的任务过后，这一阶段的编程内容引入了更加复杂更加未知的元素——多线程。这三次作业的难度相比前三次难度有明显的提升，而且三次作业都不是一个主题，前后没有联系，因此这三周的工作量相比第一周大了很多，在多线程程序设计中我也遇到了很多的障碍，在很多地方感到自己的计算与考虑还显得十分幼稚，感觉自己的程序也都存在着很多的缺陷和错误。
第五次作业
第五次作业多线程电梯我没有按时完成，这也是我的第一次无效作业。在第一次面对多线程的任务时我遇到了相当大的障碍，对本次作业的工作量估计不足，最终没能在DDL之前完成一个能实现所有任务的程序。
尽管在这次作业中很多类都由上一次的类复用而来，但最关键的调度器策略出现了较大的变动，几乎是从头开始设计一个调度器。前一次的电梯作业中并没有现实时间这个概念，对一条一条请求的调度是在全部请求已经知道的基础上，根据电梯模拟运行状态来调度，而多线程电梯需要电梯实时地进行对自己状态的改变以及请求的接收、请求的分配调度。其中wait—notify的应用使整个程序的分析过程变得比较复杂。这一次作业中我对于共享资源、设计线程安全的类的理解不够深刻，使得设计程序时没能分清楚各个处理的关系，也导致了作业的失败。这一次作业作为自己学习过程中的一次教训，今后应当尽力避免。
第六次作业
吸取上一次无效作业的经验，这次作业虽然也经历了较长时间的挣扎但最终还是时间较充裕地完成了本次作业。在issue上比较长时间的澄清与明确之后，我们对IFTTT监测对象有了比较明确的理解。很明显监控范围内的目录和文件是各个监控线程之间的共享资源，会出现未知的各个线程获取、修改这些目录、文件对象属性的操作，造成线程不安全问题。
为了避免以上的难以预测的问题，这次的程序引入了快照的方式，即每次获取、对比的方法对监控对象操作时都对监控对象进行一次快照，把需要的属性、特点等以快照的形式获取，同时也完成了记录的功能，用快照完成判断，这样线程安全的问题在这一部分就得到了解决。另外对监控对象属性的改变都使用了同步方法，保证程序不会运行出预期之外的结果（SafeFile的作用）。
程序总体类的设计比较明确，快照类、监视器类、detail、summary类等各司其职，总体的大功能在监视器类中实现、分配。
这次作业中我被检测出两个bug，问题出在renamed触发器的判断中，多个文件消失，有一个不同名但其他属性相同的文件会被我判定为其他多个文件重命名后的结果。这个问题出现的原因是自己对于指导书中判断条件的理解不够全面，只是按照指导书的内容逐字逐句完成，没有考虑到同时可能存在的问题。互测阶段我分配到的作业不能完成任何一个记录功能，最终判定为了无效作业。
第七次作业
第七次作业的共享资源是100辆出租车的状态，访问资源同步做不好的话会出现严重的调度混乱，这次作业还是使用了synchronized将对出租车属性的操作同步化，各个线程相对有次序地进行调度，尽量避免顺序的混乱。
程序将出租车本体与出租车的运动、完成任务都装载在出租车类中，三秒中的窗口是一个依照呼叫请求创建出来的线程，获取出租车的状态完成派单的工作。主要的工作都由这两个类来完成大的调度，其他类实现自己管辖的功能，共同完成运行。
这次作业与之前的多线程电梯有一些共通之处，但工程量与分析难度还是下降了不少。互测阶段我出现了一些问题，首先是自己的大意，有一些输入检查没有实现，如请求出发点和目标点相同、map的输入有不合法字符等。而在多线程运行时我的程序会出现crash的问题，而这样的问题很难复现，我还在寻找出现这样问题的原因。在互测寻找bug的过程中除了按照分支树顺次检查外我主要围绕同一时间对共享资源的交叉访问进行检查。出租车的随机性导致这样的检查难度不小，最终没有找到对方的bug。
总结
总结这三次作业，我经历了一段比较艰难的过程，逐渐对多线程有了一些最简单的感知，这还远远不够，自己仍需要对自己的程序进行更多的测试。自己在大工程量的基础上对自己程序的思考和解析能力仍然需要提高。
标签：导致 除了 判断 size 资源 经历 inf 理解 方式
原文地址：https://www.cnblogs.com/ping-yuan/p/8976880.html
