漸入OO課的深處，探索多線程的祕密——OO第二次博客總結

一次又一次的挑戰，一次又一次全新的知識，我來到了多線程的面前

---

 

第五次做業

一、度量分析

 

>第五次做業因爲很大程度上調用的是前兩次電梯的一些代碼，因此存在的問題與前幾回也十分類似。同時因爲第一次使用多線程來解決問題，可能將某些功能過於集中的放在了個別類中。致使McCabe Cyclomatic Complexity以及Nested Block Depth出現標紅的現象。

二、類圖

>此次在類圖上面問題體現的也很明顯，在方法的分配上並無作的很平均。這主要是因爲爲第一次多線程做業，因此將大部分的功能所有賦予了elevator類中，致使類過於冗長並且類圖顯得特別難看。

三、關於BUG

　　當咱們在經歷了三次面向對象式的JAVA編程歷練之後，從最開始的一頭霧水到如今的略知一二，筆者覺得本身終於已經適應了JAVA的語法與編寫規範，但第五次做業的降臨又讓我有了泰山壓頂般的感覺。最後一次電梯做業，第一次運用多線程來處理實際問題，學長學姐口中OO最難的一次做業果真名不虛傳。直到週二晚上因爲對多線程安全的理解不深入，筆者的程序仍然存在些許小bug。因爲精力實在有限，致使最後這一點bug被擱置了。～所幸此次測試的公測仍是比較弱的，此次筆者的程序被公測和互測分別找了一個bug。公測的bug仍然在於對多線程的保護上，最終致使在多個電梯共同運行狀況下運動量的計算出現了問題(3號電梯運動量被反覆計算)，致使公測的這一個點掛了。而測試者此次找到的問題一樣是因爲多線程在運行上的不肯定性致使，而這個問題則是反映在了捎帶這個功能上面，本來該捎帶的一次請求因爲多線程完成度的問題致使在條件判斷上出現誤差，沒有被捎帶上。此外沒有被找到其餘bug。而做爲測試者，此次筆者拿到的程序問題仍是很多的：首先在公測的格式測試方面，他對於錯誤格式的判斷很完善，缺在輸出格式上與要求有一點不一樣，而後是對於捎帶和同質的判斷也存在很大的問題，並且他把輸出時間輸出成了間隔時間，最終致使公測錯了不少。不過幸運的是對於最簡單的電梯和樓層請求，因爲輸入時間爲0，因此並無錯，也沒有達到一個無效的條件。而在公測以外，此人還有不少的細節方面也沒有作好。互測上筆者除了報告了他的輸出格式錯誤以外，還對單行20條請求和50行總請求進行了測試，他也沒有對此做出相應的錯誤響應。同時在一層輸出多條相同到達信息他也沒有處理。總之筆者認爲他此次做業仍是比較失敗的，不少並不難但比較細的東西沒有考慮到，並且輸出的錯誤是態度問題，筆者感受他並無很認真的對待此次多線程做業。不過此次做業着實比較困難，周圍的同窗也都多多少少出現了不一樣的問題，一樣這第一次的多線程之旅也給咱們帶來了很多的反思與經驗。電梯的結束意味着新的開始，此次做業的bug就總結到這裏咯。

---

 

第六次做業 

一、度量分析

>這一次做業因爲主要是對文件進行一個操做，因此對於功能不管是從代碼量上仍是代碼難度上都不是特別的難。但在判斷文件相對應的操做時須要判斷的條件過於繁多，過多的if-else因此形成了程序嵌套程度過深的狀況，使Nested Block Depth出現標紅。而因爲這些主要的判斷以及其餘的主要功能部分都是在Trigger中完成的，又致使過多的方法集中在了一個類中，使McCabe Cyclomatic Complexity出現標紅現象。

二、類圖

 

 >第六次做業的類圖仍是比較清晰明確的，各個類分工也比較明確。惋惜作的很差的一點在上面的度量分析與類圖中均可以反映出來，過多的功能性方法都集中在了Trigger這一個關於觸發器的類之中，使這一個類特別的突兀。

三、關於BUG

　　學長們都說第五次和第六次做業是最難的兩次，事實也確實如此。IFTTT，當這個陌生的詞彙第一次出如今我眼簾的時候我根本不知道此次做業咱們要作的到底是什麼。而OO的魅力大概就在於每一次做業咱們都須要本身去學習並探索新的知識，而此次正是對於文件的各類操做與監控。實際上此次做業不管是從代碼量仍是邏輯難度上看都不高，但難就難在不清楚做業目標以及許多的新操做。不過有驚無險，此次做業的測試中筆者沒有被公測和互測找到bug，而筆者測試的程序寫的也十分完美。但多是沒有及時收到issue上面的一些規則修改，沒有對於超過10個監控對象的處理。readme中也沒有響應的說明，筆者也只報了這樣一個bug。隨着做業的逐步深刻，測試方面也變的愈來愈困難，因此筆者沒有時間也因爲能力所限沒法進行深層的測試，一次相對和平的做業就這樣過去了。

---

 

第七次做業 

一、度量分析

 

>第一次關於出租車系列的做業，在功能上的描述與編寫上並非很難。但想到並實施一個比較好的架構十分重要並且也不容易。我在深思熟慮以後纔開始動工此次的做業，因此在類的分工作的十分的明確，但這個if-else的嵌套深度每一次做業都沒有解決。這多是因爲我經驗的上的不足，沒有很好的利用一些優質的算法與JDK自身函數，致使判斷次數與層次過於太多，之後這方面的問題我必定會多加的注意一些。

二、類圖

 

