OO第二次博客做業

1、設計策略及其變化

因爲這幾回的做業應用的線程的概念，在設計上須要不光考慮到功能性的實現，更要考慮到在多線程狀況下，須要哪些線程（用戶需求），共享什麼內容（競爭資源），以及若是進行多對象的同時處理（調度安排），這樣就須要考慮到多個對象同時需求同一對象時的分配問題。一開始的做業中我使用了大量的對象鎖，可是在使用過程當中發現了範圍難以把握，經常寫成死鎖等問題，在後面的做業中利用了更多的方法鎖，將已有的方法好比ArrayList的相關方法進行封裝以構造線程安全的動態數組，這是從SafeFile獲得的靈感。在最後一次OO實驗還學習到了BlockingQueue，感受在之後的做業中能夠加以實現。

 

2、第五次做業分析：多線程電梯

度量：

度量上能夠發如今調度策略中有太高的圈複雜度。基本都是寫了for循環的嵌套，而且在其中摻雜了不少if判斷，致使整個Scheduler線程比較複雜，也能看出Scheduler這個線程的方法過多，須要精簡和分散，防止出現一個類中方法過多過於全能，寫成了面向過程的程序。

 

類圖：

類圖方面，Scheduler經過繼承前次做業的調度器，而且重寫了相關方法。Elevator實現了ElevatorCarrier的接口，在主方法裏經過構造請求隊列RequestQueue對象，三個Elevator線程，一個InputHandler線程，一個Scheduler線程來進行多線程的電梯調度。

 

UML協做圖：

 

問題及不足：

此次做業的問題主要是對於synchronized使用不當，致使出現了大量沒必要要的等待，而且鎖的範圍把控很差，致使死鎖忙等問題。在設計上不少方法寫的過於冗長，而且每臺電梯的run方法中寫的不夠精簡，致使偏差很容易出現，不過也有多是出現了大量的新建對象致使的偏差，這個是第七次做業我才發現的。

 

BUG方面：

本次做業沒有出現bug，惟一的問題就是電梯運行過程當中出現了偏差，主要緣由來自於線程wait和notifyall以及運行過程當中執行代碼所致使的偏差積累。

 

3、第六次做業分析：IFTTT文件監視器

度量：

度量上pathchange方法中因爲監控目錄的狀況中，須要進行一個for中嵌套for的遍歷，再加上不少的條件判斷致使複雜度較高，而scan方法中我本來採用的是一步一步的判斷，例如先看格式，在看數字範圍等等，這樣致使了if的嵌套，在下次做業我以爲能夠進行改變，一個check方法進行全部的判斷，即可以有效下降複雜度。

 

類圖：

類圖方面，InputHandler一個線程，Output兩個線程，每條IFTTT指令一個監控線程，另有一個測試線程用來進行文件的相關操做。本次程序經過wrap安全文件類來代替了全部的File操做，保證其線程安全。經過文件快照來掃描發生的改變而且與IFTTT的判斷條件一一比對，將觸發結果輸出到文件。

 

UML協做圖：

 

 

問題及不足：

問題主要在於本次做業中，有兩種設計方法，一個是一條IFTTT指令一個線程，一個是一個監控對象+監控條件一個線程嗎，這樣可能致使的是因爲線程過多和重複掃描，使得時間片太短的狀況下，來不及進行全部的判斷，從而落掉部分觸發指令。

 

BUG方面：

本次做業被查出了bug，來自於因爲多線程調度致使的一些IFTTT線程沒有監控到文件的變化，初步猜想是掃描時間片太短致使的。在測試他人程序時，主要採用的策略是分析代碼，因爲多線程做業結果的不肯定性，經過控制檯輸出以及文件信息的比對更能較好的看出問題，測試數據也沒有刻意的構造偏難怪的數據，大部分是基本功能的測試，小部分來自於大量數據，對多線程性能進行測試。

 

4、第七次做業分析：出租車調度

度量：

度量上覆雜度太高的是GUI中的一個方法，我也無能爲力，塊嵌套深度中search函數是在一個4*4的區域進行條件判斷，因此首先兩層for嵌套，再加上每一個點上可能存在不止一輛出租車，以及條件判斷有效性，致使複雜度較高，雖然代碼上行數不多，可是也是一個能夠優化的問題。

 

類圖：

本次類圖方面，採用了將100個出租車放入同一個線程TaxiSquad中，以保證行進的同步性。而且調度器和出租車羣經過共享實時的地圖快照進行出租車的派遣和調度，總共擁有GUI線程，出租車羣線程，調度器線程和輸入線程。這樣作的主要緣由是避免因爲線程過多致使的偏差和不一樣步。

 

UML協做圖：

 

問題及不足：

因爲上次做業出現的問題，此次刻意避免了線程過多致使的時間偏差，將100個出租車放入同一個線程，這樣的結果有好有壞，好處在於同步控制十分簡單，將100個出租車看做一個對象進行統一更新，過程當中不會發生多線程所致使的問題，好比有的出租車到達某個端點可是某個出租車沒有，在派單，搶單上就會出現問題。可是看做一個線程在必定程度上違背了多線程的意義，雖然仍然有GUI，輸入，調度和出租車羣這幾個線程，可是出租車之間並非併發的。有利有弊。

 

BUG方面：

本次做業出了一個小問題，就是在搶單過程當中，判斷了是否已經搶過單，可是加信用度的時候忘記判斷，致使屢次搶同一單每次都加了該出租車的信用，在輸出信息時就看出來了問題。這個屬於本人編程過程當中的粗枝大葉，下次必定注意。在找別人BUG時，主要是隨便跑了跑大樣本測試數據，而後經過文件輸出本身判斷他的分配策略是否合理正確。而且深刻代碼，找到分配錯誤的緣由和源代碼片斷。

 

5、心得體會：

多線程之路感受本身慢慢摸到了門道，從對象鎖到方法鎖，從wrap包裝類到學習已經處理好的線程安全類，收穫不少。

不過這幾回做業也都花費了至關多的時間，連續熬夜感受身體被掏空，而且多線程的做業難以測試和debug，致使在互測中出了或多或少額錯誤

但願可以順利完成後幾回做業，結束OO之旅