渐入OO课的深处，探索多线程的秘密——OO第二次博客总结

一次又一次的挑战，一次又一次全新的知识，我来到了多线程的面前

---

 

第五次做业

一、度量分析

 

>第五次做业因为很大程度上调用的是前两次电梯的一些代码，因此存在的问题与前几回也十分类似。同时因为第一次使用多线程来解决问题，可能将某些功能过于集中的放在了个别类中。致使McCabe Cyclomatic Complexity以及Nested Block Depth出现标红的现象。

二、类图

>此次在类图上面问题体现的也很明显，在方法的分配上并无作的很平均。这主要是因为为第一次多线程做业，因此将大部分的功能所有赋予了elevator类中，致使类过于冗长并且类图显得特别难看。

三、关于BUG

　　当咱们在经历了三次面向对象式的JAVA编程历练之后，从最开始的一头雾水到如今的略知一二，笔者觉得本身终于已经适应了JAVA的语法与编写规范，但第五次做业的降临又让我有了泰山压顶般的感觉。最后一次电梯做业，第一次运用多线程来处理实际问题，学长学姐口中OO最难的一次做业果真名不虚传。直到周二晚上因为对多线程安全的理解不深入，笔者的程序仍然存在些许小bug。因为精力实在有限，致使最后这一点bug被搁置了。～所幸此次测试的公测仍是比较弱的，此次笔者的程序被公测和互测分别找了一个bug。公测的bug仍然在于对多线程的保护上，最终致使在多个电梯共同运行状况下运动量的计算出现了问题(3号电梯运动量被反复计算)，致使公测的这一个点挂了。而测试者此次找到的问题一样是因为多线程在运行上的不肯定性致使，而这个问题则是反映在了捎带这个功能上面，本来该捎带的一次请求因为多线程完成度的问题致使在条件判断上出现误差，没有被捎带上。此外没有被找到其余bug。而做为测试者，此次笔者拿到的程序问题仍是很多的：首先在公测的格式测试方面，他对于错误格式的判断很完善，缺在输出格式上与要求有一点不一样，而后是对于捎带和同质的判断也存在很大的问题，并且他把输出时间输出成了间隔时间，最终致使公测错了不少。不过幸运的是对于最简单的电梯和楼层请求，因为输入时间为0，因此并无错，也没有达到一个无效的条件。而在公测以外，此人还有不少的细节方面也没有作好。互测上笔者除了报告了他的输出格式错误以外，还对单行20条请求和50行总请求进行了测试，他也没有对此做出相应的错误响应。同时在一层输出多条相同到达信息他也没有处理。总之笔者认为他此次做业仍是比较失败的，不少并不难但比较细的东西没有考虑到，并且输出的错误是态度问题，笔者感受他并无很认真的对待此次多线程做业。不过此次做业着实比较困难，周围的同窗也都多多少少出现了不一样的问题，一样这第一次的多线程之旅也给咱们带来了很多的反思与经验。电梯的结束意味着新的开始，此次做业的bug就总结到这里咯。

---

 

第六次做业 

一、度量分析

>这一次做业因为主要是对文件进行一个操做，因此对于功能不管是从代码量上仍是代码难度上都不是特别的难。但在判断文件相对应的操做时须要判断的条件过于繁多，过多的if-else因此形成了程序嵌套程度过深的状况，使Nested Block Depth出现标红。而因为这些主要的判断以及其余的主要功能部分都是在Trigger中完成的，又致使过多的方法集中在了一个类中，使McCabe Cyclomatic Complexity出现标红现象。

二、类图

 

 >第六次做业的类图仍是比较清晰明确的，各个类分工也比较明确。惋惜作的很差的一点在上面的度量分析与类图中均可以反映出来，过多的功能性方法都集中在了Trigger这一个关于触发器的类之中，使这一个类特别的突兀。

三、关于BUG

　　学长们都说第五次和第六次做业是最难的两次，事实也确实如此。IFTTT，当这个陌生的词汇第一次出如今我眼帘的时候我根本不知道此次做业咱们要作的到底是什么。而OO的魅力大概就在于每一次做业咱们都须要本身去学习并探索新的知识，而此次正是对于文件的各类操做与监控。实际上此次做业不管是从代码量仍是逻辑难度上看都不高，但难就难在不清楚做业目标以及许多的新操做。不过有惊无险，此次做业的测试中笔者没有被公测和互测找到bug，而笔者测试的程序写的也十分完美。但多是没有及时收到issue上面的一些规则修改，没有对于超过10个监控对象的处理。readme中也没有响应的说明，笔者也只报了这样一个bug。随着做业的逐步深刻，测试方面也变的愈来愈困难，因此笔者没有时间也因为能力所限没法进行深层的测试，一次相对和平的做业就这样过去了。

---

 

第七次做业 

一、度量分析

 

>第一次关于出租车系列的做业，在功能上的描述与编写上并非很难。但想到并实施一个比较好的架构十分重要并且也不容易。我在深思熟虑以后才开始动工此次的做业，因此在类的分工作的十分的明确，但这个if-else的嵌套深度每一次做业都没有解决。这多是因为我经验的上的不足，没有很好的利用一些优质的算法与JDK自身函数，致使判断次数与层次过于太多，之后这方面的问题我必定会多加的注意一些。