>因爲是第一次出租車的做業，因此此次的類圖比較簡單，從名字上也能清楚的看出各個類的功能與屬性。

三、關於BUG

　　在電梯以後又迎來了又一個系列性做業——出租車系列做業。萬事開頭難，雖然已經有了兩次多線程做業的經歷，但仍然對多線程的理解不夠清楚，在設計與實際工做過程當中也不是說十分順利。因爲是系列做業，關係到後面幾回做業的成敗，因此此次做業的bug修改也是極爲重要。因爲人工手動測試十分困難，因此公測只放了一些輸入格式上的一些錯誤，筆者的程序固然也沒有問題。當筆者看到在互測中本身被找到的bug是同質請求出現了沒有判斷的狀況，仔細分析之後發現是雖然在兩次輸入上實際的時間差是小於100ms的，但因爲筆者在對每條請求處理上有些複雜，致使程序運行時間偏長，使程序中兩次輸入的時間差超過了100ms，沒有判斷爲同質請求，這樣是不符合實際的。因此筆者須要對此次代碼做出相應優化，或者利用假時間來判斷100ms，儘可能減少程序運行時間致使的偏差。另外一個bug則是測試者偶然發現當輸入知足必定的條件時個人出租車信用度在計算上會出現差錯，雖然如今仍然不知道具體問題是什麼，但能夠確定的是bug出如今信用度計算上的條件與位置一塊。這就是筆者此次做業被找到的bug。相同筆者測試的程序也存在一些相似的問題：首先筆者的測試任務代碼在公測方面沒有判斷出發點和目的點相同的狀況，也就是沒有忽略此類請求，這也是他公測惟一的錯誤。在互測上，首先比較明顯的一個問題是當輸入請求多於一條時，對方程序的出租車雖然會對全部請求有所響應，但每次都是在接到單以後卻不去運動，筆者猜想是他在狀態轉化上出現了問題，致使出租車出現了不繼續跑的狀況。對方的第二個bug狀況就和筆者的bug相似了，因爲咱們都是直接使用系統時間(也就是真時間)來進行各類判斷與輸出，因此每次模擬出租車運行一格200ms實際程序運行超過200ms，因此在輸出上會有所體現。由於結果精確到100ms，因此在必定量累積之後這個偏差量達到100ms使輸出出現問題。而這個因爲程序運行時間致使的偏差錯誤筆者在上面本身的bug處也有所說起。

　　至此，這三次做業的bug分析之旅也就結束了。

---

 

 

心得體會 

1.當步入多線程的世界，才知道這裏面的路是多麼的艱難。這幾回做業我覺的最困難的點大體有兩個，首先就是針對於一個項目的架構設計。因爲是多線程的設計，因此在每次動工以前須要想清楚要創建多少個類，同時須要想多少個線程才能把這個功能作到最佳化。
2.其二就是關於多線程最重要的一環：線程安全問題。在完成代碼基礎功能以後，若是對線程不加以管控，每每會出現不少不合乎常理的錯誤，這都是由於多個線程同時運行狀況下對公共資源的無管控的爭奪，再加上多線程運行的不肯定性致使公共資源出現意料以外的錯誤。因此在功能完成後要對幾個線程之間的聯繫做出分析，好比幾乎每次做業都用到的請求隊列在輸入線程和調度器線程之間的共用，請求的存取就比如消費者與生產者之間的經典案例。須要對之間的紐帶——請求隊列進行上鎖操做，而這就要對全部的共用資源所有分析清楚。固然在必定的實踐與理解以後，筆者也意識到並非全部涉及到共用資源都須要上鎖，有的隊伍共用資源的調用只是拿到其性質或者其餘的東西，並不對其進行操做與改變，這一部分的共用實際上是不須要加鎖保護的。就針對於請求隊列而言，重要的是對存入請求以及取出請求(刪除請求)進行保護，不然會出現亂了套的狀況。
3.對於多線程代碼的調試也是比較有感觸的一個部分。它自己的不肯定性很大程度上就決定了多線程的調試並不能依靠加斷點來單步調試。因此須要靈活而巧妙地運用輸出調試來找到問題的所在。並且在每一個線程的開始去進行輸出標誌也是屢試不爽的一個小技巧。同時多線程也有許多的好處，好比多線程能夠把任務分塊執行，分塊後能夠同時進行而不用等待。這樣效率更高以下載文件，經過多線程就能夠實現多文件下載。同時線程安全的實現方式也是有不少種的而我使用的Synchronized關鍵字：編譯後會在同步塊先後分別形monitorenter和monitorexit這兩個字節碼指令。這兩個指令都須要一個引用類型的參數來指明要鎖定和解鎖的對象。若是沒有明確指定對象參數，那就根據synchronized修飾的是實例方法仍是類方法，去取對應的對象實例或Class對象來做爲鎖對象。在執行monitorenter指令時，首先嚐試獲取對象的鎖，若是沒有被鎖定或者當前線程已經擁有了該對象的鎖，則將鎖計數器加1，相應的執行moniterexit時，將鎖計數器減1，當計數器爲0時，鎖就被釋放了。若是獲取對象鎖失敗，則當前線程就要阻塞等待。

---

 

寫在最後

　　~~至此，課程已通過去了一多半，我相信你們都已經對OO和JAVA有了必定程度的熟悉與我的的感覺吧。在這裏再次對全部在完成做業過程當中幫助過個人同窗以及認真負責測試我代碼的同窗表示衷心的感謝。但願你們能堅持下去，一塊兒加把勁，努力去迎接新的挑戰與勝利的曙光。