Android Camera 内存问题剖析，Android开发者必看避坑指南

深入分析

---

排查 Finalize 执行

虽然上述分析验证了问题，也证实了之前的猜想，但仍未找到导致此类问题的深层次原因，对于最终解决此类问题也仍然束手无策。为什么会有这么多的 CameraMetadataNative 对象等待执行 finalize 方法或许是下一步的调查方向。做过 Java 稳定性治理的同学应该都知道一类很有名的 TimeoutException 异常，这类异常的根本原因是 finalize 执行超时导致的，这个 case 会不会是某个对象的 finalize 执行超时导致的？

结合 FinalizerDaemon 的源码可以看到，每执行一个对象的 finalize 方法时，都会通过finalizingObject属性记录当前的对象。如果真的是 finalize 超时导致的，一定存在 finalizingObject 属性不为空的现场。我们在遍历完所有相关内存快照里的 FinalizerDaemon 线程状态后发现，这些现场的 finalizingObject 属性均为空。这个结果很意外，似乎并不是某个对象的 finalize 方法执行超时导致的。

通过分析finalizingReference = (FinalizerReference<?>)queue.remove() 发现这行代码后面的逻辑并没有对  finalizingReference 判空，说明这个地方一定不会返回空。既然不为空， queue.remove() 只能 block 等待，这个 ReferenceQueue.java 的源码也证实了猜想。

源码显示 goToSleep 是个同步方法，可能会 block。但遍历所有相关快照发现所有的 needToWork 属性均是 false，证明已经走过（只有FinalizerWatchdogDaemon.INSTANCE.goToSleep() 会置为 false，而且这个函数是 private 的，只在 FinalizerDaemon 线程里调用），所以 block 在这里的可能性几乎没有。