三次作業都是簡單的生產者消費者模式。
電梯演算法採用最好寫的scan演算法，前兩次效能分還可以，第三次由於加入了換乘需求，效能分全面崩盤。
1 電梯執行緒的結束條件，以及等待條件沒有找對。第一次作業和第三次作業都是因為某個（或某幾個）電梯執行緒過早結束，導致乘客請求未滿足。
2 沒有第0層
3 電梯不執行的時候，竟然不允許人上電梯
4 電梯處於最底層和最高層的時候，不允許人上電梯
5 乙個執行緒應避免直接操作另乙個執行緒
電梯作業整體難度低於第一單元，用時少於第一單元。通過這三次作業，我初步了解了多執行緒，以及多執行緒程式設計的一些方法，收穫不少。
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...
OO第二單元總結
共享資料類 在總結後面的3.基於度量的程式結構分析部分，本人根據展示的uml類圖更加詳細的講解了具體的協同結構工作原理。通過對實現以上操作的共享資料類中的方法設定synchronized，從而實現執行緒對共享資料的訪問同步。ocplsp ispdip 根據以上類圖，分析本次作業設計思路如下 2 根據...
OO第二單元總結
第二單元總結 第一次作業 思路與反思 uml類圖 度量分析 耦合度 第二次作業 思路 第二次作業與第一次的迭代在於電梯增加 人數限制 樓層改變，我依舊用的look演算法，在第一次作業的基礎上修改細節即可，多部電梯要求實現執行緒安全，由於我使用的look演算法，電梯盲目執行，沒有更高階的排程，只需要在...