今年10月份以后我们产品线的crash平台莫名出现了大量的TimeoutExceptions,crash的路径页面全部为空,log日志里面有多次的gc操作;一开始以为是网络请求方面的问题导致的,然后仔细排查了工程代码,也没有发现可以点。这个问题一直悬了将近3个月,直到最近crash率超高红线,开始重视此问题,四处请教大神,终于找到了解决方案。国内手机厂商真是非常不负责,ROM随便改。
下面直接给出问题原因以及解决方案:
首先到下面的Daemons的源码,
https://www.javatips.net/api/ARTPart-master/platform/libcore/libart/src/main/java/java/lang/Daemons.java
通过源码可以发现,最终爆出TimeoutExceptions的位置在FinalizerWatchdogDaemon类里面的finalizerTimedOut,
详情讲解可以参考下面大神的文章<关于timeoutexception这件小事>http://www.courtier.cc/2017/04/28/关于timeoutexception这件小事/
最终的解决方法有两个:一是通知FinalizerWatchdogDaemon;二是将Timeout的时间设置超长;
方案二:
方案二:
try {
Class<?> c = Class.forName("java.lang.Daemons");
Field maxField = c.getDeclaredField("MAX_FINALIZE_NANOS");
maxField.setAccessible(true);
maxField.set(null, Long.MAX_VALUE);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
方案来源:
https://stackoverflow.com/questions/24021609/how-to-handle-java-util-concurrent-timeoutexception-android-os-binderproxy-fin
本文针对产品线出现的大规模TimeoutExceptions问题进行了深入分析,并提供了解决方案。问题表现为大量空路径页面的crash,且log中频繁出现gc操作。通过对源码的研究及尝试不同方法,最终确定了解决方案,包括调整FinalizerWatchdogDaemon的行为或更改Timeout时间。
1万+

被折叠的 条评论
为什么被折叠?



