标签：block 内容 数据同步 crash 表达式 src 输出 间隔 没有
第五次作业是多线程电梯，线程的协同主要体现在两方面，一方面是从输入中获得请求和加入到请求队列和从请求队列中拿请求，另一方面是从请求队列中拿请求和获取电梯状态进行判断来分配请求，同步控制方法主要是对请求队列和电梯对象的方法加锁，同时通过线程sleep来确保线程间数据同步。
第六次作业是文件监视器，线程的协同主要体现在对文件状态的获取，同步控制方法是建立线程安全的文件类，这次作业的难点个人觉得不在于同步控制反倒在于IFTTT的逻辑判断比较复杂，很容易遗漏要点，对指导书的理解也十分困难。
第七次作业是出租车调度，线程的协同和电梯其实大同小异，都是控制器和输出和控制的内容之间的协同，同步控制方法也是对方法加锁和线程sleep。
三次作业，都是先思考有哪些变量是各个对象之间需要沟通和共用的，然后记录下来，在针对这些变量进行操作时新建方法并加锁，对于后期调试发现加锁无法解决的问题，就分析问题出现的位置并通过线程sleep的方式来强行解决。
三次作业下来，虽然作业完成度都还不错，但是其实对线程安全的理解个人觉得还是不够深刻，解决线程安全问题的方法无非就是给对象的方法加锁和线程sleep，以至于到上机实验遇到LinkedBlockingQueue根本不知道是什么，对锁这个概念的理解实际运用也并不是很熟练，还需要多加学习。
从上述度量可以看出，在Control类中判断请求分配和能否捎带的方法复杂度还是较高，有待改进。
从上述度量可以看出，在判断文件状态变化的方法中，由于循环、判断较多复杂度较高，有待改进。
度量
从上述度量可以看出，由于每200ms就要车辆随机路径走一次，WorkXY方法复杂度较高。
这三次作业都是自己经过思考和分解后认真完成的作业，所以整体思路比较清晰，各个类的职责也很明确，协同也比较好。但是不足之处就是对细节的欠思考，对于方法的拆分不够细致，所以还是有些复杂度较高，对于题目的细节也没有完全理解，反映到代码上就是很多判断考虑的不完整。
第五次作业自己为了时间完全按照+3+6的间隔直接将时间取整了，但是事后发现其实不取整也没有关系，被报了bug。
第六次作业由于忽略了指导书上对于输入错误的响应是要报错被报了bug。
第七次作业由于地图数组开的是80，所以下标应为0-79，但在考虑输入的时候一直想的是地图为80x80，就在正则表达式里加了80，导致了一系列crash错误。同时忽略了地图文件不存在的报错，也发生了crash。
这三次作业在设计思路上没有很大的问题，线程安全问题和协同性处理的也比较好，就是每次都在细节上出岔子，对指导书的阅读还是不够细致，在bug的调试上也是每次只看整体逻辑没有问题就停止调试，而不去看简单的输入输出的问题，导致一些很容易得到的分都被扣掉了，以后一定要注意。
个人是一个挺懒的人，这几次作业测试起来又十分麻烦，所以个人并没有用大量的数据和测试样例去测程序，都是用同学舍友找到别人bug的样例去测了一边自己的待测作业，然后就开始看别人的代码逻辑，通过看逻辑来分析别人的代码是否有漏洞。这样的方法个人觉得没什么毛病，也挺省时间的，毕竟是自己写过的程序，逻辑上都大同小异，自己注意了的点别人有没有注意到一眼也就能看出来。
至于线程安全问题的发现，主要是看别人代码该锁的地方锁了嘛，还有就是用大量的类之间需要共享的数据去测程序，看程序是否有遗漏或者顺序上的混乱。
线程安全方面就是要认真分析安全问题可能处在的位置，列出线程间共享的数据，并找到处理这些问题的合适的解决方案，然后在开始写代码。测试时着重测试想到的问题，看是否解决。
设计方面就是一定要先分析在写，逻辑不错的话程序不会有太多的bug，除非像我一样老是输入输出上弄错。
对指导书还是要认真看，尤其是要看细枝末节，最好写完之后一个一个点对着指导书比对，别在细节上犯错了。
最重要的其实还是，要！能！肝！
不肝不是计院人。
标签：block 内容 数据同步 crash 表达式 src 输出 间隔 没有
原文地址：https://www.cnblogs.com/jjjjjjjiyun/p/8971435.html
