SWT 重啟案例分析（四）

摘要： 極力推薦文章：歡迎收藏 Android 乾貨分享 本篇文章主要介紹 Android 開發中的部分知識點，通過閱讀本篇文章，您將收穫以下內容: 一、TimeoutException 導致系統重啟Log...

本篇文章主要介紹 Android 開發中的部分知識點，通過閱讀本篇文章，您將收穫以下內容:

一、TimeoutException 導致系統重啟Log

二、TimeoutException 重啟 trace 分析

三、TimeoutException 導致的重啟解決方案

一、TimeoutException 導致系統重啟Log

二、TimeoutException 重啟 trace 分析

從重啟的 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;

至此，本篇已結束，如有不對的地方，歡迎您的建議與指正。同時期待您的關注，感謝您的閱讀，謝謝！

如有侵權，請聯絡小編，小編對此深感抱歉，屆時小編會刪除文章，立即停止侵權行為，請您多多包涵。