SWT 重啟案例分析(四)
極力推薦文章:歡迎收藏
Android 乾貨分享 本篇文章主要介紹 Android
開發中的部分知識點,通過閱讀本篇文章,您將收穫以下內容:
一、TimeoutException 導致系統重啟Log
二、TimeoutException 重啟 trace 分析
三、TimeoutException 導致的重啟解決方案
一、TimeoutException 導致系統重啟Log
TimeoutException 導致系統重啟
Systemserver TimeoutException
二、TimeoutException 重啟 trace 分析
1090 執行緒 被執行緒134 held
執行緒134 被執行緒 92 held
執行緒 92 是卡住的主要原因 在
從重啟的 Jave Exception trace
看由於在 ART GC
時,如果檢查到某個物件其所屬的型別 override
了 finalize
函式,會把這個物件新增到 referenceQueue
中。
referenceQueue
被 FinalizerDaemon
執行緒監控,如果裡面有內容,就會逐個取出並呼叫其 finalize
函式。
這樣在下一次 GC
的時候才真正的把這個物件佔用的 memory
給回收掉。
Java程序會預設等待 10s
,如果 10s
還沒有執行完,程序會強制丟擲 TimeoutException
。
一般是由於當時 系統IO忙
或者 memory比較緊張
,導致不能及時喚醒這個執行緒及時往下執行。
三、TimeoutException 導致的重啟解決方案
由 TimeoutException
超時導致的系統重啟,一般是由於當時 系統IO忙
或者 memory比較緊張
,沒有太好的修改方案,只能增長超時時間,或者更換好一點的 Memory
。
增長時間的修改方案如下
1. 修改 Daemons類
主要修改 Daemons.java
中的 MAX_FINALIZE_NANOS
時間。
Daemons
類 路徑如下:
/libcore/libart/src/main/java/java/lang/Daemons.java
private static final long MAX_FINALIZE_NANOS = 10L * NANOS_PER_SECOND; 修改為: private static final long MAX_FINALIZE_NANOS = 15L * NANOS_PER_SECOND;
2.修改 ActivityMangerService
增長 ActivityMangerService.java
中 CONTENT_PROVIDER_PUBLISH_TIMEOUT
的時間。
ActivityMangerService
類路徑如下:
frameworks\base\services\core\java\com\android\server\am\ActivityMangerService.java
static final int CONTENT_PROVIDER_PUBLISH_TIMEOUT = 10*1000; 修改為 static final int CONTENT_PROVIDER_PUBLISH_TIMEOUT = 15*1000;
長按識別二維碼,領福利
至此,本篇已結束,如有不對的地方,歡迎您的建議與指正。同時期待您的關注,感謝您的閱讀,謝謝!
如有侵權,請聯絡小編,小編對此深感抱歉,屆時小編會刪除文章,立即停止侵權行為,請您多多包涵。