-----------Flag倒啦倒啦QAQ

第四次作業

回顧

　　本次作業是筆者編寫的第一個Java多線程程序，效果較好。在開始之前，筆者仔細閱讀了機械工業出版社Java語言程序設計（進階篇）中關於多線程的一章內容，對Java多線程相關知識有了基本的了解，隨後便迫不及待地開始上手。由於本次作業僅是在之前的電梯規則上稍作改動並添加了多線程機制，筆者誤以為並不太復雜，然而開始寫了才發現，我的天，好像不太好搞...由於筆者在編寫代碼之前未構建出一個清晰的架構以及對多線程存在些許誤解，導致多次修改架構，尤其是線程交互以及鎖的使用方面存在非常多的錯誤設計，經過大力調試與嘗試，勉強寫出了一個能跑的程序。之後在和同學對拍的過程中發現了一處極其愚蠢的"手誤"，修改過後繼續大力測試，基本無誤後便結束了此次作業。

　　公測全過，互測被叉出一處Bug，經過與測試者的溝通筆者發現如果機器以某種特殊的方式執行筆者設計的相關線程確實會觸發Bug導致某部電梯線程陷入死鎖，詭異的是，無論筆者在自己的機器上怎麽測都出不了Bug，所以筆者得出結論，確認過眼神，我遇見對的機器= =。。。有點坑，不過經過修改，筆者的代碼最終成功的在測試者機器上避免了Bug，在此筆者想要誠摯地感謝測試者認真負責的測試，由於Ta的測試，筆者加深了對多線程的理解。

　　筆者采用黑盒測試對測試任務進行了測試，最終發現被測者兩處Bug，一處是對規則的疏漏，一處是小概率Bug，沒什麽好說的

第五次作業

回顧

　 關於本次指導書，“天馬行空”這一詞可以說是非常貼切了。由於一直未能明確本次作業相關規則，筆者於周二下午才開始動工，於是一不小心就到第二天天亮了，寫了一個能跑的本質上是單線程的代碼就結束了本次作業，未進行其他測試。想說的是通宵寫代碼效率真實低，坐了兩三小時其實就寫了一個幾分鐘的代碼。另外筆者依然采用了先上手後考慮具體架構的做法，產生了額外的時間開銷。至此，學期初立下的Flag毫無尊嚴地被拔起扔到了地上T_T......

　　公測全過，互測被測試者找出一處非常簡單的Bug，經過筆者復現，發現八百行的代碼中有一行的For語句判斷少加了一個‘=‘，原因是半夜復制代碼然後修改條件時，漏了一處修改，OMG這令人窒息的操作。

　　筆者繼續采用黑盒測試對測試任務進行了測試，最終發現被測者兩處行為Bug，後來經過交流卻發現是同一個原因故最終取消了一處Bug申報。

第六次作業

回顧

對於此次作業筆者心存懈怠，再加上一些個人原因，最終結果非常不理想。設計上，筆者依然采用了先上手後考慮具體架構的做法，最終導致了更多的時間開銷，以及一處疏漏的產生。

　 在本次設計中，筆者先對地圖信息進行處理，BFS在O(n^4)的復雜度下計算出全源最短路以及全部路徑 ，實測需1S+預處理時間，之後再開啟一百個出租車線程以及調度器（輪詢實現）、請求線程。

　　這次公測沒什麽好說的，互測中被對方揪出兩處Bug，經過復現筆者發現某條IF語句打錯了一處變量名，以及之前編寫時想著後來加的“對於一輛車，如果剛剛在前幾條指令被分配指令則在後續指令的分配上應被BAN”這塊內容，不知怎麽的就忘記加了。。。

　　測試任務的需求報告寫得海星，代碼也寫得挺好，打完一個+3就佛了

三次作業設計策略及其變化

　 在電梯的多線程實現上，筆者通過輸入請求、電梯完成任務來喚醒調度器，調度器處理後再選擇是否喚醒相關等待電梯，筆者認為，電梯的多線程調度充分實踐了線程之間的交互等操作，非常好地加深了對多線程的理解；之後的兩次作業則未設計地如此復雜，只是通過簡單地輪詢即可完成全部任務。

心得體會

　 關於線程安全，最為穩妥的辦法則是對有同時訪問、修改可能的數據進行加鎖，筆者偏愛使用Lock，非常好用且非常靈活；但如果膽大心細的話，則可試著調換修改、訪問順序，搏一搏單車變摩托，沒準它就很安全不出錯呢嘿嘿！

經過筆者的觀察發現，每次狀態不太好的時候寫完代碼，肯定有至少一處zz錯誤，而這種錯誤往往經過簡單測試就能發現，所以之後的作業不管怎樣，簡單的功能測試還是必須的，省得遺憾。

　　最後想說的就是，一定要積極認真對待每次作業，事先對程序設計更細致的框架，否則吃力不討好、白費大把時光，還在起跑線你就已經輸了。

參考書籍

未完待續......

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