對於這一單元來說，多執行緒可能會導致的執行緒不安全的問題，我認為有很大一部分原因是對鎖的不夠充分理解造成的，下面是我對鎖的一些理解。
對於鎖有了一定的充分的理解之後，如果這一單元的作用架構不是很複雜的話，就不容易出現執行緒的安全問題。
三次作業大致採用了相同的結構，即乙個執行緒用來處理輸入，乙個執行緒作為電梯，乙個排程器，電梯採用了look演算法，排程器中包含請求佇列，向佇列中增加請求，從佇列中獲得請求的方法。
下面是三次作業分別的一些具體處理細節：
第一次作業中，請求佇列採用了阻塞佇列。
第二次作業，改為了wait和notifyall的方法。
第三次作業，改動較大，在前兩次作業中是把排程器作為了輸入和電梯的屬性，而在第三次作業，因為是由多個電梯，為了實現把電梯註冊到排程器中的思想，所以採用了單例模式，把排程器作為乙個單例，把電梯個輸入作為排程器的屬性，對於執行緒的處理，依然是三個電梯和輸入分別對請求佇列進行互斥訪問。同時為了解決拆分的問題，把request的請求又封裝了乙個類，在這個類中實現拆分，同時記錄需要換成的路線。
對於這一單元的多執行緒作業來說，多個執行緒的合理結束往往是引起執行緒安全問題的乙個重要方面。
第一次作業中，對於輸入執行緒的結束來說，都是讀入null後結束，為了能夠使電梯獲得這一資訊，在排程器中包含了乙個屬性，當輸入結束後將這個屬性置為true，當電梯獲取請求時，如果得到的請求為null同時這個屬性為true，說明此時輸入結束，同時請求佇列中已經沒有請求，那麼就可以讓電梯執行緒結束。
第二次作業與第一次作業的處理方式相同，不再贅述。
第三次作業，同樣因為多個電梯可以到達的樓層不同，所以即便是請求佇列中仍然含有這個電梯不能到達的請求，這個電梯也應該wait，所以採用前兩次的方法就會導致，無法區分當前電梯獲得了乙個null是應該停止，還是應該wait。所以改變了策略。在電梯中包含乙個屬性，來記錄該電梯是否處於wait狀態，當電梯獲得了null時，先判斷，如果此時輸入已經結束，並且另外兩個電梯也處於wait狀態，那麼把所有wait的電梯喚醒，返回hull，使三個電梯征程結束，否則該電梯應該wait。
首先在設計模式上，對於輸入執行緒，三次作業都是一樣的，可以做到復用，但是對於電梯的執行緒來說，如果要更改演算法，就需要對整個**進行修改，其實可以把電梯基礎的行為封裝為乙個抽象類，對於不同演算法的電梯可以從這個類整合，避免了對已有**的修改。
對於這次作業產生的bug，由於這次是單電梯，向上面說的，對鎖有一定的理解，這次作業基本不會產生錯誤。
在設計結構上，和上一次作業基本相同，還是輸入執行緒，排程器，電梯。不同點在於電梯採用了不同的演算法。基於上次的經驗，為了方便的擴充套件電梯的不同演算法，把電梯的基本功能，如上下樓，開關門等封裝為乙個baseelevator，從這個類繼承，可以實現不同演算法的電梯。
這次產生的bug，由於電梯，排程器，輸入。這三者之間的互動依然和上次沒有區別，所以沒有產生執行緒安全的問題。只是電梯的邏輯發生了一些變化，所以在自己的測試中也比較容易發現自己的錯誤。
在設計結構上，整體思路和前兩次相同。依然是輸入執行緒負責向請求佇列中新增請求，電梯執行緒取出請求。但是為了實現多個電梯執行緒，所以在結構上做了如下一些改變。
對於設計的結構來說，依然有很大很大很大的問題，雖然由於本單元作業的特性，沒有對每次作業都重構，但是也沒有做到在繼承等方法的基礎上實現對功能的擴充套件，每次對於關鍵邏輯實則還是相當於完全的重寫。對於**功能來說，沒有明確的進行功能的合理劃分，實際上是一種打補丁式的方法，即需要那個方法就填上。
對於多執行緒的程式來說，大部分的困難都來自對鎖的不熟悉，在具體學習了這部分的內容後，難度就減少了很多。對於這一單元的作業來說，如果採用的是樸素的方法，即輸入-請求佇列-電梯，這種放棄優化的方法，只要注意了執行緒結束的條件，也不太容易發生執行緒安全的錯誤。
所以，對於oo來說，實現作業的正確性不是最主要的，能夠提高自己對整體結構的設計，有乙個良好的框架才是在之後的作業中應該非常重視的（每次因為時間所迫還是選擇先完成了正確性）。
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...
OO第二單元總結
共享資料類 在總結後面的3.基於度量的程式結構分析部分，本人根據展示的uml類圖更加詳細的講解了具體的協同結構工作原理。通過對實現以上操作的共享資料類中的方法設定synchronized，從而實現執行緒對共享資料的訪問同步。ocplsp ispdip 根據以上類圖，分析本次作業設計思路如下 2 根據...
OO第二單元總結
第二單元總結 第一次作業 思路與反思 uml類圖 度量分析 耦合度 第二次作業 思路 第二次作業與第一次的迭代在於電梯增加 人數限制 樓層改變，我依舊用的look演算法，在第一次作業的基礎上修改細節即可，多部電梯要求實現執行緒安全，由於我使用的look演算法，電梯盲目執行，沒有更高階的排程，只需要在...