OO第二次博客做業

OO第二次博客做業

1.多線程協同與同步控制分析

　　第五、六、7次做業的多線程協同與同步控制基本設計思路相同，基本都是由主線程、讀入處理線程、以及主要功能線程組成，不一樣線程之間經過synchronized同步鎖來避免多線程的衝突問題。

2.每次做業分析

第5次做業：

度量圖：

 

類圖

　　此次做業中，依然是負責根據輸入指令改變電梯狀態、運行電梯並負責輸出的run方法佔用的資源最多。而除此以外，因爲沒有采用阻塞，也就是wait()的方法，而使用了while(true)一直掃描（while中會睡眠很短的時間）直到能獲取鎖的方式，運行時佔用的資源較多。因爲繼承了前幾回電梯做業較爲成熟的實現方式，因此運行時基本不會出現問題。

　　公測時被發現的BUG有兩個，一是在報錯某一種非法指令時，多輸出了一箇中括號。。純粹因爲本身粗枝大葉出現的問題，也感謝互測的同窗細心檢查，幫我發現了這個問題。第二個問題是在同質指令輸出時會報一個空指針錯誤，在檢查代碼後，發現這是在構造器中偷懶沒有寫this.形成的問題。。在構造器中，傳入的對象名與私有屬性名相同時，若是偷懶直接寫a = a;在有時會出現這樣的問題。

　　而我負責測試的同窗程序在我與我周圍同窗的電腦上並不能運行。。只有在某一位助教的電腦上能夠運行，諮詢老師後，由助教進行了公測，我來填寫結果（感謝助教的幫助。。）。不過該位同窗實現的功能極其有限，公測中都有許多錯誤的點，而且輸入END並不會結束程序。但願這位同窗能繼續加油，早日走出苦海。

第六次做業

度量圖：

 

 類圖

　　因爲多線程的多線程設計思路與前幾回做業相同，因此佔用資源最多的依然是負責實現主要功能的大方法run。這種設計優勢在於設計思路簡單，實現起來順手，但因爲線程的run方法中要負責實現要求的各類功能，每每佔用了較多的資源。

　　互測時，因爲此次測試的種種不方便性，而且因爲寫程序測試有較大的複雜度與工做量，大部分同窗都選擇較爲簡單的測試方式，即經過編寫者提供的測試線程進行一些簡單測試。因此此次測試中，我與我測試的同窗都沒有發現什麼BUG。

第七次做業

度量圖：

類圖：

　　由度量圖能夠看到，這一次的多線程較爲均衡，沒有出現標紅的方法，其中佔用資源最多的是GUI中自帶的readmap，讀入地圖的方法。此次的多線程注意點和前幾回相同，要注意在讀入某個對象的狀態並進行相應判斷，到給出對該對象的指令這段期間，有沒有其餘線程會改變這個對象的狀態。

　　因爲這是第一次多線程出租車，而且提供了GUI類，其中包含了bfs等實用方法，因此在實現上其實並不難，尤爲是在出租車運行的規則較爲簡單的狀況下。因此在互測中，我拿到的同窗的程序運行良好，除了全部輸出都在同一個文件中，對測試者能夠說極其不友好外，就是在輸入錯誤指令、同質指令時沒有任何報錯提示，這一點小小的瑕疵了。而個人程序也很幸運沒有被報任何BUG，感謝測試的同窗網開一面。

心得

　　隨着多線程做業的不斷推動，我逐漸意識到了wait、notify設計方法的優越性，並逐漸習慣了多線程各類玄學的BUG與極其不方便的DEBUG方式。最後，呼籲各位一塊兒努力在OO第一線的同窗們：雖然沒有把輸出寫的明明白白、一目瞭然的義務，但也懇請各位同窗們在寫輸出的時候爲測試者多考慮一點點，畢竟每一個人本身也都將做爲測試者測試其餘同窗的程序，而一個一目瞭然、清清楚楚的輸出也將爲測試者帶來良好的心情，也許這一點點的好心情就會成爲測試者少報幾個BUG的動機也說不定呢？