elevator、request兩個執行緒。
elevator執行緒主要負責乘客的接送和進出。
request執行緒是接收乘客資訊。
control是緩衝器，用來儲存elevator和request兩個執行緒共享的乘客佇列。
以電梯當前樓層和執行狀態為基準，如果電梯是上行的，並且高於當前樓層還有乘客要進出就上行，否則判斷是否低於該樓層有需求，如果有就下行。反之亦然，若是沒有需求，則令電梯停止。
對於乘客的排程則是到了規定樓層，能出則出，能進則進。
elevator類的五個電梯執行緒以及request執行緒。
elevator執行緒主要負責乘客的接送和進出。
request執行緒是接收乘客資訊。
control是緩衝器，用來儲存elevator和request兩個執行緒共享的乘客佇列。
基於第一次作業的單電梯，將request中獲得的乘客，平分到每個電梯中。
elevator類的若干個執行緒以及request執行緒。
elevator執行緒主要負責乘客的接送和進出。
request執行緒是接收乘客資訊。
control是緩衝器，用來儲存elevator和request兩個執行緒共享的乘客佇列，以及儲存電梯類的個數。
擴充套件personrequest類的功能，便於進行換乘操作。根據abc不同的電梯停靠樓層對接收的乘客進行分類。能夠直達的盡量直達，若是出現都能直達的情況根據abc的優先順序進行分類。若是不能直達的，則根據出發樓層abc
進行分類，換乘樓層集中在固定樓層1、5、15，便於進行操作，減少開關門的時間損失。對於同類別的不同電梯的乘客排程同第二次作業，對於電梯的執行同第一次作業。
request類主要進行生產者執行緒，elevator進行電梯的主要功能，control進行乘客資訊的排程以及儲存。三類的功能都不相同，符合單一職責的原則。在control中雖然有很多的方法，但是執行的目的都是十分簡單，還是符
合單一職責原則。
因為沒有在寫作業時，沒有考慮**的可擴充套件性，很多方法在第三次多電梯的實現中，進行了些許的調整，如果該電梯還要進行一些擴充套件操作，我想對於這些方法還是應該要進行調整。因此我覺得第三次作業的ocp原則還是不是很好。
第三次作業中我單獨寫了三個電梯類，沒有歸類到乙個父類裡面，因為在建立類，以及執行過程中都是用的電梯序號，所以沒有這方面的問題。
對於不同電梯，通過電梯索引來對電梯進行操作，在後續的幾次拓展都得到乙個很好的實現，所以相對來說介面隔離實現得比較好。但是對於電梯沒有通過屬性規範，而是獨立的建立了三個電梯類，我覺得這一方面的介面原則就處理得不是很好。
control緩衝區元素的建立依賴request的執行，elevator的執行和建立依賴control，沒有出現迴圈依賴的情況，還是很好的滿足了依賴倒置的情況。
複雜度較好，但是對於control的setupfloor方法的複雜度就比較高，這跟我的排程策略有著很大的關係，四次用到迴圈，結果作為條件的一種巢狀，都增加了複雜度，而這些在後續幾次作業都有體現。
這一次作業的的獨立性相對比較好，但是複雜度分析有很多的方法爆紅，特別是setupfloor的方法，我想應該是在該方法有四個迴圈，導致該方法的複雜度很高，而且得出的結果又會用來下一次的判斷條件，所以有乙個巢狀的複雜度，但是關於該方法的修正沒有比較好的想法。
這次作業的依賴性除了mainclass因為需要其他類來輔助執行，所以相對來說大一點其他還好。複雜度分析圖中，相比於第二次作業，爆紅的方法又加了乙個addrequest方法，因為這次作業的排程設計涉及指定樓層，在沒有找到乙個統一的方法的時候，只能通過打表的方式進行排程，我覺得或許可以通過將該函式進一步細化，得到乙個複雜度較好的函式。
互測測到的bug主要是錯誤使用了notify，隨機的喚醒執行緒使得我一些執行緒長睡不醒，改成notifyall後就不會出現這樣的隨機性了。
值得一提的是第三次作業的中測，由於對於notifyall、wait的理解不夠深入，導致我在關於wait物件一判斷就喚醒，出現了一些執行緒wait條件判斷被阻塞，導致測試re差點死於中測。但是經過這一次我好好學習了notifyall的使用，發現只有在wait物件狀態發生改變的時候，即true變成false，才能夠notifyall
。第一次作業hack到的是暴力輪詢的bug；第二次作業沒有hack到；第三次作業hack到的是re的bug，我覺得應該就是我中測碰到的那個型別的bug。
這次hack構造，主要從很長時間再來乙個人hack暴力輪詢，通過一次來很多人hack排程分配執行緒衝突。但是碰到一些評測到無法復現的bug還是感到多執行緒就是運氣的問題，但是如果乙個安全的程式不應該依賴於運氣，應該要有乙個充分的維護。與第一單元相比，這一次的作業在除錯，bug復現的難度上大大的提高，而且有時候原理搞不明白，也很難找到bug。所以我認為還是應該要細細的分析程式，通過自動測試的方式只能是一種手段，還應該從從執行緒的程度上考慮，避免阻塞的情況發生。
在這一次作業中，從執行緒安全上考慮應該要理清楚執行緒的執行順序，執行緒共享的物件。設計原則上應該盡可能的符合開閉原則，減少一些重複操作和閉合操作，防止死鎖的產生。多執行緒的體驗中，我學習到了一些設計模式，雖然理解還不是很透，但是對於多執行緒的協作感到十分的神奇，而且感覺十分的接近現實生活。而且感覺學習寫程式，不應該依賴於專有的設計架構，應該多想想多嘗試一些原理。不然再後續調bug，可能自己就算是小黃鴨講解程式，也還是不會找到程式的bug。同時這種多執行緒的使用，在過程式**中是相當難實現得，又進一步了解了物件導向程式！
OO第二單元多執行緒電梯總結
第一次作業要求完成單部可捎帶電梯的模擬。第一次作業中，我對於多執行緒程式設計理解還不深刻，只能先模仿實驗課練習的規範寫。我採用了經典的生產者 消費者模型，由input執行緒產生請求，放入排程器物件requestqueue中，然後由elevator執行緒從中取出請求執行。在排程器放入 取出請求以及結束...
OO第二單元電梯作業總結
三次電梯作業，從實現單部多執行緒 相同的多部多執行緒到可以處理增加電梯請求的不同多部多執行緒電梯，是乙個對多執行緒程式設計從無到有的指南。多執行緒程式設計的優勢和用處不必多說，在oo os理論課上老師都已有詳盡的闡釋。整體而言，在個人學習的體會中，多執行緒程式設計的難點集中在 多執行緒概念的理解 包...
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...