最近在查看上传到服务器上的应用崩溃信息的时候，发现两个比较奇怪的崩溃栈，如下：
百思不得其解，最后在网上查到了貌似可以解释这个现象的原因：
|
1 2 3 4 5 6 |
java.util.concurrent.TimeoutException: com.android.internal.os.BinderInternal$GcWatcher.finalize() timed out after 10 seconds at com.android.org.conscrypt.NativeCrypto.EVP_MD_CTX_destroy(Native Method) at com.android.org.conscrypt.OpenSSLDigestContext.finalize(OpenSSLDigestContext.java:27) at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:191) at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:174) at java.lang.Thread.run(Thread.java:818) |
|
1 2 3 4 |
java.util.concurrent.TimeoutException: com.android.internal.os.BinderInternal$GcWatcher.finalize() timed out after 10 seconds at java.lang.Daemons$Daemon.isRunning(Daemons.java:79) at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:171) at java.lang.Thread.run(Thread.java:818) |
百思不得其解，最后在网上查到了貌似可以解释这个现象的原因：
|
1 2 3 |
The reason for this timeout can come from two options: 1. A problem in the finalize code - trying to perform complex logic in the native destroy part. 2. CPU/Screen timeouts - the screen will dim and power off, followed by a System deep sleep state. the deep sleep can happen in a Garbage collection run, and when the device wakes up - a timeout can happen. |
我也碰到了同样的问题，找不到解决方法，请问你最后是怎么处理这个问题的？
这个现象是Java虚拟机的BUG，比较好的解释是，当开始GC的时候，强制让机器休眠，然后等超过2秒后唤醒机器，就有可能导致这个现象。原因在于虚拟机认为自己回收超时了。其实这2S时间CPU根本没有工作。
具体的解法应该是修改虚拟机获取时间的函数，调整为采用CPU上电工作时间，应该就不会发生问题了。
这个只适用于系统开发人员，如果你是普通应用的开发者，只能期待用户升级到最新版本的Android了。貌似新版本没有问题了。从Android 6.0开始的？也不是太清楚了。