OO第二单元作业总结

一：设计策略

　　第一次作业：第一次是单电梯傻瓜调度策略，因此我把调度器当作共享资源对象，有一个put和一个get方法，因为只有一个电梯，并且单次取出和投放一个请求，因此只需要同步控制一下这两个方法是互斥就行了。

　　第二次作业：第二次作业是单电梯ALS调度策略，为了我的代码能复用到第三次作业，这次我的调度器的作用就是把指令全部投放到电梯里，电梯拿到这些指令后，开始独立的决定自己的方案并执行，如此一来，第三次多电梯作业只需要写一个调度器分配请求给各个电梯的方法就行了，第二次的电梯类可以直接复用过去。基于以上的策略，可以发现同步控制的工作和第一次一模一样。

　　第三次作业：第三次是多电梯智能调度策略，由于作业二的准备(参考上段)，本次只需要写一个分配指令给电梯的调度器。虽然这次是多电梯，调度器是共享资源，但是调度器是主动分配任务的，因此只需要同步控制电梯内请求队列的访问即可，不可同时对电梯内的·请求队列投放请求以及删除请求等。同时由于输出方法是线程不安全的，多个电梯可能同时输出信息，因此需要对输出方法进行同步控制。

 

二：基于度量分析自己的程序结构

第一次作业类图以及度量图：

 

 

　　类图分析：从类图分析，第一次作业类就三个类，主线程进行输入，一个电梯类，一个调度器类，第一次作业直接采用经典的生产者消费者模型，结构简单，类较少，每个类的方法也少，每个方法的控制分支数目少，且每个类的总代码规模小。

　　复杂度分析：整个程序的ev(G),iv(G),v(G)都较低，说明这次的作业的程序圈复杂度低，结构化程度高，高内聚，低耦合。同时分析每个类的Ocavg以及WMC容易得到类的方法的平均循环复杂度和总循环复杂度低。

 

第二次作业类图以及度量图：

 

 

　　类图分析：从类图可以看出，第二次作业优点是：电梯实现了模块化，即电梯封装成了一个单独的可独立处理请求的模块，代码复用性好。但是缺点也很明显：电梯内的方法较多，个别方法的规模较大，其实是因为电梯内实现了自己的策略调度算法，以便减轻主调度器的算法复杂度并使得实现模块化设计智能调度电梯，但是调度算法解耦做的不是很好。

　　复杂度分析：程序的ev(G)（除了个别方法稍稍高）都较低，说明程序模块化设计方面还说得过去。代码iv(G)部分，除了Lift中的take和backtake方法的iv(G)较高，其他模块的iv(G)都很低，这两个方法是调度策略的核心部分，由于backtake是take的一种特例，因此在take中调用backtake，使得这两方法耦合度较高。程序的v(G)方面，依然是Lift中的take和backtake方法的v(G)高，其他方法很低，原因是这两方法是调度策略的核心部分，尤其是take方法，由于调度算法较复杂，使用了较多的if语句嵌套和for语句嵌套，使得它们的圈复杂度高。同时分析每个类的Ocavg以及WMC发现唯独电梯类的方法的平均循环复杂度和总循环复杂度高，而这两个复杂度高的原因还是来自take和backtake方法的圈复杂度高，说明调度算法的解耦做的不好。

 

第三次作业作业类图以及度量图：

 

 

　　类图分析：从类图可以看出，第三次作业的优点：第三次作业的类较少，就主类，调度器类，电梯类，类与类之间只进行消息交互，每个类都封装成了单独的模块，实现了独立的功能，整个程序高内聚，低耦合。第三次作业的缺点：第三次作业复用了第二次作业的电梯模块，因此把第二次电梯模块的缺点一起带了过来。

　　复杂度分析：模块的ev(G)基本都很低，个别方法稍高那么一点，说明这次作业模块化设计比较好，代码的可维护性好。模块的iv(G)基本都很低，只有Lift中的take和backtake方法的iv(G)较高,这是因为第三次作业直接复用了第二次作业的电梯模块，于是把这个去点带过来了，但是第三次作业实现的智能调度器的iv(G)很低，这是不错的。然后模块的v(G)和iv(G)的情况一样，绝大多数模块都很低，只有Lift中的take和backtake方法的iv(G)较高，还是复用的后遗症。每个类的Ocavg以及WMC的情况同上。从这次可以得到一个教训，代码复用具有双面性，虽然代码复用真的很爽，但是如果复用的模块的模块化设计，圈复杂度等方面设计的不好的话，这些缺点会一并带过来。总的来说这次作业抛开复用的模块外，程序的模块化设计较好，结构化设计高，模块间低耦合，模块内高内聚，每个模块的复杂度低(v(G))。

 

