仅联想华为设备偶现FinalizerReference.add抛出TimeoutException原因咨询

java.util.concurrent.TimeoutException: 
  at java.lang.ref.FinalizerReference.add (FinalizerReference.java:61)
  at com.android.internal.os.BinderInternal$GcWatcher.finalize (BinderInternal.java:63)
  at java.lang.Daemons$FinalizerDaemon.doFinalize (Daemons.java:289)
  at java.lang.Daemons$FinalizerDaemon.runInternal (Daemons.java:276)
  at java.lang.Daemons$Daemon.run (Daemons.java:137)
  at java.lang.Thread.run (Thread.java:919)

崩溃成因分析 #

• 厂商ROM定制的超时逻辑差异
  原生AOSP的FinalizerDaemon仅会在对象回收超时的时候输出警告日志，不会主动抛出异常终止应用。华为、联想两家的定制ROM修改了这部分逻辑，缩短了Finalizer的默认超时阈值（原生通常为10s，部分厂商ROM调整为3~5s），并且增加了超时后主动抛出异常崩溃的逻辑，这是该问题仅出现在这两个品牌设备的核心原因。
• Binder通信带来的Finalizer队列积压
  栈顶的BinderInternal$GcWatcher是Android Binder机制自带的回收监听类，每次跨进程Binder调用都会生成对应的GcWatcher实例，依赖Finalizer线程完成回收。如果应用侧存在频繁的跨进程调用（比如频繁调用系统服务、第三方SDK的跨进程通信逻辑），会在短时间内生成大量GcWatcher对象堆积在Finalizer队列，超出线程处理速度就会触发超时。
• 系统资源抢占导致的调度延迟
  Finalizer线程的优先级默认低于用户线程，当设备处于高负载场景（CPU占用率超过90%、内存严重不足、后台大量应用保活）时，Finalizer线程长期抢不到CPU时间片，无法及时处理队列中的回收任务，最终触发超时。
• 应用侧自定义Finalize逻辑阻塞队列
  如果应用本身或者集成的第三方SDK存在重写finalize()方法的类，且方法内部执行耗时操作（比如IO操作、同步锁等待），会阻塞整个Finalizer队列，后续的GcWatcher回收任务等待时间过长，也会触发该异常。

内容的提问来源于stack exchange，提问作者Hong