南阳做网站推广,桂林漓江游船攻略,山东平台网站建设公司,西安网络科技公司一#xff1a;设计策略 第一次作业#xff1a;第一次是单电梯傻瓜调度策略#xff0c;因此我把调度器当作共享资源对象#xff0c;有一个put和一个get方法#xff0c;因为只有一个电梯#xff0c;并且单次取出和投放一个请求#xff0c;因此只需要同步控制一下这两个方法… 一设计策略 第一次作业第一次是单电梯傻瓜调度策略因此我把调度器当作共享资源对象有一个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
