OO生存指.....抱歉没法生存

还记得前三次的设计策略：星期二以前实现功能，星期三找一下可能出现的小bug。

这三次以及变成了：星期二以前能跑出来就行。

整体来讲设计策略是：先让几个线程可以顺利运行，再开始实现功能。

在接触到多线程以后，我已经没有前三次做业的余裕了（虽然前三次也不怎么有）。

还生存个鬼嘞，不无效就好了吧 = =

---

 第五次做业：多线程电梯（三电梯）

据说是全部做业中最难的一次了，事实上也彻底对得起这个名号。此次做业对设计架构，线程安全的要求都是至关高的。并且对于测试来讲，由于三线程电梯的随机性实在不高，测试时很明确，也提高了此次做业写出来的难度。比起来以后的出租车随机性更高一点，固然没有电梯这么难设计了。

放在第五次的理由，大概一是有足够的时间清明假期（不让好好的过清明），二是有个单线程电梯的基础。可是我仍是以为放在第五次不太稳当，毕竟让一个彻底没接触过线程的人，一个星期的时间写出来这样的一个工程实在要求过高。并且像我这种菜鸡，在这么短期，要理解线程，线程安全和同步之类的能够说是天方夜谭了。

事实上在此次做业以前我彻底没想过可以一星期“速成”JAVA多线程，好在最后牺牲了很多的睡眠时间是作出来了，虽然时间太紧作的也不怎么样。

设计策略：

多线程按照指导书设计，三个电梯各一个线程，调度器一个线程，输入一个线程。

此次比起第三次ALS的电梯改动仍是挺大的，最明显的是调度器再也不是一个GOD类，电梯的运动也是分配给了elevator类。

然而提及来容易，实施起来确是无比困难。

首先是我对线程彻底不清楚，全靠速成。以至于刚开始跑的时候，一度由于while(true) 而卡死，eclipse崩溃，CPU的占用率100%。

其次知道了线程不能直接这样，使用了wait来使线程中止，具体说来即让调度器在请求队列为空时中止工做。

另外对每个电梯都构造了一个请求队列，电梯直接根据这个队列来跑便可。因此此次做业，在相互的睡眠与唤醒，花了很多功夫。另外这样会有不少共有元素，所以线程安全也很重要。为了解决输入END中止线程，我甚至还特意开了个类传递参数。

最后在调度上一度出现问题，最后发现是根据电梯状态来判断分配延迟太大，又来改分配。在星期三下午还临时改了分配掉地策略。致使最后出来了不少以前没有，意想不到的bug。

回首起来此次做业真是一次惨痛的经历，也是多线程痛苦的开始。

度量分析：

 

 

类图：

使用ctrl + 滚轮 获取最佳观赏效果。

协做图：

 

能够看出来，度量分析有三个点飘红了。

圈复杂度和嵌套复杂度很高，这也是情理之中的。毕竟这个sendInLine方法大部分是沿用上次的电梯的，上次都飘红了，然而并无时间来优化上次代码，此次飘红也正常。

另外一个点是类的属性过多。问题出在调度器类中，传了很多参数。

可是在此次难度的重压下，对于我这个菜鸡来讲，优化实在不大现实，毕竟debug就要花上很多时间。在bug都没法解决的状况下没办法去面对优化和设计原则的。

因此写完以后，缺点一大堆，bug多并且设计也很差。惟一的优势可能就是写出来了。

BUG总结：

本身的bug：一堆

时间有偏差（还好公测没有出现），这个实在很难避免，在时间不足的状况下我也没办法处理了。

同层应该捎带未捎带，多开了一次门。

STILL状态下不能捎带。

上述两条是由于我开始按照电梯状态来判断捎带，出问题后，临时改为按照另外的方式，可是没有测试，因此出现了bug。

ER请求有一个捎带不上，不知道缘由，多是由于锁？

 

下家的bug：也是一堆，还更多

公测运动量没有按照最小的来分配。

同质请求判断出了问题。

同层请求多于一条，捎带不上。这个是由于按照电梯状态判断，中间有时间偏差，对于同时输入的请求没法及时正确分配。

此外还出现了一个crash，是线程中出现了问题。

 

测试策略什么的，不存在的，毕竟随便一找就是一堆bug。

---

第六次做业：IFTTT（文件监控器）

最迷的一次，比多线程电梯还迷。

若是说多线程电梯在星期一已经大体跑出来多线程只是bug不少，此次IFTTT在星期一连个架构都没有，在星期二才能大体跑出来。晚上一边听凉凉一边写完了。

虽然难度不及多线程电梯，可是时间紧迫，并且指导书不知所云，光是理解指导书就要费很多功夫。

此次做业说是训练对线程安全的应用，实际上写完以后，除了一个SafeFile类，根本没发现线程安全在哪里有应用。对线程安全的要求，比上次多线程电梯差远了，甚至比不过出租车。因此彻底不能理解此次做业的意义何在。干脆说是对文件类的训练彻底不为过。

