OO近三次的作业总结

 

一． 三次作业的设计策略
从第五次作业开始，我真正接触了多线程编程（也真正打开了地狱的大门）（笑）。三次作业我的设计方式基本相同，首先思考哪些工作是可以异步执行的，比如第五次作业的三部电梯和给它们分配任务的队列，第六次作业的trigger和recorder，以及第七次作业的每一辆出租车和每一条指令；然后我们来思考工作有哪些同步的部分，这些是多线程容易出现无解bug的地方；之后再来考虑线程之间同步时的信息交换，就我三次作业的感觉来说，信息交互越少越不容易出错，共享信息越集中（集中在某一个类、某一个对象中），设计的难度就会越低（不然容易被无穷无尽的锁淹没）。三次作业我的设计变化不大，但是随着学习深入（特别是操作系统PV操作的学习），我对于wait()和notify()的认识逐渐加深，也逐渐能正确使用。
二． 三次作业分析
1. 第五次作业
(1) OO度量

(2) 类图

(3) 时序图

(4) Bug分析
这次作业的bug主要是在顺路捎带上出了一点问题，因为考虑了太多多线程的问题，最后交作业时反而忘记了顺路捎带的注意事项，导致当指令不同时输入时出现了一个bug。
这次作业整体上在设计方面做的不是很好，有些方法使用频率过高。但是从这次开始，我了解到同步会导致的安全问题（读写同步，写写同步等等），导致代码多次异常中断，让我了解到多线程安全的重要性，并且学会了一些分析和解决问题的一些方法（状态转换前输出，转换后输出来明确各个线程的状态）。
2. 第六次作业
(1) OO度量

(2) 类图

(3) 时序图

(4) Bug分析
文件操作中我对于每一项任务，都建立了一个触发器的线程和一个操作的线程（由于recover操作简单且无需输出，所以未建立线程，两行代码即可解决），但是当我要输出时却发现输出文档惨不忍睹，因为线程之间对于写的竞争导致输出变得不那么安全。后来解决方法也同样是对方法加synchronized，以此来解决冲突。
3. 第七次作业
(1) OO度量

(2) 类图

(3) 时序图

(4) Bug分析
这次作业的bug是未处理起点终点相同请求的bug以及未在选择出租车时选择路径最短的出租车，在加入最短路后，又发现由于多次求最短路的时间过长，导致等待时间拖得过长，因此对寻路算法进行一定修改，在第一次求出距离后，将距离数组保存，在下一次求同源的最短路径时，直接调用数组，从而大大缩短了时间。
三． 心得体会
对于刚接触多线程的我来说，多线程的确是很有难度的操作，每当遇到信息交换的时刻就需要思考锁应该放在哪一个位置，需不需要使用wait和notify来保证同步等等问题；特别在调试时容易碰到一些一闪而逝的问题，往往毫无头绪。我觉得，在调试过程中，碰到的任何错误，只需要一步步向前推，在每一个存在同步的角落加一行代码来输出信息，通过检查信息是否有误，就可以判断出错误发生的位置，再通过错误的信息和输出的中间信息，进而得出是哪里出现了问题。三次作业给我的感觉是，信息交流进行的越少越不容易出问题，共享信息越集中，出现的问题越容易解决。