java - 为什么在Android Studio的Profiler(内存)中，FinalizerReference类的保留堆大小如此之大？

Question

我已阅读this question about Finalizer's lion share of the heap。它始于2011年，当时工具有所不同，而Java类仍然具有不同的名称（Finalizer与FinalizerReference）。因此，我认为现在可以提出类似但又新的问题。

最重要的是，该问题的公认答案归结为：避免使用finalize（）对象。直接或间接使用finalize（）的Android类包括Canvas，Paint，Bitmap，Drawable和RenderNode。祝你好运，一直都在避免他们。

我还阅读了Profiler documentation，并通过了Memory Profiler Codelab。

后者将“保留大小”定义为“该类所有实例都在控制的内存大小”。

所以这是问题所在：我在Codelabs Memory Overload app上运行了Profiler（顺便说一句，这是设计造成的）。我将添加的TextView的数量限制为2000，并且仅轻按了设备上的浮动操作按钮一次。转储堆时，Profiler报告FinalizerReference的保留大小是我测试设备上可用内存的两倍。显然，某些占主导地位的内存不只一次被计算在内。

当然，我对自己程序的堆使用确实很感兴趣。当探查器在堆顶部显示FinalizerReference时，它似乎是一种误导，它支配着每个可用字节以及更多字节。我应该忽略FinalizerReference的保留堆大小吗？为什么我应该相信为其他班级提供的价值？

Answer 1

探查器似乎像其他任何类一样计算FinalizerReference的保留堆大小。这是一个错误，因为FinalizerReference在垃圾回收方面具有独特的自反性（请参见下文）。

一个简单的例子将证明这导致的荒谬结果。这也将弄清楚为什么FinalizerReference似乎比系统中的可用内存更多。

在Android Studio中，分析Codelabs Memory Overload之类的应用并转储堆。 （您可能需要触发垃圾回收并在转储之前等待其完成，以获取以下结果。）切换到zygote堆。在“堆转储”窗格上（可能在顶部）找到FinalizerReference。找到分配列中列出的实例数，例如n。计算n *（n + 1）/ 2 * 36。它等于“保留大小”列下的数字吗？我是这么想的。

为什么此公式有效？你自己看。在“堆转储”窗格上选择“ FinalizerReference”。在“实例视图”中向下滚动实例列表。经常选择“单击以查看下一个100”，以到达列表的底部。选择最后一个实例。请注意，在下面的窗格中，在其他一些引用它的FinalizerReference中有一个“下一个”字段，但没有“上一个”字段。还要注意，在这种情况下，“浅”和“保留”大小是相同的，即36个字节。然后查看保留大小的顺序，该顺序在列表上：36、72、108、144，...现在将所有n个实例的值相加。

上面给出的公式对应用程序堆不起作用（仅），有两个原因。一种是堆有时包含FinalizerReference实例，这些实例已从链接列表中取出，但尚未被垃圾回收。可以通过查看其内容（显示空引用）来识别它们，next和prev也为空。另一个是应用实例列表底部的项目由合子实例列表顶部的项目引用。因此，只能通过考虑合子堆上的实例并排除所有未链接的实例，来计算应用程序堆上FinalizerReference的（声称的）保留大小。

这是东西。 FinalizerReference不是普通的类。它是垃圾回收期间垃圾回收器使用的类。这种反射性很重要。 FinalizerReference实例的垃圾收集仅由垃圾收集触发。

创建时，将FinalizerReference实例作为双向链接列表的一部分，以便可以删除任何位置的实例而不会破坏列表。但这也意味着大多数实例都引用了另外两个实例。但是，唯一可以删除这些引用的操作是垃圾回收。垃圾回收器会找到除FinalizerReference实例之外没有被任何对象引用的每个对象，运行其finalize（）方法，进行垃圾回收，然后从列表中删除引用该对象的FinalizerReference实例，从而可以依次回收该实例。

目前，Profiler所做的是将FinalizerReference的“第一个”实例计算为保留的大小为36个字节，等于其“浅”大小。对于第二个实例，它计算自己的36个Shallow字节，再加上第一个实例的36字节的保留大小，并为其引用。对于第三个实例，它计算自己的36个Shallow字节，再加上前两个实例的72 + 36 Retained大小。因此，当我们达到100时，第一个实例的内存已经被计算了100次，第二个实例的内存被计算了99次，依此类推。这可能没有意义，除了（对于此类而言，具有误导性和毫无意义的） ）“内存控制”的递归定义。

对于开发人员而言，有关FinalizerReference实例的有趣事情不是它引用的其自己类的其他实例，而是它的引用对象，尤其是在该引用对象没有其他引用的情况下。如果Profiler对于该类有用，它将计算FinalizerReference类的Retained大小，作为由FinalizerReferences实例引用的引用所占内存的总和。那将永远不会超过系统中的实际内存，并且任何过高的值都会通知开发人员一个问题，即对象的创建和丢弃速度超过了垃圾回收的速度。

就目前情况而言，Profiler仅确认用于求和连续整数的数学公式（似乎遍历FinalizerReference列表，并实际上将这些数字相加！）。从这个意义上说，这没有错，但是将结果解释为FinalizerReference的保留堆大小仍然是错误的。这具有误导性，并且肯定不会帮助开发人员了解堆中正在发生的事情。