OO第二次博客做业

OO第二次博客做业

1.多线程协同与同步控制分析

　　第五、六、7次做业的多线程协同与同步控制基本设计思路相同，基本都是由主线程、读入处理线程、以及主要功能线程组成，不一样线程之间经过synchronized同步锁来避免多线程的冲突问题。

2.每次做业分析

第5次做业：

度量图：

 

类图

　　此次做业中，依然是负责根据输入指令改变电梯状态、运行电梯并负责输出的run方法占用的资源最多。而除此以外，因为没有采用阻塞，也就是wait()的方法，而使用了while(true)一直扫描（while中会睡眠很短的时间）直到能获取锁的方式，运行时占用的资源较多。因为继承了前几回电梯做业较为成熟的实现方式，因此运行时基本不会出现问题。

　　公测时被发现的BUG有两个，一是在报错某一种非法指令时，多输出了一个中括号。。纯粹因为本身粗枝大叶出现的问题，也感谢互测的同窗细心检查，帮我发现了这个问题。第二个问题是在同质指令输出时会报一个空指针错误，在检查代码后，发现这是在构造器中偷懒没有写this.形成的问题。。在构造器中，传入的对象名与私有属性名相同时，若是偷懒直接写a = a;在有时会出现这样的问题。

　　而我负责测试的同窗程序在我与我周围同窗的电脑上并不能运行。。只有在某一位助教的电脑上能够运行，咨询老师后，由助教进行了公测，我来填写结果（感谢助教的帮助。。）。不过该位同窗实现的功能极其有限，公测中都有许多错误的点，而且输入END并不会结束程序。但愿这位同窗能继续加油，早日走出苦海。

第六次做业

度量图：

 

 类图

　　因为多线程的多线程设计思路与前几回做业相同，因此占用资源最多的依然是负责实现主要功能的大方法run。这种设计优势在于设计思路简单，实现起来顺手，但因为线程的run方法中要负责实现要求的各类功能，每每占用了较多的资源。

　　互测时，因为此次测试的种种不方便性，而且因为写程序测试有较大的复杂度与工做量，大部分同窗都选择较为简单的测试方式，即经过编写者提供的测试线程进行一些简单测试。因此此次测试中，我与我测试的同窗都没有发现什么BUG。

第七次做业

度量图：

类图：

　　由度量图能够看到，这一次的多线程较为均衡，没有出现标红的方法，其中占用资源最多的是GUI中自带的readmap，读入地图的方法。此次的多线程注意点和前几回相同，要注意在读入某个对象的状态并进行相应判断，到给出对该对象的指令这段期间，有没有其余线程会改变这个对象的状态。

　　因为这是第一次多线程出租车，而且提供了GUI类，其中包含了bfs等实用方法，因此在实现上其实并不难，尤为是在出租车运行的规则较为简单的状况下。因此在互测中，我拿到的同窗的程序运行良好，除了全部输出都在同一个文件中，对测试者能够说极其不友好外，就是在输入错误指令、同质指令时没有任何报错提示，这一点小小的瑕疵了。而个人程序也很幸运没有被报任何BUG，感谢测试的同窗网开一面。

心得

　　随着多线程做业的不断推动，我逐渐意识到了wait、notify设计方法的优越性，并逐渐习惯了多线程各类玄学的BUG与极其不方便的DEBUG方式。最后，呼吁各位一块儿努力在OO第一线的同窗们：虽然没有把输出写的明明白白、一目了然的义务，但也恳请各位同窗们在写输出的时候为测试者多考虑一点点，毕竟每一个人本身也都将做为测试者测试其余同窗的程序，而一个一目了然、清清楚楚的输出也将为测试者带来良好的心情，也许这一点点的好心情就会成为测试者少报几个BUG的动机也说不定呢？