面向對象課程第二次隨筆

多線程的協同與同步控制

第五次做業

　　做爲第一次多線程做業，對於多線程的同步和協同機制還不是很是瞭解。在此次做業中，我將三個電梯做爲了三個線程，輸入線程和調度器線程進行輔助。輸入線程和調度器線程之間採起了很簡單的生產者消費者模式來進行指令的傳遞。比較重要的是調度器與三個電梯之間的協同，共享資源爲指令與電梯的狀態。因爲要考慮電梯的狀態進行分配指令，電梯狀態的同步是十分重要的，我在電梯類中設計了一個專門的方法返回電梯狀態並將這個方法synchronized來保證調度器得到的電梯狀態與實際電梯狀態的同步。

第六次做業

　　此次做業的共享資源主要是目錄下的文件，對目錄下文件的檢測與對目錄的下文件的操做要同時進行。很重要的一個同步措施是設計一個線程安全的文件類來保證文件被改動時的同步性。我我的在此次設計中出現了一些問題。第一個就是線程的創建，我對於每一條監視指令，創建一條監視線程，而後這個監視線程不斷地掃描監視目錄下的文件，得到快照。好處是看起來沒啥問題加開的線程比較少，不過實際處理中問題太多，最關鍵的一點是沒法保證文件被操做的同步性。即便我將對文件的操做上鎖，可是因爲相同的文件（路徑相同），在兩個線程中創建的file索引是不一樣的，實際上徹底沒法保證線程安全。

第七次做業

　　此次做業是關於100輛出租車的叫車問題。我我的認爲此次線程安全的設計，和三部電梯並無本質不一樣。不一樣在於調度策略以及更加合理的代碼設計。關鍵依舊是對於出租車狀態這個共享資源的控制，須要保證出租車的狀態被鎖住。對於每一個請求，我不喜歡每一個都開一個線程致使線程過多，個人作法是把它們放在調度器線程中，不斷掃描，通過3s後自動清除。

基於度量對程序的分析

第五次做業

 

 　　以上爲本次做業的代碼分析，能夠看到McCabe圈複雜度依然是紅的，自己的方差也不算過小，可是與上一次做業相比，已經有了很大的改進。改進主要來源於對輸入控制，調度和電梯類的分離。最大深度還算能夠，最大的深度在scheduler類的run方法，有6層。

第六次做業

　　此次做業複雜度總體和上次類似，迭代深度略深，多是因爲我採用了遞歸的方式來檢查目錄下的文件。

　　這是本次做業的類圖，能夠看出，此次設計比較無腦，沒有仔細地規劃。只是單純地對於每一個目錄創建監視線程。

第七次做業

　　與前兩次做業相比，不管是代碼行數，類數，方法數都有所上升。值得注意的是，圈複雜度的方差有點過大

 

　　究其緣由，Taxi類中的findNextPlace方法值得注意，這個方法是用來幫助出租車尋找下一個要行駛的地點的。因爲摻雜了多種狀況，甚至包括了BFS，致使複雜度很是大。下次做業考慮重寫該方法，拆分其功能，下降複雜度。

　　從類圖能夠看出，此次做業和第五次類似，100個taxi線程同時運行，shceduler負責對他們的調配

分析本身的Bug

第五次做業

bug1:在INVALID狀況下也去掉括號了，應該原版輸出輸入的內容

bug2:一行中指令用；隔開，對於所給輸入，「；；」之間無指令應予以報錯反饋,我直接當作不存在指令沒有報錯

第六次做業

bug1:沒有忽略相同的請求

bug2:沒有考慮在指令超過100條時如何處理，在超過100條時我直接選擇忽略後面的指令。然而100條以內的指令有多是無效的，因此在一次性輸入過多指令時會產生Bug。

bug3:遞歸時記錄文件出現了錯誤，致使對文件的記錄比實際上的要少。

bug4:未準確理解指導書中關於modified的定義，原來誤覺得modified是隻有最後修改時間變化。

第七次做業

暫時未被發現bug

發現別人Bug的策略

　　檢查主要是對於測試樹上節點的檢查，步驟爲：

　　基礎功能檢查---查看代碼---分析共享資源---對於共享資源構造測試用例，檢查線程安全---壓力測試

　　因爲爲多個線程同時運行的程序，在壓力測試和考察共享資源管理上，比較容易出現bug，緣由是線程在壓力測試時開的比較多，以及共享資源致使線程不安全。

本身的分析、總結與思考

心得體會

設計原則

（1）保證類，方法的均衡性。

　　出現god類之類的東西很容易有bug發生。

（2）集中化數據管理。

　　不少時候我會將一組單獨寫成一個類便於管理，例如電梯的狀態。

（3）在底層類實現方法，提供接口，頂層類直接調用，讓本身的代碼更有層次感、

線程安全

　　個人分析思路是一開始先不考慮怎樣保證線程安全。首先進行類與方法的設計，而後考慮這之間的交互，找出共享資源。最後，分析如何進行一些鎖，同步措施來保證線程安全。不過有些線程安全設計不是很好，單純的用sychronized有時候會下降併發的效率。之後應該多嘗試一些書上看到的更優秀的線程安全設計。