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

1、多線程的設計

　　這三次做業的主要內容就是使用多線程而且解決多線程中出現的問題。而對於多線程我也有了本身的理解。首先明確的一點是單個CPU在同一時間只能處理一件事。那麼，不論是多進程仍是多線程，咱們的CPU只是在其中不停地交換執行，只不過期間過短以致於用戶感受不到，這就是宏觀上的並行，微觀上的並行。咱們的程序在啓動的時候就會建立一個主線程，而咱們能夠在其中繼續建立線程來完成咱們的任務。

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

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

2、策略與設計

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

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

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

　　

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

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

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

3、度量分析

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

度量結果和前兩次電梯做業的有必定的類似之處，由於調度器有繼承，這一點能夠從類圖上看出來。新的調度器在重寫的command_new方法上出現了超出標準的控制流和循環。其次，在電梯類中的remsame方法中，也是有不少控制流和循環。這個方法主要是用於判斷並移除同質請求的，由於沒有設置爲方法，在程序中出現了三次，且判斷過程也比較複雜，形成了電梯類內部冗餘。

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

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

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

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

4、bug分析

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

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

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

5、發現bug的策略

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

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

3）大數據的壓力測試

6、心得體會

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

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