三：分析自己程序的bug

　　分析这三次作业的bug可以看出，自己这三次作业中公测和互测的bug总数是呈递增趋势的，并且出现的bug都是线程安全方面的bug，下面来具体分析这三次作业的bug。

　　第一次作业：第一次作业很简单，单电梯傻瓜调度策略，依据生产者消费者模型很容易解决，没有出现什么bug。

　　第二次作业：第二次作业强测没有挂点，但是互测被发现一个bug了，发现是arrayList线程不安全，arrayList的一些操作并不是原子操作，后来手动加锁后解决了这个问题。

　　第三次作业：这次作业强测挂了两个点，依然是cpu时间超了，仔细检查发现是在有些不该加锁的地方加锁了，某种特定情况下三个线程竞并且等待导致cpu时间超了。

 　综合上述分析发现，这三次的bug都是线程安全方面的bug，其中第二次作业还因为arrayList线程不安全导致的bug给了我一个启示就是写多线程的时候，不光要思考自己代码的逻辑的线程安全，还要注意自己使用的别人提供的方法的线程安全问题。

 

四：分析自己发现别人程序bug所采用的策略

　　第一次互测，使用自己写的评测机，由于第一次作业过于简单，并没有发现什么bug.

　　第二次互测，还是评测机，发现了一些bug但是提交测试用例发现无法复现。

　　第三次互测，这次变聪明了，先使用评测机发现会出现bug的测试用例，然后观察输出，找出其中的线程安全的bug所在的代码并分析，设计使得bug能复现的测试数据。

　　显然第三次的策略最为有效，第二种策略使用评测机发现bug的测试数据的话，由于是线程安全的bug，因此很大可能bug不能复现，因此第三次作业分析线程不安全的原因，手动构造使得bug能复现的测试数据。

 

五：心得体会

　　这三次作业的难度是递增的，对线程安全以及设计原则的要求也越来越高。首先是第一次作业，由于是单电梯傻瓜调度策略，故不涉及电梯间资源共享问题，由于单调度器单电梯，符合生产者消费者模型，故设计上直接采用生产者消费者模型，从而线程安全基本很容易做到。

　　第二次作业还是单电梯，只不过采用ALS调度策略，设计上则是调度器把请求全部丢给电梯，电梯根据自己的策略决定怎么做。之所以这么做是为了第三次多电梯作业的代码复用，因为如果第二次作业的电梯实现了给我请求就行了我自己决定怎么做的功能，第三次作业只需要实现调度器决定请求怎么分配给这些电梯的功能，可直接把第二次作业的电梯类复用过来就行了。线程安全则是和第一次一样，只有一个电梯，比较简单，但值得一提的是，第二次作业我没想到arrayList线程不安全最终导致我的代码线程不安全，因此以后多线程不光要考虑自己的代码线程安全问题，还要考虑点用别人的类以及方法时的线程安全问题。

　　第三次作业是多电梯智能调度。设计原则上，因为第二次作业的设计(见上段)，导致这次作业我只需要思考多电梯的线程安全问题以及调度器的分配策略即可。现在只剩下线程安全的问题了，这次的线程安全重点在于线程之间的共享资源安全问题以及线程与线程之间的竞争导致的线程安全问题，本次作业这两个问题我都考虑并解决了。但是我没有考虑到电梯之间的并发导致cpu时间过长的问题，所以这次作业自己的线程安全是安全，但cpu资源的利用也是很重要的东西，因此兼顾两者才是真正意义上的线程安全。

　　综合三次作业来说，关于设计原则上来说，自己并没有费很大功夫，相对来说比较简单，线程安全方面，后两次作业都没有做到线程很安全的地步，但是每次都发现了自己没有意识到的可能线程安全问题，使得我的线程一次比一次安全，对线程安全的理解也越来越深，总的来说是在进步的，希望以后能做到绝对意义上的线程安全。

转载于:https://www.cnblogs.com/bug2017/p/10764849.html