OO面向對象多線程編程做業總結

第五次做業：多線程電梯調度

設計策略

​ 在本次電梯做業當中，我構造了一個電梯請求隊列線程，一個調度器線程，三個電梯線程，一個文件輸出線程，還有主線程。

​ 調度器掃描用戶的請求隊列，將每一個隊列分配給符合要求的電梯，每一個電梯有本身的請求隊列，電梯根據本身的請求隊列來改變自身狀態。

​ 同步控制主要包含兩個點：用戶請求隊列會被調度器和請求隊列輸入線程操做，須要進行同步控制，電梯內部的運行隊列也會被電梯自己和調度器操做，也須要進行同步控制。

​ 同步控制上，我用了synchronized關鍵詞和wait()與notify()的方法來實現對共享資源的線程安全操做。

度量分析及類圖

• 類圖：

• 度量分析：

在類的度量分析裏面，調度器類和電梯類的複雜度較高，接着分析方法的複雜度。

在調度器中，判斷是否能捎帶的方法複雜度較高，實際上這一部分徹底能夠經過模擬電梯按鈕來執行，在bug分析中提到。調度電梯的方法複雜度也較高，主要是要判斷電梯外的請求，分析每部電梯的累計運動量等，這裏能夠更加模塊化一些。

電梯類的複雜度主要是方法過多，每次停在某個樓層以後都要從新計算最短的捎帶請求。改變思路可讓代碼簡潔不少。

還有個人請求隊列中的run()方法當中，我把輸入的各類判斷所有寫在run當中了，這是很很差的習慣，應該讓線程的run方法儘可能簡潔，把輸入的操做模塊化。

bug分析

此次做業我在提交以前幾個小時才發現一個很重要的bug，這是我在設計思路上的一個缺陷致使的，並且指導書也沒有認真閱讀。在請求加入請求隊列的時候，若是是電梯內的請求應該直接分配給對應的電梯，不須要等待電梯都處於能捎帶或者等待服務的狀態，而我卻讓電梯內請求等待了。最後修改的時候直接將請求強行加入到電梯隊列當中，這樣又致使了捎帶問題。

實際上較好的設計思路應該是模擬真實的電梯，給電梯的每一層設置按鈕，當有請求發送的時候，改變按鈕的狀態，在每一層運行的時候都判斷按鈕是否被按下，若是是同質請求就忽略。

還有就是線程時間的控制上面有較大的偏差，不是特別精確。

發現別人的bug

此次我測試的同窗的bug主要出在格式問題上面，輸出的時候括號不少沒有按照指導書的要求輸出。

第六次做業：IFTTT文件管理系統

設計策略

本次做業中，我從主線程開啓輸入控制器，從輸入中獲取須要開啓的文件監控器，監控器線程開始對文件進行實時監控，測試線程也同時開啓，對文件進行修改操做，監控器檢測到文件的變化，將信息發送給操做線程，對相應的文件執行相應的操做。

在同步控制方面，對文件信息的讀取和修改須要進行同步操做。

還有一個stop線程是用來控制系統終止的，輸入相應的指令，系統會自動退出。

度量分析及類圖

• 類圖：

• 度量分析：

在InputHandler當中，平均操做複雜度較高，由於在判斷格式的方面寫的代碼較長，能夠考慮更加模塊化的判斷。

各個觸發器的平均操做複雜度也比較高。這也和個人設計思路有關，由於一開始沒有注意到不少觸發器須要監控目錄下全部文件的變化，因此一開始沒有對文件夾進行監控，後來增長了文件夾監控之後，代碼變得冗長。

其實能夠用嵌套循環單個文件監控的方式實現文件夾的監控，這樣寫起來會比較簡潔。

bug分析&自我分析

• bug

  在測試較深的目錄的時候，個人輸出狀況會很不穩定，好比未刪除前一次的recorddetail.txt的話很容易會不穩定，線程安全的問題沒有解決。

• 自我分析

  我把全部的類放在了默認的package裏面，這樣的架構不是很好。監控器類和操做類均可以分別放在單獨的包中，監控器類也能夠寫成繼承一個父類的方式，他們都有對文件進行監控的功能。個人程序的可拓展性和可維護性還有所欠缺。

  程序比較好的地方是用了一個Operation類來對操做進行選擇，每次只須要調用Operation，而不須要單獨調用每一個操做的方法。

發現別人的bug

對方在線程安全的設計上有所欠缺，不少文件進行了修改之後監控器能夠檢測到，可是並無進行相應的操做，致使了不少輸出是空。

第七次做業：出租車調度系統

設計策略

對於每個出租車，我都開了一個線程，每個符合要求的請求，我都會開一個調度器線程來對出租車進行調度，把符合要求的出租車加入到調度器線程的隊列當中，調度器線程運行了3s之後，從隊列中篩選出最合適的出租車並將請求發送給出租車執行，請求執行過程當中，出租車須要被上鎖，防止其餘調度器線程對出租車進行調度。

度量分析及類圖：

類圖：

此次把不一樣功能模塊放在了不一樣的package裏面，information用來存儲數據，taxi用來存儲出租車和出租車隊列，locaiton用來存儲座標和地圖，scheduler用來調度，passenger用來存儲請求隊列，輸入請求。

度量分析：

除去gui，平均複雜度最高的是taxi類，taxi的移動和狀態轉換的確須要不少函數來判斷實現，因此不可避免的複雜度升高。

bug分析&自我分析

• 起點終點一致的時候我沒有判斷錯誤，而是讓出租車進行接單。還有出租車信息文件的輸出沒有實時輸出。

  老問題，輸出的時間間隔又有偏差。發現系統的sleep方法的確會產生偏差，因此後面本身寫了個sleep的方法進行精確的控制睡眠時間。

• 原本此次做業想使用觀察者模式，可是因爲涉及的觀察者類不是不少，我用了observer和notifier之後反而使代碼變得十分冗雜，因此最後仍是放棄了使用這種方法，感受設計模式上還須要多加研究。

發現別人的bug

在線程調度的時間發現了問題，同時輸入兩條一樣的請求被當作兩個時間的請求，多是中間代碼出現了延遲。

在出租車自由行走之後，經過控制檯輸出，發現有些沒有在規定時間中止一秒。

還有尋找最短路徑的過程沒有輸出。

心得體會

一、在代碼結構和設計模式上還須要多加研究，從一開始把全部類都寫在一塊兒，到後面對不一樣類的功能分門別類，也有了一些進步。對於接口和抽象類的使用還須要多加練習，加強程序的可維護性和可拓展性。

二、在線程的控制方面，老是會在時間的精確度上出一些問題，主要是在線程的調度方面會發生一些延遲，這些問題目前尚未找到合適的解決方案，如今能作的就是儘可能簡化代碼的運行量。

三、感受每次作做業以前都沒有進行系統的學習就開始寫代碼，致使中間不少環節不會寫又要到回頭去學習，並且沒有一個總體的框架。仍是要把基礎知識鞏固才行。