oo第八次做业--5,6,7次做业总结

1、多线程的设计

　　这三次做业的主要内容就是使用多线程而且解决多线程中出现的问题。而对于多线程我也有了本身的理解。首先明确的一点是单个CPU在同一时间只能处理一件事。那么，不论是多进程仍是多线程，咱们的CPU只是在其中不停地交换执行，只不过期间过短以致于用户感受不到，这就是宏观上的并行，微观上的并行。咱们的程序在启动的时候就会建立一个主线程，而咱们能够在其中继续建立线程来完成咱们的任务。

　　这样交替执行会带来线程不安全的问题。这样的状况有不少，常见的状态就是在A线程执行一个对共享资源的操做中，被B进程打断（CPU去执行了B进程），但此时，A进程的操做并无结束，应该改变的某些值尚未改变，那么此时执行的B进程在对共享资源操做的时候必然会出现错误。

　　可是，多进程的使用是必然的，不然一些程序并无任何实际价值。因而，有多种方法能够帮助咱们实现代码的同步。Synchronized修饰符能够保证其内部的代码块是同步执行的，这个方法也是这三次做业中主要用到的方法。另外还有加锁机制和唤醒机制。

2、策略与设计

1）第五次做业：三部电梯的多线程设计

　　调度器的任务就是预先判断和分装。在电梯中执行的时候是以每一层为粒度，到一层后扫描一遍当前电梯的队列，执行在这一层的请求。主要涉及的线程是主线程，调度器线程和三个电梯线程。共享资源的冲突点在与三个共享队列在不一样线程之间被访问时候的线程安全问题。因而，队列采用了vector类。扫描器使用的是timer。

2）第六次做业：ifttt文件监控

　　

每个监控任务有一个成员变量是当前的snapshot（原snapshot）在每隔必定时间后，进行新的snapshot的生成，与原来的snapshot进行比较，若是知足监控做业的要求，则输出。主要的问题在与写文件时候，所以采用每隔5s扫描一次的timer策略来完成。另外，这次做业采用了TestThread线程控制的测试方法，经过程序直接控制文件系统。

3）第七次做业 100辆出租车的调度

有主线程，扫描线程和调度器线程。经过设置成员变量的累计方式，控制单个出租车的状态。

3、度量分析

　　1）第五次做业：三部电梯的多线程设计

度量结果和前两次电梯做业的有必定的类似之处，由于调度器有继承，这一点能够从类图上看出来。新的调度器在重写的command_new方法上出现了超出标准的控制流和循环。其次，在电梯类中的remsame方法中，也是有不少控制流和循环。这个方法主要是用于判断并移除同质请求的，由于没有设置为方法，在程序中出现了三次，且判断过程也比较复杂，形成了电梯类内部冗余。

2）第六次做业：ifttt文件监控

主要的问题出如今比较快照的comp方法。在此方法中，须要比较四个监控做业的条件是否知足，须要比较的前提也都比较多，并且对detail.txt文件的输入才在这个方法中。其次就是在创建快照的run方法中，由于要实现将结果写入summary.txt文件中，须要控制流的参与。至于ele类的参数过多这一点是服务于detail.txt文件的输出。

3）第七次做业：100辆出租车的调度 

主要问题在pathlength方法中，此方法是用bfs来计算两点之间的最短距离，对四个方向的遍历须要较多的控制流，且打印路径的操做放在了此方法中，经过一个标志变量控制。

4、bug分析

1）在三部电梯的调度中，出现了一个较大的问题，我尝试了与前两次不一样的实现方法，结果考虑不够周全，用错了一个变量，使计算时间的时候产生了累积效应，在电梯类的模拟运动方法中致使时间的计算有错误，因而影响到了程序对到达楼层时间的预判，是一个很大的失误。

2）在文件监控中，没有仔细注意重命名和文件路径移动时须要判断是不是新产生的文件，不然就会致使我删除一个文件却触发了重命名等监控器。

3）设计原则问题，在表示状态的时候用隐含信息的数字表示。

5、发现bug的策略

1）从小处着手，测试基本的功能。

2）形成公共资源的竞争状况，经过观察输出之间的逻辑关系，看是否有矛盾，不合理的状况。

3）大数据的压力测试

6、心得体会

　　经历了这几回做业，对线程安全问题的解决停留在同步各个方法的基础层面上，这样操做使得程序运行慢，有些失去了多线程的优点。应该尝试着缩小同步代码块的范围，提升多线程的效率。

　　对于有些设计原则的理解还比较浅薄，可是设计原则确实很考验程序员的功底。对于程序来讲，仅仅实现功能是不够的，遵循设计原则能够很好地提升代码的复用性和可维护性。之后在设计时须要考虑这些原则，完成一个好的设计。