标签：文件监控 mil 个人 方便 线程安全 lib 扫描 时间差 height
第五次作业——多线程电梯
设计策略
本次作业共有五个类，构造了输入线程、调度器线程和三个电梯线程。输入线程负责将请求加入到请求队列里面；调度器线程负责按照给定的规则，判断将请求队列里的请求分配给哪个电梯；电梯线程负责电梯的运行及输出。
OO度量
程序的bug
1、在时间的处理方面，电梯每上升、下降一层或开关门一次，就让其sleep三秒或六秒，但这种方法会带来时间差的问题，如果让电梯sleep的时间为3/6秒减去当前系统时间和上一次停靠的系统时间之差，就能解决这个问题了。
2、这次作业调度器没有继承上次作业的调度器，算作imcomplete类bug。
3、未完成捎带功能，导致电梯只能按照傻瓜电梯的方式运行。
测试代码的bug
被测试者提交的是第三次作业的代码...
第六次作业——IFTTT
设计策略
本次作业为每个监控对象建立一个线程。在输入时，先将请求保存在请求队列里面，以便删除相同请求。在忽略不符合要求和相同请求后，为每个监控作业建立一个线程。监控线程每隔一个周期检查一次相应的监控对象是否发生改变，若改变，则按照规范将信息输出到文件里。
文件监控类里保存了上次扫描后文件的各个信息，便于和下次扫描进行对比。文件监控类里有四个方法，分别对renamed、size-changed、path-chaged和modified进行监控。size-changed和modified只需要比较文件大小和最后修改时间。renamed和path-changed需要对整个目录进行扫描，按照指导书的说明，也不难实现。
不过这次作业忽略了目录的变化，只实现了对文件的监控，导致公测点错的有点多。
OO度量
程序的bug
1、对于recover，在复原文件时，没有之前的文件删掉。
2、由于忽略了对目录的监控，公测和目录有关的公测点都未通过。
测试代码的bug
被测试者的代码写得十分规范，对文件和目录的监控写得都十分完善，在阅读完readme和代码后，并没有发现什么bug。通过阅读别人的代码，我也找到了自己的bug所在，学习了目录监控的方法，让我受益匪浅。
第七次作业——出租车
设计策略
本次作业多线程电梯类似，构造了输入线程、调度器线程和100个出租车线程。输入线程负责输入，并将请求加入到请求队列里面；调度器负责判断请求的抢单窗口是否结束，如果结束，则将请求分配给满足要求的抢单出租车。出租车线程负责与出租车运行有关的所有方法，包括随机移动，移动后是否抢单，抢单后按照最短路径前往始发地，到达目的地。
本次作业输出方面，为了方便，我将请求的内容，抢单车辆的信息这些即刻可以输出的内容输出到一个文件，将抢单车辆的具体运行信息输出到taxi.txt文件中，这样每个出租车对应一个文件，避免了放到一个文件里输出乱序的情况。
OO度量
程序的bug
1、在公测和互测中，测试者没有找出bug。但我自己在测试的过程中，发现如果在同一时间输入多条请求，程序有可能会输出“地图不是连通的”，报错并结束。现在还没有发现原因所在，由于本次作业寻找最短路径使用了gui中的方法，不知道是不是gui的线程安全做得不过好导致了这个bug的产生...
2、由于我采用sleep（200）的方法来让出租车每200ms移动一次，但是由于程序执行需要时间，导致移动时并不是精确的200ms。
测试代码的bug
1、测试代码中出租车随机移动算法对地图边界的处理有误，导致每当出租车和运行到地图边界，该出租车线程就会crash。
2、被测试者并没有将出租车运行情况输出到文件，并且没有在gui上显示出出租车状态的变化，导致判断程序是否正确特别困难。
3、测试者没有提供按照状态查询出租车和按照出租车查询相关信息的测试接口。
个人心得
1、多线程确实很难，多线程程序在运行时可能会出现许多无法解释的问题，所以做好线程安全十分重要。
2、全面分析，先设计好程序的框图，再去实现。这几次作业出现了许多写到一半发现思路不对，又得重写的情况，所以不能感觉花时间去设计思路是浪费时间，相反，这是最有效的一种方式。
3、合理分配时间，不要轻言放弃。在第五次作业中，由于前几次作业和该次作业不符，需要完全重构，而清明由于贪玩，导致没有时间去实现捎带功能。曾一度想过放弃，但是困难再大，也要去努力克服。后面几次作业，再接再厉，继续前行。
标签：文件监控 mil 个人 方便 线程安全 lib 扫描 时间差 height
原文地址：https://www.cnblogs.com/ycl1606/p/8977934.html