另外但愿下届此次做业指导书能更清晰，不要朝令夕改，毕竟星期三下午还要改需求让咱们仍是挺难受的，作好测试时候测试点和设计需求的平衡，最好直接删除IFTTT此次做业。

 

设计策略：

输入一个线程，每个 “触发器-任务” 对 对应一个线程，即为每个监视器开一个线程，最多可能100个。

此外为detail和summary单开了两个线程。

线程安全问题，发现只要用的是SafeFile，不会由于线程安全而出错，出错的只多是实现上的。

因此最困难的仍是实现，线程安全我基本上没注意到然而也没有出问题。

度量分析：

 

 

类图：

使用ctrl + 鼠标上滚轮获取最佳观赏效果。

协做图：

飘红的点是圈复杂度和嵌套深度，所有出在rename方法上（除了这个方法估计就是path-changed方法）

由于一个方法中涉及的太多。这也跟设计策略有关，由于每个线程对应的一种方法。除此以外，快照snapshot也在方法中进行，所以这圈复杂度和嵌套深度都很高。

BUG总结：

虽然本身感受写的不是很好，应该会有bug，然而实际被测试中并未被找到bug，也是很值得高兴的。

测试下家过程发现了两个bug，公测发现监控文件夹renamed的recover没法恢复，在监控文件夹path-changed的recover也没法恢复。另外一个bug是监控文件夹modified，在size-changed同时不会触发。

至于测试策略，按树测吧。毕竟除了树也没什么好测的。（树上的也不能所有测完）

---

 第七次做业：傻瓜出租车

据说是简单了，然而实际上动手的时候发现本身又被骗了。

不过比起最难的多线程电梯，以及最迷的IFTTT来看，确实是简单了点。虽然没简单到比前三次简单就是了。

总体思路和架构由于有了多线程电梯，看起来不是那么困难了。并且实现上由于有随机性，因此更不会跟电梯同样有明确的bug可寻。

可是花的时间并无减小太多。。。。。

 

设计策略：

彻底按照电梯的思路，输入一个线程，调度一个线程，此外把100个出租车单开一个线程。

此次调度比电梯简单的缘由是分配任务后没捎带，也就是说没必要再考虑出租车的调度，直接让出租车运行便可。不会像电梯同样，分配了任务以后，电梯还要考虑到本身被分配的任务来运行。

设计看起来不太难，主要仍是实现部分。

度量分析：

 

 

类图：

使用ctrl + 鼠标上滚轮获取最佳观赏效果。

协做图：

 

第一个飘红的点圈复杂度来自GUI ？ 就不作评述了。

后面嵌套深度过深来自run方法，应该是scheduler的run方法。这块写的太复杂了致使飘红。

此次由于有设计原则的限制，在设计上稍微下了点功夫。所以自我评价还行。

BUG总结：

己方惟一bug仍是时间的偏差，没法作到很精确的200ms，感受要实现仍是很困难的。

对方的bug除了个人以外，还有加信用时间没有作到与指导书相同。

此次的测试策略仍是按照树测，由于随机性过高，找不到其余测试方法。

---

 心得与体会：

 1.先说下收获。从清明以前，彻底不知道多线程为什么物，在寝室啃着教程学习多线程，到现在已经能写出三个多线程程序，要说内心面没有点成就感是不可能的。

最大的收获就是对多线程有了必定的理解，不像一开始同样，漏洞百出，什么都不会，写一段代码能把电脑炸半天。如今不只能写出来多线程程序，对多线程的debug也有计可施。也对多线程安全有了必定理解。

2.对于线程安全的理解，不只仅只是用synchronized简单锁一下方法，一开始用这个方法在debug过程当中吃了很多亏。什么时候synchronized，什么时候wait，什么时候notify，须要开始就有一个大致的把握。

3.因此在设计线程的时候就要考虑好线程同步问题，否则debug会有苦头吃。

4.至于设计原则，虽然在开始几回比较困难的时候，真的是没有时间来考虑本身的设计。可是在还算充足时间的出租车上，一个好的设计做用仍是很大的。

5.有得也有失。失去的睡眠时间和头发固然微不足道，真正令我心痛的是失去的其余课程的时间。由于花了太多时间在oo上，os前一天基本没有时间复习os的理论，实验也只是粗略的看看。致使os次日的考试一塌糊涂，三次实验上机挂了两次，这是让我最遗憾的。但愿后来人能协调好oo与os的时间。也但愿oo的课业压力可以小一点点，熬夜真的不算什么，可是我真的不但愿os挂科。。。。。

 

 

6.....大概不算一点吧

感受Avicii的waiting for love 挺符合oo的意境的

Monday left me broken
Tuesday I was through with hoping
Wednesday my empty arms were open
Thursday waiting for love, waiting for love　

但愿以后的测试者都能满怀爱心