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

 

【多線程設計總結】

　　設計必定要設計好了再開始碼代碼，必定要肯在設計上花時間，千萬別急着寫代碼，設計的時候多和室友、大佬們聊聊，畢竟設計能夠兩三天，寫代碼基本上只要一個晚上。要是沒設計好就盲目動筆，這周的夜晚怕是都要在重構中度過。

 

【心得體會】

　　每時每刻都要懷揣一顆感恩的心！