面向對象課程第二次博客總結

第五次做業——多線程電梯

設計策略

實現三部電梯的綜合調度，爲每一個對象線程明確任務分工。對象線程間經過發送睡眠中斷信號實現事件通訊。

Presser對象不斷讀取請求模擬按下按鈕，生成請求併發送至請求隊列中並向調度器發送新請求到達的中斷信號。

電梯對象擁有一個任務執行隊列，經過不斷檢查系統時間是否已到任務結束的假時間戳模擬執行這個任務隊列完成請求，該任務隊列由調度器負責添加新任務。電梯若執行完主請求，則暫停運行並向調度器發送中斷信號請求分配任務。

調度器對象接收到中斷信號後，嘗試到請求隊列中獲取新請求，並獲取三個電梯的狀態分配請求，更新電梯的任務隊列。

訪問衝突存在於兩個地方，一是調度器與Presser對象讀寫請求隊列，而是調度器與電梯讀寫任務隊列。那麼就須要請求隊列與電梯加鎖。

度量分析

代碼分析

類圖

 

協做圖

 

bug分析

次此做業沒有什麼大問題，互測中發現別人的程序在模擬電梯運行中直接使用真實時間模擬運行，致使由於線程調度存在阻塞，出現了累積偏差，運行一段時間後，電梯的到達時刻會有0.1秒的正偏差。在個人設計中使用的真時間模擬假時間戳，能夠消弭這樣線程運行調度引發的累積偏差。

第六次做業——IFTTT

設計策略

監控文件系統的修改狀況，一個監控對象的一種修改狀況，對應設立一個觸發器線程，觸發器下可吊掛多個效應器。

每一個觸發器線程輪詢文件系統，比對新舊快照，判斷觸發條件，若觸發則啓動該觸發器下掛的效應器。

訪問衝突在於觸發器要讀文件系統，效應器可能要寫文件系統，那麼爲文件系統加鎖，簡單的synchronized悲觀鎖會互斥任何針對文件系統的操做，但其實咱們但願的是，多個讀者間是不互斥的，只有讀寫者、寫寫者間保持互斥，這種加鎖方式比較複雜，須要用到閘機模型，當時也不知道閘機模型，因此仍是用的synchronized鎖。

度量分析

代碼分析

 

類圖

 

協做圖

 

bug分析

這次做業沒有什麼大問題

第七次做業——模擬出租車

設計策略

模擬100輛出租車載客運行。設計徹底模擬現實生活中的場景，爲每一個對象作明確合理分工，各作各事。

InputerHandler對象負責讀取請求並將請求發送至請求隊列。

調度器對象負責從請求隊列中獲取新請求，併爲每一個新請求生成車輛搶單用的報名表，掛靠在地圖上的相應的請求出髮結點上，供過往的出租車搶單報名。搶單窗口關閉後，根據報名表上登記的搶單車輛信息和其目前的狀態，爲請求分配車輛。

出租車的任務是在城裏閒逛，並查看附近地圖結點下掛靠的搶單報名表，參與搶單填寫本車信息，等待派單。如成功搶單，則執行送客任務。送客結束後重覆上訴操做。

訪問衝突在於調度器要在地圖節點下發放和收取報名表，出租車要在地圖節點下查看和填寫報名報，所以爲地圖上的每個結點加訪問鎖。

度量分析

 代碼分析

 

類圖

 

協做圖 

 

bug分析

這一次程序在總體設計上沒有什麼大問題，只是出現了兩個由於粗心致使的小bug。測試對面的程序時再一次出現了相似第5次做業的時間偏差問題，被測程序直接使用真實時間模擬出租車的運行，由於線程調度的問題，有的車的運行時間就開始出現累積偏差了。

心得體會

資源訪問的安全問題是多線程設計的重要問題之一，在最初的設計過程當中，就要作細緻的分析和全面的考慮。首先要研究每個對象的讀寫行爲，尋找對象間的讀寫衝突點，並要根據不一樣到的讀寫特徵選擇適當的加鎖方式，以免過多的線程阻塞致使的效率降低，而不是隻會簡單的使用sybchroniezd鎖。好比讀者線程明顯多於寫者線程的狀況下，就要考慮設計讀者間的不互斥鎖，不然的話，多個讀者進程就會都被阻塞在臨界區外，加劇了調度負擔，也消磨了多線程併發執行所帶來的優點。

一個好的事前設計會給之後的工做不管是編碼仍是維護帶來加速型的回報。可是事先設計也不可能考慮到全部的問題，不少問題是在編碼過程當中或是實際的測試中發現的。所以在編碼完成填補bug時，不能只着眼於局部的問題處理，而是要結合總體設計判斷是否找到了問題的根源，及時的作好新的註釋，必要的話還須要從新整合設計，避免出現拆東牆補西牆，按下葫蘆浮起瓢的狀況，致使原本一個較好的總體設計，最終被改得面目全非，使得往後的代碼維護變得十分困難。好比如今會看多線程電梯時，大致的設計仍是看得明白的，但出現了不少細節的地方就看不明白了。這也提醒咱們，設計並非只存在編碼以前，在編碼時也有不斷的動態設計，在編碼結束後，也要回顧總體設計，針對新的問題對設計作更合理的抽象整合和重構。