java.util.concurrent.TimeoutException: com.android.internal.os.BinderInternal$GcWatcher.finalize() timed out after 10 seconds

最近在查看上传到服务器上的应用崩溃信息的时候,发现两个比较奇怪的崩溃栈,如下:

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)
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)

百思不得其解,最后在网上查到了貌似可以解释这个现象的原因:

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.util.concurrent.TimeoutException: com.android.internal.os.BinderInternal$GcWatcher.finalize() timed out after 10 seconds》上有2条评论

    1. 这个现象是Java虚拟机的BUG,比较好的解释是,当开始GC的时候,强制让机器休眠,然后等超过2秒后唤醒机器,就有可能导致这个现象。原因在于虚拟机认为自己回收超时了。其实这2S时间CPU根本没有工作。
      具体的解法应该是修改虚拟机获取时间的函数,调整为采用CPU上电工作时间,应该就不会发生问题了。
      这个只适用于系统开发人员,如果你是普通应用的开发者,只能期待用户升级到最新版本的Android了。貌似新版本没有问题了。从Android 6.0开始的?也不是太清楚了。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注