一、概述
本單元通過多執行緒實現電梯排程，和上一單元相比較，更加側重於執行緒的安全的模式。相較於上一單元難度有提高，整體來看，沒有第一單元的學習結果好，三次作業中第一次第二次作業比較順利，第三次作業因為執行緒安全的問題最後是無效作業，比較讓人頭痛。在排程策略上三次作業都選擇了指導書中的als排程策略，沒有更多的自己思考更高效的策略，也沒有做到像研討課上的大佬那樣，對各種排程策略進行分析，並做出視覺化的圖表，最後優中選優，選擇最好的排程策略，這是我沒有努力做到的點，本單元的作業有很多的不足之處。
二、設計策略分析
這三次作業採用的是生產者——消費者的模式，輸入作為生產者，電梯是消費者，他們之間由乙個排程器相連。排程器中維護乙個儲存請求的佇列。每次新增新的請求就把請求加入排程器佇列。排程器再把請求分給各個電梯執行。電梯內部也有乙個請求佇列，按照als原則，每次以主請求為基準來控制電梯的執行，請求佇列的請求逐漸變為電梯內部的請求，當請求輸入、排程器請求佇列、電梯內部請求佇列同時停止時，程式結束。排程器的部分方法用synchronized修飾用於解決等待佇列的同步和互斥問題。
第一次作業：單個電梯
第一次整體比較簡單，設計的時候只需要乙個生產者，乙個請求佇列作為排程器，還有乙個電梯消費者就可以。按照上面講過的方法：電梯的執行策略是，如果電梯內有請求，則優先處理電梯內請求；否則則接收電梯外最早到達的請求並執行，如果沒有請求，則電梯停在最後完成請求的樓層不變。
第二次作業：多個電梯
第二次作業增加了電梯的數量和電梯中允許搭載的人數限制。我沒有想到更多的優化演算法，就選擇使用取模的方法，將請求通過排程器平均分給每個電梯執行緒，排程策略方面沒有什麼改變，程式主要的迭代是在電梯執行緒中增加人數限制的判斷，決定是否新人可以上電梯，排程器由簡單的arraylist變成了arraylist中的每個元素仍然是arraylist，把總的請求佇列細分為不同電梯執行緒的不同專用請求佇列。
第三次作業：多種電梯
我的第三次作業是無效作業，但是應該是執行緒安全方面有一些問題，設計策略設計方法方面我覺得應該還是可以說一說的。因為涉及到不同型別的電梯，乘客可能需要通過換乘才可以到達目的樓層，我就定義了1、5、15作為三個換乘樓層。請求處理方面和第二次類似，將請求分給a、b、c三種請求佇列，再通過細化的請求佇列分給不同型別的電梯執行緒。請求分配的原則：判斷請求能不能不換乘一次完成，優先分配給不換乘的電梯，請求需要換乘的話，分配給fromfloor存在於電梯停靠樓層的電梯。每次請求分配的優先順序按照abc的順序（因為a類電梯的工作範圍大於b類，大於c類。但是沒有考慮abc類電梯的載客容量的影響以及不同種類電梯數目對整體效率的影響，還是有很多優化提高空間），每種電梯依然採取als的策略，與第二次作業不同的是在電梯可以停靠樓層上要增加一些判斷。
三、第三次作業架構設計的擴充套件性
整個電梯設計的思路一直都是生產者——消費者模式，對電梯種類的擴充套件可以通過在電梯類中增加屬性和判斷條件來實現，對電梯功能的擴充套件只需要和第一單元的作業類似，在電梯類中增加相應的方法實現就可以。對多種多數目電梯的綜合排程，大部分也只需要改變排程器中的排程方法就可以完成擴充套件和改進。總體上講，採用了適當的設計模式，那麼明顯感受到程式的擴充套件迭代性有了更多的加強。
四、基於度量的程式分析
第三次作業一直都是無效作業，所以在程式設計的時候更多一直在最後的找bug，沒有對程式進行更多的優化和提高簡潔性降低耦合度的過程，最後也沒有找出bug
第三次作業協作圖：
五、自己程式中的bug
第一次作業：第一次作業的時候沒有十分理解多執行緒的意義，在處理請求的順序上沒有按照輸入的時候就開始處理請求，而是以輸入所有請求都結束之後再開始電梯的處理，使得程式的效能極差，而且在強測中有乙個點超時。
第二次作業：更多理解多執行緒之後，改變了第一次作業中處理請求的錯誤方式，也就沒有出現bug。
第三次作業：最後應該是執行緒安全的問題，使得第三次作業無效，最後也是超時，還是對執行緒安全的理解不到位，而且發現了synchronized不能盲目修飾方法，因為修飾方法的時候就會鎖住方法中的所有this變數，更應該明確操作中需要保護的this變數，了解每一步要幹什麼。而且對執行緒的工作方法要有很好的認知掌握，不能隨便乙個方法就notifyall（），就會把剛睡的執行緒無腦喚醒，造成超時和更多的麻煩。總之需要對執行緒之間的互動、執行緒安全有比較完全的認知理解才能寫出對的程式……真的是學藝不精吃了大虧。
六、心得體會
1、程式的效能與正確性之間要做到很好的衡量，不能顧此失彼
2、選擇乙個很好的設計模式有利於後續的迭代開發
3、原來的oo作業都是想出方法之後沒有急著去完成，每次都是留出的debug時間不是很多，結果第三次作業出現執行緒安全bug最後沒有解決，作業翻車……以後oo作業要盡快努力去寫
4、學習掌握自動化測試……提高debug的能力，並且在程式設計的時候盡可能嚴謹一些，少給自己挖坑（不會自動化測試真的深受其害
5、以後的oo學習要自己學的更用心努力……多看多學，要不然真的補給站了……無效作業真的可怕
OO第二單元部落格作業
首先這三次作業總體都是關於電梯，所以電梯肯定要抽象出乙個類。然後聽老師上課說的，排程器要有乙個類。還要乙個主線程來開始其他執行緒，以及乙個用來讀取輸入的執行緒。所以總體我寫了四個類。電梯類 模擬電梯執行，持有屬性為執行速度，到達樓層，所在樓層，執行方向等，還有自己的request佇列，存放的是在本電...
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...
OO第二單元總結
共享資料類 在總結後面的3.基於度量的程式結構分析部分，本人根據展示的uml類圖更加詳細的講解了具體的協同結構工作原理。通過對實現以上操作的共享資料類中的方法設定synchronized，從而實現執行緒對共享資料的訪問同步。ocplsp ispdip 根據以上類圖，分析本次作業設計思路如下 2 根據...