一、從多線程的協同和同步控制方面，分析和總結自己三次作業來的設計策略及其變化

　　第五次：這次作業我的策略便是讀入指令一個線程、調度器一個線程、電梯三個線程，通過調度器線程將讀入指令線程讀入的指令分配給三個電梯，而三個電梯則一直在運行，檢測是否有指令產生。本次作業完全使用synchronized關鍵字進行同步控制。

　　第六次：這次作業因為指導書要求不太明確，我便放棄了讀入指令線程這個設計以達到更好地同步控制。我的設計是將指令全部讀入後，根據指令數量建立對應的監控線程，這樣一來我只需做好監控線程的同步即可，實現起來較為容易。

　　第七次：這次作業的設計又變回了第五次作業的設計策略，即讀入指令一個線程、調度器一個線程來實現指令的讀入與分配，之後讓

二、基於度量來分析自己的程序結構

第五次作業：

　　這次作業因為給電梯分配指令時要考慮的因素過多（例如同質和捎帶），因此Dispatch類寫的過於臃腫，在分配算法上可以繼續優化。

　　優點：采用Button思路使電梯運行策略變得簡單。

　　缺點：對於捎帶判斷思路不清晰導致代碼變得臃腫。

　　設計原則缺陷：責任均衡分配原則及懂我原則。

第六次作業：

　　這次作業由於涉及到線程的類只有Monitor類，導致該類責任過重成為God類。

　　優點：線程較少，同步控制容易實現。

　　缺點：Monitor類過於龐大，實現較為復雜。

　　設計原則缺陷：存在God類，責任分配均衡原則。

第七次作業：

　　這次因為調度器類只需要讓出租車搶單及派單給出租車即可，因此實現較為容易，避免了方法冗余。

　　優點：各類的職責明確，責任均衡，較好地達成了責任分配均衡原則。

　　缺點：100個出租車100個線程，稍有不慎便會卡死（例如多層while(true)嵌套）。

　　設計原則缺陷：局部化原則。Map對象在很多類中重用了。

三、分析自己程序的bug

　　第五次作業：這次作業因為是第一次接觸多線程，對synchronized關鍵字的用法不太熟練，導致指令讀入線程和調度器線程存在同步控制問題（無法正確讀取指令序列中的指令），導致其余的設計和實現時間嚴重不足，遺留了很多bug。本次作業我被發現了

　　第六次作業：本次作業被發現了一個在同一文件上實行recover和path-changed觸發器後有概率導致找不到文件而crash的bug。這個bug存在的原因是因為在讀入指令時該文件存在，但一旦修改文件後，recover會將其改回來，並且導致改名後的文件在path-changed觸發器下找不到，而我未想到這種情況，認為讀入指令時文件存在便不需考慮文件不存在的問題，因此使用了listfiles方法，但這種情況只能返回null，從而出現了crash。

　　第七次作業：這次作業被發現了一個時間輸出上的錯誤。主要是我未考慮到出租車的運行需要微小的時間，運行多了自然會產生偏差。

四、分析自己發現別人程序bug所采用的策略

　　這三次作業均未發現別人bug。策略是按照bug樹構造指令。

五、心得體會

　　這三次多線程作業做完後，我覺得我整個人都上升了一個境界。一是針對大代碼量的作業的迅速完成能力的提升，二是針對問題提出設計的能力的提升，三便是不屈不撓的毅力。尤其是多線程電梯作業，因為對多線程完全陌生，導致同步控制完全沒做，因此出現了神奇的情況——就算添加指令和分配指令是對同一個指令序列進行的操作，他就是無法正確執行，而是像玩捉迷藏一樣偶爾正確執行一次。這真是差點讓我放棄，不過後來認真學習了synchronized關鍵字的用法後，這個問題便迎刃而解了，剩下的只有一個下午以及還沒開始寫的電梯類（心累），也導致遺留了很多bug。不過熟悉了同步控制方法後，接下來的兩次作業我都做得得心應手，也沒有被同學挑出來線程安全方面的問題。第六次作業做完我最大的感受便是——都跟你說了要try-catch，因為我過於自信（其實是沒想到）自己的邏輯，導致recover觸發器的一些問題沒有考慮周全，出現了文件不存在的指針錯誤。第七次作業讓我明白了假時間的好處，我在輸出出租車運行時間時只是簡單地輸出了系統時間/100，但沒考慮到出租車運行一段時間後會有誤差這一問題，導致出現了出租車運行時間間隔為300ms的錯誤，在稍微用假時間修改後，該問題得以解決。

oo博客2