乘客的請求資訊：起點層和終點層不同，起點座和終點座相同。如1-from-a-1-to-a-2
思路：採用look策略。若同方向上沒有請求且電梯裡的乘客的目的地都在反方向，則轉換電梯執行方向。（捎帶前往目的地與電梯執行方向相同的乘客）
uml類圖
自己程式的bug
輸出時間戳沒遞增
乘客的請求資訊：[起點座 == 終點座] + [起點層 == 終點層] == 1，即樓座和樓層兩者中有且僅有乙個相同。如1-from-c-7-to-a-7
思路：橫向電梯的排程策略與look策略類似。（優先捎帶前往目的地與電梯執行方向相同的乘客，再捎帶在當前層等待進入電梯的乘客）
採用自由競爭。縱向電梯加上橫向電梯，總共有15種電梯。排程器根據電梯的型別分別把同型別的電梯請求分配進同乙個processingqueue，再由同型別的幾個電梯競爭同乙個processingqueue的請求。
uml類圖
自己程式的bug
終於沒有bug了，高興tvt
乘客的請求資訊：[起點座 == 終點座] + [起點層 == 終點層] != 2，即樓座和樓層不會同時相同。如1-from-a-4-to-c-3
思路：將請求分成好幾段（最多三段），當完成一段請求後，就根據該請求的下一段請求資訊put進相應的processingqueue，直到完成所有段則完成了乙個乘客請求。
需要用counter來記錄完成的請求數量，所有的請求完成後，才結束所有電梯執行緒（記得notifyall）。
uml類圖
自己程式的bug
忽略了可達性問題，強測和互測都被hack爛了，快樂的時光總是那麼短暫
明確共享物件以及哪個執行緒對共享物件進行寫操作，哪個執行緒對共享物件進行讀操作，在這些操作中訪問共享物件時需要加上鎖，確保在同一時刻只有乙個執行緒在訪問共享資源。（使用synchronized加鎖）
在第一次作業中建立了共享類物件，所以在加鎖的時候，只需要在該類的方法上加上synchronized就可以了，這樣方便了很多，也比較難出錯。
三次作業中的共享物件都是waitqueue和processingqueue，所以在對它們倆進行操作時要多上點心。
鎖與同步塊中處理語句之間的關係：若執行緒a進入同步塊獲取鎖後，其他執行緒還想要進入同步塊獲取同個鎖是不行的，只能阻塞在外面，直到執行緒a退出同步塊釋放鎖，其他執行緒才可以獲取鎖。
第一次作業：只有縱向電梯，所以只需要根據電梯的樓座id排程。
第二次作業：引入了橫向電梯，根據橫向電梯的樓層id或縱向電梯的樓座id排程。
第三次作業：和第二次作業一樣。
用測試自己**的資料拿去測試別人（重複利用
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...
OO第二單元總結
共享資料類 在總結後面的3.基於度量的程式結構分析部分，本人根據展示的uml類圖更加詳細的講解了具體的協同結構工作原理。通過對實現以上操作的共享資料類中的方法設定synchronized，從而實現執行緒對共享資料的訪問同步。ocplsp ispdip 根據以上類圖，分析本次作業設計思路如下 2 根據...
OO第二單元總結
第二單元總結 第一次作業 思路與反思 uml類圖 度量分析 耦合度 第二次作業 思路 第二次作業與第一次的迭代在於電梯增加 人數限制 樓層改變，我依舊用的look演算法，在第一次作業的基礎上修改細節即可，多部電梯要求實現執行緒安全，由於我使用的look演算法，電梯盲目執行，沒有更高階的排程，只需要在...