一、多線程的設計

　　這三次作業的主要內容就是使用多線程並且解決多線程中出現的問題。而對於多線程我也有了自己的理解。首先明確的一點是單個CPU在同一時間只能處理一件事。那麽，不管是多進程還是多線程，我們的CPU只是在其中不停地交換執行，只不過時間太短以至於用戶感覺不到，這就是宏觀上的並行，微觀上的並行。我們的程序在啟動的時候就會創建一個主線程，而我們可以在其中繼續創建線程來完成我們的任務。

　　這樣交替執行會帶來線程不安全的問題。這樣的情況有很多，常見的狀態就是在A線程執行一個對共享資源的操作中，被B進程打斷（CPU去執行了B進程），但此時，A進程的操作並沒有結束，應該改變的某些值還沒有改變，那麽此時執行的B進程在對共享資源操作的時候必然會出現錯誤。

　　但是，多進程的使用是必然的，否則一些程序並沒有任何實際價值。於是，有多種方法可以幫助我們實現代碼的同步。Synchronized修飾符可以保證其內部的代碼塊是同步執行的，這個方法也是這三次作業中主要用到的方法。另外還有加鎖機制和喚醒機制。

二、策略與設計

1）第五次作業：三部電梯的多線程設計

　　調度器的任務就是預先判斷和分裝。在電梯中執行的時候是以每一層為粒度，到一層後掃描一遍當前電梯的隊列，執行在這一層的請求。主要涉及的線程是主線程，調度器線程和三個電梯線程。共享資源的沖突點在與三個共享隊列在不同線程之間被訪問時候的線程安全問題。於是，隊列采用了vector類。掃描器使用的是timer。

2）第六次作業：ifttt文件監控

每一個監控任務有一個成員變量是當前的snapshot（原snapshot）在每隔一定時間後，進行新的snapshot的生成，與原來的snapshot進行比較，如果滿足監控作業的要求，則輸出。主要的問題在與寫文件時候，因此采用每隔5s掃描一次的timer策略來完成。另外，此次作業采用了TestThread線程控制的測試方法，通過程序直接控制文件系統。

3）第七次作業 100輛出租車的調度

有主線程，掃描線程和調度器線程。通過設置成員變量的累計方式，控制單個出租車的狀態。

三、度量分析

　　1）第五次作業：三部電梯的多線程設計

度量結果和前兩次電梯作業的有一定的相似之處，因為調度器有繼承，這一點可以從類圖上看出來。新的調度器在重寫的command_new方法上出現了超出標準的控制流和循環。其次，在電梯類中的remsame方法中，也是有很多控制流和循環。這個方法主要是用於判斷並移除同質請求的，因為沒有設置為方法，在程序中出現了三次，且判斷過程也比較復雜，造成了電梯類內部冗余。

2）第六次作業：ifttt文件監控

主要的問題出現在比較快照的comp方法。在此方法中，需要比較四個監控作業的條件是否滿足，需要比較的前提也都比較多，而且對detail.txt文件的輸入才在這個方法中。其次就是在建立快照的run方法中，因為要實現將結果寫入summary.txt文件中，需要控制流的參與。至於ele類的參數過多這一點是服務於detail.txt文件的輸出。

3）第七次作業：100輛出租車的調度

主要問題在pathlength方法中，此方法是用bfs來計算兩點之間的最短距離，對四個方向的遍歷需要較多的控制流，且打印路徑的操作放在了此方法中，通過一個標誌變量控制。

四、bug分析

1）在三部電梯的調度中，出現了一個較大的問題，我嘗試了與前兩次不同的實現方法，結果考慮不夠周全，用錯了一個變量，使計算時間的時候產生了累積效應，在電梯類的模擬運動方法中導致時間的計算有錯誤，於是影響到了程序對到達樓層時間的預判，是一個很大的失誤。

2）在文件監控中，沒有仔細註意重命名和文件路徑移動時需要判斷是否是新產生的文件，否則就會導致我刪除一個文件卻觸發了重命名等監控器。

3）設計原則問題，在表示狀態的時候用隱含信息的數字表示。

五、發現bug的策略

1）從小處著手，測試基本的功能。

2）造成公共資源的競爭情況，通過觀察輸出之間的邏輯關系，看是否有矛盾，不合理的情況。

3）大數據的壓力測試

六、心得體會

　　經歷了這幾次作業，對線程安全問題的解決停留在同步各個方法的基礎層面上，這樣操作使得程序運行慢，有些失去了多線程的優勢。應該嘗試著縮小同步代碼塊的範圍，提高多線程的效率。

　　對於有些設計原則的理解還比較淺薄，但是設計原則確實很考驗程序員的功底。對於程序來說，僅僅實現功能是不夠的，遵循設計原則可以很好地提高代碼的復用性和可維護性。以後在設計時需要考慮這些原則，完成一個好的設計。

oo第八次作業--5,6,7次作業總結