第五次作業感覺是學習多執行緒的起手題目，並沒有很複雜的邏輯關係，電梯的排程也是最簡單的傻瓜排程。這裡我設定了三個執行緒，雖然本次作業的排程器沒有什麼作用，但是還是按照要求打出來了；我使用了乙個請求佇列的類，用於儲存請求，並作為處理輸入執行緒與排程器執行緒的共享物件資源。排程器與電梯共享乙個佇列，電梯從佇列中提取資料執行。這次作業較為簡單，這裡不再贅述。
uml圖：
方法複雜度：
類的複雜度：
時序圖如下：
2、單電梯als排程
要求可以捎帶，所以只和第一次採用乙個請求佇列去處理感覺會很困難，查了一下電梯的排程演算法，綜合scan、look，als和等等其他演算法，最後採用了look演算法；我另開了乙個樓層類，將請求佇列裡的資料按上行與下行分散在各個樓層中，這樣處理的好處是在電梯運動的過程中，只需要訪問當前樓層與電梯行進方向（上行或下行）對應的陣列是否有人即可，如果其目的地會讓電梯執行到更遠的地方，就更新目的地的狀態即可。但是不太好的地方在於如何讓電梯動起來，即第乙個讓電梯執行起來的請求處理會麻煩。這裡採用了look演算法，即從最高的樓層往下遍歷到最低的樓層檢視下行的最高樓層的地方，從最低的樓層往上到最高樓層遍歷尋找上行的最低的樓層，然後選擇離電梯最近的那乙個讓電梯去接（這裡不一定是最快的，對於某些情況會慢一些，但隨機資料表現的還好）。然後對於一些特殊情況的處理，如電梯在一樓，本來要去接乙個從5樓下行的人，過程中如果有6樓下行的人出現，理論上當然會去接，所以在執行過程中要不斷重新整理目的地是什麼。多設定了輸入處理與電梯兩個執行緒。共享資料只有乙個處理佇列，電梯內部設定排程器實現。
uml圖：
複雜度：
class複雜度：
由於排程器在電梯內部實現了，所以電梯的複雜度特別高，**長度也因為配置了不同的訪問方法而顯得極其冗長。
時序圖：
3、多電梯協同排程
這次的電梯數量增加了兩個，增加了乘客數量限制、停靠樓層限制。這時需要保證電梯之間盡量並行，所以需要外設乙個排程器用於給三個電梯分配資料。我用的排程方法仍是第二次的排程策略，通過排程器依據各個電梯的狀態給各個電梯分配資料，然後電梯依靠自己已有的資料執行。這樣的處理方法沒有考慮到電梯之間的協作，理論上還只是三個電梯各幹各的，所以效率不是很高。
有關資料的拆分，我採用的是用乙個0-7三位二進位制資料代表該樓層屬於三個電梯的狀態，然後通過兩個樓層的&來判斷是否需要轉電梯，如果需要轉電梯，我只是簡單的選擇最近的可以實現中轉的地方。（本次作業沒有想明白電梯之間的協作怎麼才能有效執行，所以這個地方的選擇也會慢一點）
uml圖：
複雜度分析：
因為沒有很好的考慮多電梯的協同運送，所以想在電梯資料的分配上盡量便捷一些，然後處理的過程變得特別麻煩使用了大量的條件語句，所以在計算給abc三電梯的資料分配上複雜度很高。
時序圖如下：
排程器邏輯如下：
自己的bug：第一次作業因為比較簡單，所以沒有發現bug，第二次的作業在課下的bug主要是排程的問題，最多的情況還是在電梯狀態的改變上，因為我採用的演算法有一步是不斷變換目的地，但是沒想到在換掉目的地後原本的樓層移動迴圈出現了問題。而且這個部分bug很難排查，花了我較多的時間。都二次作業互測沒有測出bug。第三次作業因為排程方法更加複雜，我仍是在人員排程問題上出了問題，第乙個就是滿載的處理，其次是因為abc樓層停靠特定，我的處理是在停靠樓層判斷是不是該樓層對應的有人要下，在到達乙個樓層不是其停靠樓層時，在遍歷時會產生乙個錯誤，算是自己的乙個邏輯錯誤。第三次作業強測出現了乙個執行緒不安全的錯誤，加了乙個鎖後就完成了（覺得好蠢）。
其他人的bug： 我是和舍友一起打了乙個簡易的隨機生成資料並且定點投放，並對程式的輸出進行乙個比較簡單的評判，只是對人的進出與輸入進行對比的乙個簡易的評判**。所以互測的時候也就是把**打包後放進程式跑，把錯誤資料交上去就完了。第一次第二次作業沒有發現其他人的問題，第三次找到了一位同學的乙個bug，有乙個資料沒有運送到指定位置，目測應該是在轉站的時候電梯沒有正確更新狀態導致的，雖然資料還在，但是電梯已經不會執行了，而排程器因為人員沒有全部運送完成而不會結束，出現超時。
尋找bug的策略：首先就是程式硬莽一直跑，檢視隨機資料的正確性，這種測試方法能測出絕大多數bug，對於一般情況的正確性效果奇佳，但是同樣因為資料的隨機性，這種方法對邊界情況測試很弱，這樣的東西需要自己去構建資料去測試。執行緒安全這個東西我覺得真的可能要佛了。弄出來完全看運氣，解決辦法我覺得只能從根源上解決了，就得分析設計上的共享資料的鎖問題，我覺得這樣比**不斷嘗試復現來的高效。
這三次作業讓我學習到了多執行緒，感覺收穫最多的也就是這一點，相關的鎖操作、同步、程序狀態變換等等。也對隨機演算法的認識提高了，隨機生成資料要求**的普適性很廣，極端情況會少很多，因而這些特殊資料顯得又不是太重要。對於如何結束乙個多執行緒的程式也嘗試多種不同的方法，比如第三次的作業我將資料拆分開，當電梯執行完以後會將第二段放**度器的請求佇列中，這樣排程器就不能單單依靠隊列為空就結束，引申出的思考也是學到了挺多東西，處理也更加熟練了。
在這個單元裡，突然覺得打碼找bug是一件很有意思的事情（瘋了），可能是os的襯托？（同樣是bug，自己的**越看越歡喜，領養的os**填空就怎麼看怎麼難受）
OO第二次部落格作業
從第4次作業開始，就進入了多執行緒程式設計的環節。我個人對於多執行緒的理解就是在乙個程式在執行時有多個執行流，能夠實現多個執行緒併發執行的技術。由於能在同一時間內執行多個執行緒，因而能夠提公升計算機的整體處理效能。第五次作業分析 由於第五次作業是我第一次接觸到多執行緒程式設計，因此這次作業對於我來說...
OO第二次部落格作業
第五次作業和第六次作業因為一些個人原因被判了無效所以這裡就不拿出來分析了 捂臉 第七次作業 設計乙個簡單的計程車排程系統 類圖 度量分析 其實在剛看到指導書的時候，覺得排程規則十分複雜。週日看了一下午指導書之後才大概想到一點思路，接著就開始了一步步嘗試。其實這次作業的目標十分明確，每個執行緒的任務很...
OO第二次部落格作業
在多執行緒的海洋裡遨遊了三周後，同學們又有了這難得的乙個月一次的oo部落格 休息 時間。多執行緒的各種 玄學 問題可是給我帶來了不少困擾和麻煩。而且這三次作業的共性特點就是特別難debug，不僅是難以給自己debug，給別人debug也不容易。就趁這個時間來回顧下這三周的時光吧！1.簡述 經過了傻瓜...