在多執行緒的海洋裡遨遊了三周後，同學們又有了這難得的乙個月一次的oo部落格(休息)時間。多執行緒的各種"玄學"問題可是給我帶來了不少困擾和麻煩。而且這三次作業的共性特點就是特別難debug，不僅是難以給自己debug，給別人debug也不容易。就趁這個時間來回顧下這三周的時光吧！
1.簡述
經過了傻瓜式電梯、als電梯後，同學們又"歡天喜地"地提了三颱多執行緒電梯。這是我正式初識多執行緒，在迷霧未現的時候進入了這個玄學領域。這次雖說大體上繼承了als電梯的思路，但由於這次要完全模擬真實情況，我選擇了完全推翻重寫的策略，讓我的**整體結構和思想和之前的als電梯完全不同，以模擬現實的邏輯思路實現了這次作業。我依然保留了乙個請求佇列來儲存電梯請求，在此之外，我還構建了乙個等待佇列，作為該電梯執行緒即將執行的請求。與之前相同，我還構建了排程類和主排程方法來對請求佇列的請求進行排程。每一台電梯作為乙個獨立運作的執行緒，排程類再獨立作為乙個執行緒對整體的運作進行排程，共同訪問請求佇列。
這一次作業的一大要點便是執行緒之間的競爭和安全關係。為了使我們的三颱電梯不互相爭搶請求，修改相關資訊，我們不得不使用synchroniezd鎖來鎖住方法或物件，來避免多執行緒所謂的"玄學"情況。
2.程式結構
3.bug分析
這次出現的bug主要是執行緒安全的問題。因為是第一次寫多執行緒**，對執行緒安全還沒有什麼認知概念，有些時候只鎖了方法卻沒有鎖物件，導致真執行起來還是會出現執行緒不安全的情況。現在對執行緒之間的運作有了更深的理解，也理解了鎖方法和鎖物件(**塊)的實際運**況，再遇到這種問題時，就知道怎麼去解決了。
1.簡述
終於送別了電梯，這次作業是對檔案/目錄進行監控管理，算是對執行緒安全進行了一次強化訓練來加深理解。這次作業難度體現在各種對目錄的操作。監控目錄時需要監控目錄下所有的檔案的變化情況，因而需要遞迴遍歷該目錄下所有的檔案和子目錄來獲得所有檔案的狀態變化。值得一提的是，file.io庫提供的各種檔案操作的方法並不是執行緒安全的。所以，我們建立了執行緒安全的safefile類來將各種操作方法"安全化"(加上synchroniezd方法鎖)。除此之外還對每個觸發器各自構建了乙個類，根據目錄/檔案兩種方式進行監控。這一次作業的邏輯思考方面比多執行緒電梯要簡單一些，但是對執行緒要求的處理要求更高。
值得一提的是，這次測試採用了自動化測試。通過編寫test執行緒來對自己的**進行測試，這種測試方法更智慧型，而且對每乙個操作的時間間隔把控準確，更方便人為去判斷結果是否符合預期。
2.程式結構
3.bug分析
這次的bug主要在於對目錄監控。對檔案監控的四種觸發器都比較容易完成，問題主要存在與對目錄監控時的path-change trigger。我在判斷目錄下檔案路徑移動時有時候巢狀深了會產生一些問題，後來我想了想，應該還是**邏輯上寫的有些錯誤，跟執行緒安全什麼的應該沒有太大關係。而且因為我每個監控請求都開了乙個執行緒，所以如果乙個檔案/目錄同時被多個執行緒監控並且做出了多個會出發相應觸發器的變化時，summary/detail記錄的內容值可能會累計，如果乙個檔案/目錄被recover，還可能會導致另外的請求執行緒記錄相應的變化，有時也存在一些無法預料的結果，但一般都是能進行解釋的。
1.簡述
這次開始寫計程車了。第一次就是多執行緒計程車，但是好在有之前兩次多執行緒作業的基礎，加上這次作業的邏輯也不是很複雜，此次作業並沒花費太多時間去完成。這次的一大特點是引入了gui，讓我們寫完**執行的時候能更直觀地去觀察計程車執行的效果。我覺得這次作業是寫oo以來最有趣的一次，因為gui動起來以後讓人看著很有成就感，很滿足，畢竟這100個電梯怎麼動都是自己寫的，切切實實地感受到了自己的努力終於有了成果。
這次作業裡，我把每輛計程車各自開了乙個執行緒。由於把每個乘客請求都獨起了乙個執行緒進行排程，所以並沒有寫請求佇列這種東西。我這次的排程策略是請求選擇計程車，在請求類裡寫上了主排程方法，請求類物件start()後就會呼叫相應排程方法，每個請求執行緒的生命週期只有3s,當成功排程選擇好計程車後就結束這個請求執行緒。
2.程式結構
metrics:
uml:
uml sequence:
3.bug分析
這次我在本地測試的時候發現了幾個bug，後來都解決了。因為這次計程車的初始位置和移動是隨機的，所以有些bug需要多次測試才能復現。其中乙個是請求在排程分配的時候沒有把物件和**塊鎖起來，導致可能出現乙個請求分給多輛車的情況。這也屬於執行緒安全的問題。在多執行緒程式設計時執行緒安全是十分重要的問題，我們應該在平時寫**的時候就有意識去避免執行緒不安全的情況，以免測試的時候不完備，沒有測試到這種bug。
轉眼間，我們也從電梯寫到了計程車。oo的**作業也沒幾次了。雖然每次寫oo**的時候都心力交瘁，怨聲載道，但是不得不說，這些大量的**量的積累，對我們本身大有裨益。多次的高強度**編寫，讓我也習慣了長時間坐在電腦前coding。我覺得最用成長的就是測試環節了。以前學資料結構的時候，大多都是本地隨便測兩個弱測然後就交上去讓評測機debug,這種方式沒有讓我的測試能力得到鍛鍊。但是每次oo作業的大量測試，是我通過bug分支樹，自己對指導書和題目的理解，不斷地編寫測試**/樣例來完成的。而且第六次作業開始引入了自動化測試，讓我也是見識到了新的世界。希望自己能在最後幾次**作業中拼盡全力，不讓之前每一次的努力留下遺憾。
OO第二次部落格作業
從第4次作業開始，就進入了多執行緒程式設計的環節。我個人對於多執行緒的理解就是在乙個程式在執行時有多個執行流，能夠實現多個執行緒併發執行的技術。由於能在同一時間內執行多個執行緒，因而能夠提公升計算機的整體處理效能。第五次作業分析 由於第五次作業是我第一次接觸到多執行緒程式設計，因此這次作業對於我來說...
OO第二次部落格作業
第五次作業和第六次作業因為一些個人原因被判了無效所以這裡就不拿出來分析了 捂臉 第七次作業 設計乙個簡單的計程車排程系統 類圖 度量分析 其實在剛看到指導書的時候，覺得排程規則十分複雜。週日看了一下午指導書之後才大概想到一點思路，接著就開始了一步步嘗試。其實這次作業的目標十分明確，每個執行緒的任務很...
OO第二次部落格作業
第一次作業 套用生產者消費者模式。電梯作為乙個單獨執行緒，是消費者。輸入執行緒是生產者。全域性只有乙個任務佇列的共享物件。第二次作業 採用生產者消費者模式。耦合比較亂的地方 電梯作為乙個單獨執行緒，同時肩負起排程器和電梯的角色。第三次作業 採用類似於流水線的模式 其實還是生產者消費者模式，不過就是一...