二、类图

 

>因为是第一次出租车的做业，因此此次的类图比较简单，从名字上也能清楚的看出各个类的功能与属性。

三、关于BUG

　　在电梯以后又迎来了又一个系列性做业——出租车系列做业。万事开头难，虽然已经有了两次多线程做业的经历，但仍然对多线程的理解不够清楚，在设计与实际工做过程当中也不是说十分顺利。因为是系列做业，关系到后面几回做业的成败，因此此次做业的bug修改也是极为重要。因为人工手动测试十分困难，因此公测只放了一些输入格式上的一些错误，笔者的程序固然也没有问题。当笔者看到在互测中本身被找到的bug是同质请求出现了没有判断的状况，仔细分析之后发现是虽然在两次输入上实际的时间差是小于100ms的，但因为笔者在对每条请求处理上有些复杂，致使程序运行时间偏长，使程序中两次输入的时间差超过了100ms，没有判断为同质请求，这样是不符合实际的。因此笔者须要对此次代码做出相应优化，或者利用假时间来判断100ms，尽可能减少程序运行时间致使的偏差。另外一个bug则是测试者偶然发现当输入知足必定的条件时个人出租车信用度在计算上会出现差错，虽然如今仍然不知道具体问题是什么，但能够确定的是bug出如今信用度计算上的条件与位置一块。这就是笔者此次做业被找到的bug。相同笔者测试的程序也存在一些相似的问题：首先笔者的测试任务代码在公测方面没有判断出发点和目的点相同的状况，也就是没有忽略此类请求，这也是他公测惟一的错误。在互测上，首先比较明显的一个问题是当输入请求多于一条时，对方程序的出租车虽然会对全部请求有所响应，但每次都是在接到单以后却不去运动，笔者猜想是他在状态转化上出现了问题，致使出租车出现了不继续跑的状况。对方的第二个bug状况就和笔者的bug相似了，因为咱们都是直接使用系统时间(也就是真时间)来进行各类判断与输出，因此每次模拟出租车运行一格200ms实际程序运行超过200ms，因此在输出上会有所体现。由于结果精确到100ms，因此在必定量累积之后这个偏差量达到100ms使输出出现问题。而这个因为程序运行时间致使的偏差错误笔者在上面本身的bug处也有所说起。

　　至此，这三次做业的bug分析之旅也就结束了。

---

 

 

心得体会 

1.当步入多线程的世界，才知道这里面的路是多么的艰难。这几回做业我觉的最困难的点大体有两个，首先就是针对于一个项目的架构设计。因为是多线程的设计，因此在每次动工以前须要想清楚要创建多少个类，同时须要想多少个线程才能把这个功能作到最佳化。
2.其二就是关于多线程最重要的一环：线程安全问题。在完成代码基础功能以后，若是对线程不加以管控，每每会出现不少不合乎常理的错误，这都是由于多个线程同时运行状况下对公共资源的无管控的争夺，再加上多线程运行的不肯定性致使公共资源出现意料以外的错误。因此在功能完成后要对几个线程之间的联系做出分析，好比几乎每次做业都用到的请求队列在输入线程和调度器线程之间的共用，请求的存取就比如消费者与生产者之间的经典案例。须要对之间的纽带——请求队列进行上锁操做，而这就要对全部的共用资源所有分析清楚。固然在必定的实践与理解以后，笔者也意识到并非全部涉及到共用资源都须要上锁，有的队伍共用资源的调用只是拿到其性质或者其余的东西，并不对其进行操做与改变，这一部分的共用实际上是不须要加锁保护的。就针对于请求队列而言，重要的是对存入请求以及取出请求(删除请求)进行保护，不然会出现乱了套的状况。
3.对于多线程代码的调试也是比较有感触的一个部分。它自己的不肯定性很大程度上就决定了多线程的调试并不能依靠加断点来单步调试。因此须要灵活而巧妙地运用输出调试来找到问题的所在。并且在每一个线程的开始去进行输出标志也是屡试不爽的一个小技巧。同时多线程也有许多的好处，好比多线程能够把任务分块执行，分块后能够同时进行而不用等待。这样效率更高以下载文件，经过多线程就能够实现多文件下载。同时线程安全的实现方式也是有不少种的而我使用的Synchronized关键字：编译后会在同步块先后分别形monitorenter和monitorexit这两个字节码指令。这两个指令都须要一个引用类型的参数来指明要锁定和解锁的对象。若是没有明确指定对象参数，那就根据synchronized修饰的是实例方法仍是类方法，去取对应的对象实例或Class对象来做为锁对象。在执行monitorenter指令时，首先尝试获取对象的锁，若是没有被锁定或者当前线程已经拥有了该对象的锁，则将锁计数器加1，相应的执行moniterexit时，将锁计数器减1，当计数器为0时，锁就被释放了。若是获取对象锁失败，则当前线程就要阻塞等待。

---

 

写在最后

　　~~至此，课程已通过去了一多半，我相信你们都已经对OO和JAVA有了必定程度的熟悉与我的的感觉吧。在这里再次对全部在完成做业过程当中帮助过个人同窗以及认真负责测试我代码的同窗表示衷心的感谢。但愿你们能坚持下去，一块儿加把劲，努力去迎接新的挑战与胜利的曙光。