本文原地址: http://www.feitianzhi.com/boke/index.php/archives/27/
概述
"視頻系統"雖採用面向過程對象(參見:http://www.feitianzhi.com/boke/index.php/archives/18/)編程,去除線程池等複雜的設計,並減少線程的使用量,但線程數依然高達40個之多;
40個線程數雖對cpu而言已沒有任何壓力了,但多線程的複雜性依然存在,其中線程死鎖是多線程中最常見同時也難以定位的問題;
線程死鎖產生的原因分析
- 能否通過合理的設計規劃避免線程死鎖?
"小雉視頻系統"是一份持續維護並增加新功能的代碼,代碼的修改必須考慮與老代碼的兼容,需要處理的細節多,對每次修改都做出完美的設計幾乎是不能實現的; - 能否使用第三方工具查找線程死鎖?
對開發階段就能發現的死鎖用第三方工具定位是處理問題的通用方法,但使用第三方工具會導致系統速度指數級別的下降,在生產環境中無法使用,同時"小雉視頻系統"模塊衆多,模塊均支持按需開啓和關閉,任何一個修改需要準備的測試用例太多,死鎖後難以確定與此死鎖相關的模塊;
理想化設計
- 死鎖時自動報告是哪些線程卡住了?卡在源碼的哪一行?卡時的調用堆棧是什麼樣?
- 可在任意時間接受外部干預,報告所有線程當前執行到哪段源代碼的哪行並提供調用堆棧;
小雉視頻系統--線程死鎖設計預覽
- 線程死鎖時自動報告,"小雉視頻系統"並不能判斷線程死鎖,"小雉視頻系統"是做視頻應用,5S以上的卡頓足以讓用戶不滿,"小雉視頻系統"是監視所有線程,看哪個線程連續5S時間內一直停在同一句代碼處,以此認爲其死鎖了,效果如下:轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消
- 任意時間打印所有線程的調用堆棧,"視頻系統"監聽linux下10的信號,在收到信號後打印所有線程當前的調用堆棧,效果如下:轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消轉存失敗重新上傳取消