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（微笑）。

 

【多线程设计总结】

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

 

【心得体会】

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