第五次作业
1.度量分析
由于电梯线程需要控制自己的运行，关于运行的判断过多，if嵌套过多,if用的也太多，导致Nested Block Depth和McCabe Cyclomatic Complexity标红。
2.类图
enter线程负责输入，调度线程（sche）负责调度电梯请求，根据规则分配给各个电梯，而电梯线程（lifts）负责执行自己所分配到的请求，掌管自己的运动。其余的是一些请求类，请求队列，电梯类等等直接继承上次作业的。
3.关于bug
这次作业由于粗心，没有及时将电梯运动量传至调度线程，导致公测那个点挂了。而笔者负责测试的程序并没有发现bug。
第六次作业
1.度量分析
由于笔者的监控线程，用了过多的if语句嵌套，导致Nested Block Depth和McCabe Cyclomatic Complexity标红，此外笔者的监控线程负责整个监控器的运行，所以将太多功能赋予它了，整个类显得冗余复杂。
2.类图
监控线程（monitor）负责了太多功能，基本监控线程所有的运行方式都在monitor类中实现，导致整个类看起来相当冗余，且难看。
3.关于bug
由于之前以为Modified只是最后修改时间发生改变，但笔者以为如果最后修改时间和大小都发生了改变就不是Modified，而是size-changed，最终导致Modified树被报错，且Modified关于这部分测试也被测试者挂满了bug，实在是很可惜。此外笔者的编码格式忘记修改，不是UTF-8也被报了个incomplete，而且非法请求会占用笔者的10个线程中的名额也被报了incomplete，总之这次作业让笔者深刻认识到了细心的重要性。而笔者测试的程序这次也没有发现bug。
第七次作业
1.度量分析
笔者的taxi线程掌管其所有运行，导致这部分的代码过长，判断运行方向过多，最终导致McCabe Cyclomatic Complexity标红，此外调度线程（sche）的判断嵌套过多，导致Nested Block Depth标红。
2.类图
主要有出租车线程(taxi)以及调度线程(sche)，请求类(Request)和寻找最短路径类(即bfs类)。
3.关于bug
这次由于在乘客请求无车响应时，没有通知乘客，而被报了个bug，此外由于笔者的请求红框在GUI只会显示最后一个，这让笔者的测试者感到困惑。而笔者测试的程序这次感觉水平明显下降，公测中明显（80，80）已经超出地图范围却会继续执行，最后导致程序crash。此外程序的运行也莫名其妙。
心得体会
笔者认为多线程中至关重要的便是线程安全，如果不对线程加以控制，往往会出现很多莫名其妙的错误，这是由于线程竞争的不确定性，在第一次多线程时笔者以为加了synchronized 便能解决这个问题，现在笔者才发现线程安全更依赖于一个好的架构，不是所有的共享资源都需要加锁，另外也需要注意死锁的问题。此外笔者发现一个好的写代码风格能够极大的减少bug的出现率，另外调试bug时由于自己程序的简洁性能够一目了然哪里出现了问题。把每个类的功能具体化，分类化，这样出现bug也能很快知道哪里出现了问题。