oo博客2
一、從多線程的協同和同步控制方面,分析和總結自己三次作業來的設計策略及其變化
第五次:這次作業我的策略便是讀入指令一個線程、調度器一個線程、電梯三個線程,通過調度器線程將讀入指令線程讀入的指令分配給三個電梯,而三個電梯則一直在運行,檢測是否有指令產生。本次作業完全使用synchronized關鍵字進行同步控制。
第六次:這次作業因為指導書要求不太明確,我便放棄了讀入指令線程這個設計以達到更好地同步控制。我的設計是將指令全部讀入後,根據指令數量建立對應的監控線程,這樣一來我只需做好監控線程的同步即可,實現起來較為容易。
第七次:這次作業的設計又變回了第五次作業的設計策略,即讀入指令一個線程、調度器一個線程來實現指令的讀入與分配,之後讓
二、基於度量來分析自己的程序結構
第五次作業:
這次作業因為給電梯分配指令時要考慮的因素過多(例如同質和捎帶),因此Dispatch類寫的過於臃腫,在分配算法上可以繼續優化。
優點:采用Button思路使電梯運行策略變得簡單。
缺點:對於捎帶判斷思路不清晰導致代碼變得臃腫。
設計原則缺陷:責任均衡分配原則及懂我原則。
第六次作業:
這次作業由於涉及到線程的類只有Monitor類,導致該類責任過重成為God類。
優點:線程較少,同步控制容易實現。
缺點:Monitor類過於龐大,實現較為復雜。
設計原則缺陷:存在God類,責任分配均衡原則。
第七次作業:
這次因為調度器類只需要讓出租車搶單及派單給出租車即可,因此實現較為容易,避免了方法冗余。
優點:各類的職責明確,責任均衡,較好地達成了責任分配均衡原則。
缺點:100個出租車100個線程,稍有不慎便會卡死(例如多層while(true)嵌套)。
設計原則缺陷:局部化原則。Map對象在很多類中重用了。
三、分析自己程序的bug
第五次作業:這次作業因為是第一次接觸多線程,對synchronized關鍵字的用法不太熟練,導致指令讀入線程和調度器線程存在同步控制問題(無法正確讀取指令序列中的指令),導致其余的設計和實現時間嚴重不足,遺留了很多bug。本次作業我被發現了
第六次作業:本次作業被發現了一個在同一文件上實行recover和path-changed觸發器後有概率導致找不到文件而crash的bug。這個bug存在的原因是因為在讀入指令時該文件存在,但一旦修改文件後,recover會將其改回來,並且導致改名後的文件在path-changed觸發器下找不到,而我未想到這種情況,認為讀入指令時文件存在便不需考慮文件不存在的問題,因此使用了listfiles方法,但這種情況只能返回null,從而出現了crash。
第七次作業:這次作業被發現了一個時間輸出上的錯誤。主要是我未考慮到出租車的運行需要微小的時間,運行多了自然會產生偏差。
四、分析自己發現別人程序bug所采用的策略
這三次作業均未發現別人bug。策略是按照bug樹構造指令。
五、心得體會
這三次多線程作業做完後,我覺得我整個人都上升了一個境界。一是針對大代碼量的作業的迅速完成能力的提升,二是針對問題提出設計的能力的提升,三便是不屈不撓的毅力。尤其是多線程電梯作業,因為對多線程完全陌生,導致同步控制完全沒做,因此出現了神奇的情況——就算添加指令和分配指令是對同一個指令序列進行的操作,他就是無法正確執行,而是像玩捉迷藏一樣偶爾正確執行一次。這真是差點讓我放棄,不過後來認真學習了synchronized關鍵字的用法後,這個問題便迎刃而解了,剩下的只有一個下午以及還沒開始寫的電梯類(心累),也導致遺留了很多bug。不過熟悉了同步控制方法後,接下來的兩次作業我都做得得心應手,也沒有被同學挑出來線程安全方面的問題。第六次作業做完我最大的感受便是——都跟你說了要try-catch,因為我過於自信(其實是沒想到)自己的邏輯,導致recover觸發器的一些問題沒有考慮周全,出現了文件不存在的指針錯誤。第七次作業讓我明白了假時間的好處,我在輸出出租車運行時間時只是簡單地輸出了系統時間/100,但沒考慮到出租車運行一段時間後會有誤差這一問題,導致出現了出租車運行時間間隔為300ms的錯誤,在稍微用假時間修改後,該問題得以解決。
oo博客2