和你一起終身學(xué)習(xí)，這里是程序員Android

經(jīng)典好文推薦，通過(guò)閱讀本文，您將收獲以下知識(shí)點(diǎn):

一、TimeoutException 導(dǎo)致系統(tǒng)重啟Log
二、TimeoutException 重啟 trace 分析
三、TimeoutException 導(dǎo)致的重啟解決方案

一、TimeoutException 導(dǎo)致系統(tǒng)重啟Log

1.TimeoutException log如下：

TimeoutException 導(dǎo)致系統(tǒng)重啟

Systemserver TimeoutException

二、TimeoutException 重啟 trace 分析

1.TimeoutException Trace 如下：

1090 線程 被線程134 held

線程134 被線程 92 held

線程 92 是卡住的主要原因 在

從重啟的Jave Exception trace看由于在ART GC時(shí)，如果檢查到某個(gè)對(duì)象其所屬的類型override了finalize函數(shù)，會(huì)把這個(gè)對(duì)象添加到referenceQueue中。

referenceQueue被FinalizerDaemon線程監(jiān)控，如果里面有內(nèi)容，就會(huì)逐個(gè)取出并調(diào)用其finalize函數(shù)。

這樣在下一次GC的時(shí)候才真正的把這個(gè)對(duì)象占用的memory給回收掉。

Java進(jìn)程會(huì)默認(rèn)等待10s，如果10s還沒(méi)有執(zhí)行完，進(jìn)程會(huì)強(qiáng)制拋出TimeoutException。

一般是由于當(dāng)時(shí)系統(tǒng)IO忙或者memory比較緊張，導(dǎo)致不能及時(shí)喚醒這個(gè)線程及時(shí)往下執(zhí)行。

三、TimeoutException 導(dǎo)致的重啟解決方案

由TimeoutException超時(shí)導(dǎo)致的系統(tǒng)重啟，一般是由于當(dāng)時(shí)系統(tǒng)IO忙或者memory比較緊張，沒(méi)有太好的修改方案，只能增長(zhǎng)超時(shí)時(shí)間，或者更換好一點(diǎn)的Memory。

增長(zhǎng)時(shí)間的修改方案如下

1. 修改 Daemons類

主要修改 Daemons.java中的MAX_FINALIZE_NANOS 時(shí)間。
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

增長(zhǎng)ActivityMangerService.java中CONTENT_PROVIDER_PUBLISH_TIMEOUT的時(shí)間。

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;

至此，本篇已結(jié)束。轉(zhuǎn)載網(wǎng)絡(luò)的文章，小編覺(jué)得很優(yōu)秀，歡迎點(diǎn)擊閱讀原文，支持原創(chuàng)作者，如有侵權(quán)，懇請(qǐng)聯(lián)系小編刪除。同時(shí)感謝您的閱讀，期待您的關(guān)注。