面向對象程序第二階段總結

　　在第一階段的任務過後，這一階段的編程內容引入了更加復雜更加未知的元素——多線程。這三次作業的難度相比前三次難度有明顯的提升，而且三次作業都不是一個主題，前後沒有聯系，因此這三周的工作量相比第一周大了很多，在多線程程序設計中我也遇到了很多的障礙，在很多地方感到自己的計算與考慮還顯得十分幼稚，感覺自己的程序也都存在著很多的缺陷和錯誤。

第五次作業

第五次作業多線程電梯我沒有按時完成，這也是我的第一次無效作業。在第一次面對多線程的任務時我遇到了相當大的障礙，對本次作業的工作量估計不足，最終沒能在DDL之前完成一個能實現所有任務的程序。

盡管在這次作業中很多類都由上一次的類復用而來，但最關鍵的調度器策略出現了較大的變動，幾乎是從頭開始設計一個調度器。前一次的電梯作業中並沒有現實時間這個概念，對一條一條請求的調度是在全部請求已經知道的基礎上，根據電梯模擬運行狀態來調度，而多線程電梯需要電梯實時地進行對自己狀態的改變以及請求的接收、請求的分配調度。其中wait—notify的應用使整個程序的分析過程變得比較復雜。這一次作業中我對於共享資源、設計線程安全的類的理解不夠深刻，使得設計程序時沒能分清楚各個處理的關系，也導致了作業的失敗。這一次作業作為自己學習過程中的一次教訓，今後應當盡力避免。

第六次作業

吸取上一次無效作業的經驗，這次作業雖然也經歷了較長時間的掙紮但最終還是時間較充裕地完成了本次作業。在issue上比較長時間的澄清與明確之後，我們對IFTTT監測對象有了比較明確的理解。很明顯監控範圍內的目錄和文件是各個監控線程之間的共享資源，會出現未知的各個線程獲取、修改這些目錄、文件對象屬性的操作，造成線程不安全問題。

為了避免以上的難以預測的問題，這次的程序引入了快照的方式，即每次獲取、對比的方法對監控對象操作時都對監控對象進行一次快照，把需要的屬性、特點等以快照的形式獲取，同時也完成了記錄的功能，用快照完成判斷，這樣線程安全的問題在這一部分就得到了解決。另外對監控對象屬性的改變都使用了同步方法，保證程序不會運行出預期之外的結果（SafeFile的作用）。

程序總體類的設計比較明確，快照類、監視器類、detail、summary類等各司其職，總體的大功能在監視器類中實現、分配。

這次作業中我被檢測出兩個bug，問題出在renamed觸發器的判斷中，多個文件消失，有一個不同名但其他屬性相同的文件會被我判定為其他多個文件重命名後的結果。這個問題出現的原因是自己對於指導書中判斷條件的理解不夠全面，只是按照指導書的內容逐字逐句完成，沒有考慮到同時可能存在的問題。互測階段我分配到的作業不能完成任何一個記錄功能，最終判定為了無效作業。

第七次作業

第七次作業的共享資源是100輛出租車的狀態，訪問資源同步做不好的話會出現嚴重的調度混亂，這次作業還是使用了synchronized將對出租車屬性的操作同步化，各個線程相對有次序地進行調度，盡量避免順序的混亂。

程序將出租車本體與出租車的運動、完成任務都裝載在出租車類中，三秒中的窗口是一個依照呼叫請求創建出來的線程，獲取出租車的狀態完成派單的工作。主要的工作都由這兩個類來完成大的調度，其他類實現自己管轄的功能，共同完成運行。

這次作業與之前的多線程電梯有一些共通之處，但工程量與分析難度還是下降了不少。互測階段我出現了一些問題，首先是自己的大意，有一些輸入檢查沒有實現，如請求出發點和目標點相同、map的輸入有不合法字符等。而在多線程運行時我的程序會出現crash的問題，而這樣的問題很難復現，我還在尋找出現這樣問題的原因。在互測尋找bug的過程中除了按照分支樹順次檢查外我主要圍繞同一時間對共享資源的交叉訪問進行檢查。出租車的隨機性導致這樣的檢查難度不小，最終沒有找到對方的bug。

總結

總結這三次作業，我經歷了一段比較艱難的過程，逐漸對多線程有了一些最簡單的感知，這還遠遠不夠，自己仍需要對自己的程序進行更多的測試。自己在大工程量的基礎上對自己程序的思考和解析能力仍然需要提高。

OO第二階段總結