第五次作业：三部电梯的多线程调度

度量分析：

类图：

 

度量分析中: scheduling方法是电梯调度的主要函数，由于需要依靠指令和电梯状态来判断同质与捎带等等，嵌套得比较深，另外函数体也过大，复杂度有点大

从类图中可以看出各个类之间还算均衡，电梯类比较大，主要是它要记录的一些状态及相关标记比较多，便于调度时候进行判断。本次作业我是推翻重写，虽然第二次ALS电梯的2个bug我已经改正了，不过自我感觉第二次电梯的代码十分冗余，有很多可以优化的地方，再加上这是第一次写多线程程序，不希望以前不成熟的代码对本次造成影响。写这三次电梯代码，发现每次增加一点难度，代码却并没有增加很多，甚至第三次的代码明显少于第二次电梯的代码，主要原因应该是对以前的功能更加熟悉，在代码实现的时候做了不少优化，重构了实现方法。本次作业的难点仍然是捎带和同质，由于是三部电梯，另外还有均衡原则，捎带和同质的判断以及任务分配有点复杂，最主要的是多线程的玄学问题。说实话完成这次作业的时候我对多线程的理解和运用能力还是十分不足，万幸，这次作业没有bug.

第六次作业：文件监测

度量分析：

类图：

 

 先从度量分析看起：run方法过于复杂，嵌套深；

从类图中感觉各个类还算均衡；

这次作业从我的构思开始就已经有点错误了，按照我的设计思路，每一条监测请求都开一个线程，是以那四个触发器为中心，这样的设计存在漏洞，比如同一个监测对象，如果拥有四个监测行为触发器，如果有recover行为，那其他的触发器是否触发就不可预测；另外，我没有考虑可以复制粘贴一个文件，这样的文件除了文件名，其他属性都相同，而且我触发器判断条件有漏洞，比如对于重命名文件判断，没有考虑是新添加的文件，也就是以前不存在的文件，这两个错误加起来就产生了bug.  此外，我的设计思路没有按照提示的去做，构造snapshot去扫描文件，而是每个触发器单独扫描，这样明显存在线程安全和效率问题。事实再一次证明了前期设计思路的正确与严谨的重要性；这一次作业的bug有点多，也出现了玄学问题，就不一 一 列出来了。另外这部分内容涉及到文件操作，对我来说又是一个新的知识点，文件操作的安全性考虑也蛮重要。我在百度上看到说多线程写文件要用文件锁, 本次作业的SafeFile中使用了方法锁，另外每个方法中也使用了文件锁，不过文件锁显然是多余的。

第七次作业：模拟出租车

度量分析：

类图：

本次作业的构思：每一辆出租车开一个线程，每一个有效请求开一个线程，请求线程的生命周期为3s，所以一次性输入的请求数目不能太大。另外schedule类是用来帮所有的出租车进行抢单的，抢单成功便记录下来，由请求线程进行派单。提供的GUI代码中已经提供了求最短路径的代码，不过我不喜欢用别人写的代码（读懂别人的代码要花时间，另外自己写的代码用起来更舒服，虽然效率可能不高，但自己理解），度量分析里的红色部分就是我将输入文件转换为地图，以及求两点间最短路径的代码。这次作业学到了：对象作为参数传递，以及方法中return一个对象，是比较危险的，因为传递的是对象的地址，而不是像基本类型一样复制一份，这样的话在其它地方也可以对对象进行更改。这部分内容老师早就讲过，不过我还是在实践中操作才深有体会。这次作业没有bug.