OO第二次博客做業

做業總結分析

多線程電梯

(1)做業設計

本次做業要求完成能捎帶的3個電梯的運行；須要多線程。

此次做業每部的電梯都和以前的電梯大體相同，由請求處理後的請求隊列，請求調度，電梯來完成請求，不一樣的是此次是3部電梯同時運行。

根據需求，將輸入處理，請求分配，電梯設計爲線程。

輸入請求隊列並處理後的是須要調度的請求隊列，每一個電梯線程也擁有本身的請求隊列，便於進同質和捎帶的判斷。

(2)程序分析

本次做業的請求隊列是共享資源，輸入處理後的請求隊列和電梯須要執行的請求隊列都沒有被寫成線程安全類。

對捎帶問題上的處理有錯，本次捎帶是沿用上次電梯的捎帶方法。應該對電梯的得到的請求隊列判斷，遍歷當前請求，若是符合就放入電梯的執行隊列中。

輸出問題，將完成請求後須要輸出的信息格式不對。

 

本次做業第一次使用多線程解決需求，一開始不能理解多線程編程和之前做業的區別，致使設計時出了不少問題。因爲第一次使用多線程，對run方法的寫法上又不少不合適的地方，run方法太冗雜，對鎖的運用也很差，對共享資源的訪問處理方法都沒有加鎖。調度算法也用的很低效的，類的設計不清晰，對多線程僅有大概但不清晰的瞭解。

 

---

 

IFTTT

(1)做業設計

本次做業目的爲實現IF XXX THEN XXX的文件監控與相應操做。

程序設計分爲得到監控任務，監控事件觸發，完成相應的監控任務。

對每一個監控任務創造一個線程，每一個監控任務觸發後的的輸出建立一個輸出的線程。

(2)程序分析

在監控任務產生時，由於構造文件系統時每一級目錄下的文件都是用線性表來構造，因此每次遍歷目錄下文件時複雜度很高，上次做業的問題此次做業依舊出現，run方法的仍是很複雜，4中觸發器的判斷和3種任務的執行所有在run中進行。最大的問題是在最初設計時，僅考慮到當前目錄下文件改變的狀況，沒有考慮目錄觸發器的問題，以及目錄改變的狀況下recover任務的處理。

此次做業無效，問題在設計時考慮不全，並且run方法冗雜致使後來發現錯誤想改都改不了，在觸發path-changed的時候若是路徑改成當前目錄下的目錄中時沒法處理。在遍歷方法也很粗糙，遍歷能夠優化，例如構造時採用樹的形式。run方法的內容也能夠改的更簡便一些。

 

 

---

 

出租車系統

(1)做業設計

設計100輛出租車的搶單調度系統

大體設計爲：

乘客系統交互產生的數據：下單的地址，時間，目的地位置，是否有車接單

出租車與系統的交互：出租車當前位置，出租車狀態，信用，乘客位置，目的地位置，搶單結果

系統與乘客的交互，經過控制檯輸入每一個請求，用一個線程處理請求併爲這個請求調度出租車，100輛獨立的出租車每100ms與系統交互，反饋自身的信息，根據反饋信息在對乘客請求處理反饋，最後信息的輸出有一個單獨的線程處理。

(2)程序分析

此次做業，將全部出租車存在一個出租車數組中，可是在設計時，沒有考慮到SOLID原則，對之後的延展會有隱藏風險，還有對線程安全問題的不瞭解。

 

總結

這三次做業讓我對多線程有了一些初步淺顯的瞭解，還須要更多的學習。學習線程安全的問題。知道設計時須要知足的12個基本準則，尤爲是上次做業，要求知足SOLID原則，者要求代碼有鮮明的層次，最高層的需求與對象間的交互，再到對象信息的交互，再細節到每一個類對應的具體方法，和對類內信息的維護。