面向对象课程第二次随笔

多线程的协同与同步控制

第五次做业

　　做为第一次多线程做业，对于多线程的同步和协同机制还不是很是了解。在此次做业中，我将三个电梯做为了三个线程，输入线程和调度器线程进行辅助。输入线程和调度器线程之间采起了很简单的生产者消费者模式来进行指令的传递。比较重要的是调度器与三个电梯之间的协同，共享资源为指令与电梯的状态。因为要考虑电梯的状态进行分配指令，电梯状态的同步是十分重要的，我在电梯类中设计了一个专门的方法返回电梯状态并将这个方法synchronized来保证调度器得到的电梯状态与实际电梯状态的同步。

第六次做业

　　此次做业的共享资源主要是目录下的文件，对目录下文件的检测与对目录的下文件的操做要同时进行。很重要的一个同步措施是设计一个线程安全的文件类来保证文件被改动时的同步性。我我的在此次设计中出现了一些问题。第一个就是线程的创建，我对于每一条监视指令，创建一条监视线程，而后这个监视线程不断地扫描监视目录下的文件，得到快照。好处是看起来没啥问题加开的线程比较少，不过实际处理中问题太多，最关键的一点是没法保证文件被操做的同步性。即便我将对文件的操做上锁，可是因为相同的文件（路径相同），在两个线程中创建的file索引是不一样的，实际上彻底没法保证线程安全。

第七次做业

　　此次做业是关于100辆出租车的叫车问题。我我的认为此次线程安全的设计，和三部电梯并无本质不一样。不一样在于调度策略以及更加合理的代码设计。关键依旧是对于出租车状态这个共享资源的控制，须要保证出租车的状态被锁住。对于每一个请求，我不喜欢每一个都开一个线程致使线程过多，个人作法是把它们放在调度器线程中，不断扫描，通过3s后自动清除。

基于度量对程序的分析

第五次做业

 

 　　以上为本次做业的代码分析，能够看到McCabe圈复杂度依然是红的，自己的方差也不算过小，可是与上一次做业相比，已经有了很大的改进。改进主要来源于对输入控制，调度和电梯类的分离。最大深度还算能够，最大的深度在scheduler类的run方法，有6层。

第六次做业

　　此次做业复杂度总体和上次类似，迭代深度略深，多是因为我采用了递归的方式来检查目录下的文件。

　　这是本次做业的类图，能够看出，此次设计比较无脑，没有仔细地规划。只是单纯地对于每一个目录创建监视线程。

第七次做业

　　与前两次做业相比，不管是代码行数，类数，方法数都有所上升。值得注意的是，圈复杂度的方差有点过大

 

　　究其缘由，Taxi类中的findNextPlace方法值得注意，这个方法是用来帮助出租车寻找下一个要行驶的地点的。因为掺杂了多种状况，甚至包括了BFS，致使复杂度很是大。下次做业考虑重写该方法，拆分其功能，下降复杂度。

　　从类图能够看出，此次做业和第五次类似，100个taxi线程同时运行，shceduler负责对他们的调配

分析本身的Bug

第五次做业

bug1:在INVALID状况下也去掉括号了，应该原版输出输入的内容

bug2:一行中指令用；隔开，对于所给输入，“；；”之间无指令应予以报错反馈,我直接当作不存在指令没有报错

第六次做业

bug1:没有忽略相同的请求

bug2:没有考虑在指令超过100条时如何处理，在超过100条时我直接选择忽略后面的指令。然而100条以内的指令有多是无效的，因此在一次性输入过多指令时会产生Bug。

bug3:递归时记录文件出现了错误，致使对文件的记录比实际上的要少。

bug4:未准确理解指导书中关于modified的定义，原来误觉得modified是只有最后修改时间变化。

第七次做业

暂时未被发现bug

发现别人Bug的策略

　　检查主要是对于测试树上节点的检查，步骤为：

　　基础功能检查---查看代码---分析共享资源---对于共享资源构造测试用例，检查线程安全---压力测试

　　因为为多个线程同时运行的程序，在压力测试和考察共享资源管理上，比较容易出现bug，缘由是线程在压力测试时开的比较多，以及共享资源致使线程不安全。

本身的分析、总结与思考

心得体会

设计原则

（1）保证类，方法的均衡性。

　　出现god类之类的东西很容易有bug发生。

（2）集中化数据管理。

　　不少时候我会将一组单独写成一个类便于管理，例如电梯的状态。

（3）在底层类实现方法，提供接口，顶层类直接调用，让本身的代码更有层次感、

线程安全

　　个人分析思路是一开始先不考虑怎样保证线程安全。首先进行类与方法的设计，而后考虑这之间的交互，找出共享资源。最后，分析如何进行一些锁，同步措施来保证线程安全。不过有些线程安全设计不是很好，单纯的用sychronized有时候会下降并发的效率。之后应该多尝试一些书上看到的更优秀的线程安全设计。