OO第二次博客做业

1、设计策略及其变化

因为这几回的做业应用的线程的概念，在设计上须要不光考虑到功能性的实现，更要考虑到在多线程状况下，须要哪些线程（用户需求），共享什么内容（竞争资源），以及若是进行多对象的同时处理（调度安排），这样就须要考虑到多个对象同时需求同一对象时的分配问题。一开始的做业中我使用了大量的对象锁，可是在使用过程当中发现了范围难以把握，经常写成死锁等问题，在后面的做业中利用了更多的方法锁，将已有的方法好比ArrayList的相关方法进行封装以构造线程安全的动态数组，这是从SafeFile获得的灵感。在最后一次OO实验还学习到了BlockingQueue，感受在之后的做业中能够加以实现。

 

2、第五次做业分析：多线程电梯

度量：

度量上能够发如今调度策略中有太高的圈复杂度。基本都是写了for循环的嵌套，而且在其中掺杂了不少if判断，致使整个Scheduler线程比较复杂，也能看出Scheduler这个线程的方法过多，须要精简和分散，防止出现一个类中方法过多过于全能，写成了面向过程的程序。

 

类图：

类图方面，Scheduler经过继承前次做业的调度器，而且重写了相关方法。Elevator实现了ElevatorCarrier的接口，在主方法里经过构造请求队列RequestQueue对象，三个Elevator线程，一个InputHandler线程，一个Scheduler线程来进行多线程的电梯调度。

 

UML协做图：

 

问题及不足：

此次做业的问题主要是对于synchronized使用不当，致使出现了大量没必要要的等待，而且锁的范围把控很差，致使死锁忙等问题。在设计上不少方法写的过于冗长，而且每台电梯的run方法中写的不够精简，致使偏差很容易出现，不过也有多是出现了大量的新建对象致使的偏差，这个是第七次做业我才发现的。

 

BUG方面：

本次做业没有出现bug，惟一的问题就是电梯运行过程当中出现了偏差，主要缘由来自于线程wait和notifyall以及运行过程当中执行代码所致使的偏差积累。

 

3、第六次做业分析：IFTTT文件监视器

度量：

度量上pathchange方法中因为监控目录的状况中，须要进行一个for中嵌套for的遍历，再加上不少的条件判断致使复杂度较高，而scan方法中我本来采用的是一步一步的判断，例如先看格式，在看数字范围等等，这样致使了if的嵌套，在下次做业我以为能够进行改变，一个check方法进行全部的判断，即可以有效下降复杂度。

 

类图：

类图方面，InputHandler一个线程，Output两个线程，每条IFTTT指令一个监控线程，另有一个测试线程用来进行文件的相关操做。本次程序经过wrap安全文件类来代替了全部的File操做，保证其线程安全。经过文件快照来扫描发生的改变而且与IFTTT的判断条件一一比对，将触发结果输出到文件。

 

UML协做图：

 

 

问题及不足：

问题主要在于本次做业中，有两种设计方法，一个是一条IFTTT指令一个线程，一个是一个监控对象+监控条件一个线程吗，这样可能致使的是因为线程过多和重复扫描，使得时间片太短的状况下，来不及进行全部的判断，从而落掉部分触发指令。

 

BUG方面：

本次做业被查出了bug，来自于因为多线程调度致使的一些IFTTT线程没有监控到文件的变化，初步猜想是扫描时间片太短致使的。在测试他人程序时，主要采用的策略是分析代码，因为多线程做业结果的不肯定性，经过控制台输出以及文件信息的比对更能较好的看出问题，测试数据也没有刻意的构造偏难怪的数据，大部分是基本功能的测试，小部分来自于大量数据，对多线程性能进行测试。

 

4、第七次做业分析：出租车调度

度量：

度量上复杂度太高的是GUI中的一个方法，我也无能为力，块嵌套深度中search函数是在一个4*4的区域进行条件判断，因此首先两层for嵌套，再加上每一个点上可能存在不止一辆出租车，以及条件判断有效性，致使复杂度较高，虽然代码上行数不多，可是也是一个能够优化的问题。

 

类图：

本次类图方面，采用了将100个出租车放入同一个线程TaxiSquad中，以保证行进的同步性。而且调度器和出租车群经过共享实时的地图快照进行出租车的派遣和调度，总共拥有GUI线程，出租车群线程，调度器线程和输入线程。这样作的主要缘由是避免因为线程过多致使的偏差和不一样步。

 

UML协做图：

 

问题及不足：

因为上次做业出现的问题，此次刻意避免了线程过多致使的时间偏差，将100个出租车放入同一个线程，这样的结果有好有坏，好处在于同步控制十分简单，将100个出租车看做一个对象进行统一更新，过程当中不会发生多线程所致使的问题，好比有的出租车到达某个端点可是某个出租车没有，在派单，抢单上就会出现问题。可是看做一个线程在必定程度上违背了多线程的意义，虽然仍然有GUI，输入，调度和出租车群这几个线程，可是出租车之间并非并发的。有利有弊。

 

BUG方面：

本次做业出了一个小问题，就是在抢单过程当中，判断了是否已经抢过单，可是加信用度的时候忘记判断，致使屡次抢同一单每次都加了该出租车的信用，在输出信息时就看出来了问题。这个属于本人编程过程当中的粗枝大叶，下次必定注意。在找别人BUG时，主要是随便跑了跑大样本测试数据，而后经过文件输出本身判断他的分配策略是否合理正确。而且深刻代码，找到分配错误的缘由和源代码片断。

 

5、心得体会：

多线程之路感受本身慢慢摸到了门道，从对象锁到方法锁，从wrap包装类到学习已经处理好的线程安全类，收获不少。

不过这几回做业也都花费了至关多的时间，连续熬夜感受身体被掏空，而且多线程的做业难以测试和debug，致使在互测中出了或多或少额错误

但愿可以顺利完成后几回做业，结束OO之旅