OO Summary Ⅱ

【第五次作业——多线程电梯】

类图

---

 度量

---

协作图

 

设计分析：

　　多线程电梯是我第一次接触多线程，因此真的是无（瞎）从（g）下（2）手（写），感觉仿佛只是用一个调度器来调度3部电梯但又总觉得好像哪里不太对，加上清明节还出去浪了三天，回来以后只感觉到深深的凉意。经过了将近一天的设计（不设计好真的是一点一点都不敢写反正也要重构），总算是把大概流程理顺清楚了：输入类(InputHandler)识别输入并生成请求(Request)后加入到请求队列(reqList)中，由调度器(schedule)每次扫描请求队列然后统一调度，将请求分配给合适的电梯(Lift)，然后电梯执行分配到的请求，并携带可以捎带的请求。

BUG分析：

　　遇到了多线程中第一个不知道该怎么办的bug，就是调度器扫描到队列中间时，如果有电梯突然变为空闲状态，就会导致中间的请求先进行分配。原本想到的策略是设置一个flag，当有电梯变为空闲时就变化一下flag，然后将调度器从头开始遍历请求队列，然后来一直都没有改好（菜得令人窒息），就只能在每次遍历后sleep个几十毫秒，因为毕竟遍历一次的时间很快很快，所以大多数情况下电梯变为空闲状态应该理论上大概都会落在调度器sleep的时候（心绪.jpg），从而大大降低了出现bug的概率（反正出现了也很难复现…）

 

 

 

【第六次作业——IFTTT】

类图

---

度量

---

 协作图

 

设计分析：

　　本次IFTTT要求仅根据文件的快照来判断文件的改变，因此每输入一个监控对象（目录或文件）就将其包含的所有文件拍一个快照存储到一个ArrayList中去，然后下一次扫描时再拍一次，对比两次快照来得出信息。

BUG分析：

　　但不知是什么神奇的原因，在对比两次快照时总会出现神奇的bug，导致有小概率出现错误对应的情况。

 

 

 

【第七次作业——多线程出租车】

类图

---

 度量

---

 协作图

 

设计分析：

　　多线程出租车总的来说感觉和多线程电梯很相似，都是按照“生产者——消费者”的模型，输入类(InputHandler)识别输入并生成请求(Request)后加入到请求队列(reqList)中，由调度器(schedule)每次扫描请求队列然后统一调度，将达到3s的请求分配给合适的出租车(Taxi)，然后出租车执行分配到的请求。

　　与电梯不同的是，电梯中处理“调度器扫描到中间需要分配而产生的问题”十分麻烦，且理论上仍存在bug，而本次在出租车中，当扫描到一个达到3s的请求时，则说明在请求队列中的、它前面的请求均达到了3s，因此break并从头开始遍历，这样就可以保证了先输入的请求先分配，只不过可能会有几毫秒的误差。

　　此外，由于指导书要求出租车按最短路径前往乘客出发地和去往乘客目的地，而计算最短路径的算法(bfs)还比较耗时间，因此若是在请求分配给出租车后再进行计算的话，累积起来会造成较大的误差。因此，本程序另开了一个计算(calculate)线程，当读入一个有效的请求后，就开始计算出发地和目的地的最短路径，从而节省时间，不过当输入足够多的请求的时候，还是会存在时间误差的问题……

BUG分析：

　　当一次输入多条请求的时候会crash然后落到UNKNOWN ERROR中，并不知道为什么……

 

【发现别人BUG的策略】

　　把自己debug的时候存下的数据给别人跑一遍就好，跑着跑着就又发现了一个自己的bug（微笑）。

 

【多线程设计总结】

　　设计一定要设计好了再开始码代码，一定要肯在设计上花时间，千万别急着写代码，设计的时候多和室友、大佬们聊聊，毕竟设计可以两三天，写代码基本上只要一个晚上。要是没设计好就盲目动笔，这周的夜晚怕是都要在重构中度过。

 

【心得体会】

　　每时每刻都要怀揣一颗感恩的心！