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

Posted 2020-11-02 Waker

还记得前三次的设计策略：星期二之前实现功能，星期三找一下可能出现的小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　

希望之后的测试者都能满怀爱心