java - 小对象池是否比 Android 的 Java 垃圾收集器更有效？

Question

所以，我正在读这个:http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html 上面写着，“公共(public)服务公告:对象池现在是除了最重量级对象之外的所有对象的严重性能损失，即便如此，在不引入并发瓶颈的情况下也很难做到正确，”并从表面上看。文章讨论了分代 GC、释放、线程本地分配和逃逸分析。

但是，我脑子里有个小声音问我，“但是 Android 中的垃圾收集器实现是这样吗？”我不知道答案。我什至不知道如何去寻找答案。

不过，我记得当我为经常使用的小对象实现池时，我的 Android 应用程序中的 GC 运行频率较低。不确定这是否意味着更快的应用程序。此外，GC 在没有池化的情况下运行得更频繁(根据 logcat)，所以我假设 Android 的 GC 实现会因为池化而失败。但是这个假设几乎没有支持，因为我没有注意到使用或不使用池的任何显着性能差异。

所以.. 这里有人知道对于经常使用的小对象，池化是否比 Android 的 GC 更有效吗？

Answer 1

Anyone here know if pooling is more efficient than Android's GC for small objects used often?

这取决于您如何衡量“高效”、“小”和“经常”。

对象池在 Android 本身的几个地方使用，例如:

• AdapterView(ListView 和 kin)的整个 Adapter 框架都是围绕对象池设计的，这次是针对相对重量级的对象(例如，ListView 行很容易达到数十 KB)

• SensorEvent 对象被回收，这次是针对每秒可能使用数十次的轻量级对象

• AttributeSet 对象被回收，作为 View inflation 的一部分

等等。

其中一些是基于早期版本的 Android 中的 Dalvik 的早期版本，当时我们的目标是使用纯解释语言和相当简单的 GC 引擎开发低于 100MHz 的 CPU。

然而，即使在今天，对象池在即时性能之外还有一大优势:堆 fragment 。

Java 的 GC 引擎是一个紧凑型垃圾收集器，这意味着空闲堆空间的连续 block 被组合成更大的 block 。 Dalvik 的 GC 引擎是一个非压缩垃圾收集器，这意味着您分配的 block 永远不会成为更大块的一部分。这就是许多开发人员搞砸位图管理的地方——他们得到的 OutOfMemoryError 不是因为堆没有空间，而是因为堆没有足够大的 block 来进行所需的分配 fragment 化。

对象池避免堆 fragment ，只需防止池中的对象再次被垃圾收集，并且不经常为池分配新对象(仅当池由于同时使用太多而需要增长时)。

游戏开发者很早就在 Android 中使用对象池，源于当时 Android 的垃圾收集是非并发的，GC 时“停止世界”。现在，大多数 Android 设备都使用并发垃圾收集器，这在一定程度上减轻了这里的痛苦。

因此，对象池绝对仍然是一项相关技术。不过，大多数情况下，我会将其视为对检测到的问题的 react (例如，Traceview 在 GC 中显示太多时间，Traceview 在对象构造函数中显示太多时间，MAT 显示你有足够的堆但你获取 OutOfMemoryErrors)。异常(exception)情况是游戏开发——游戏开发者可能有自己的启发式方法来判断现代 Android 设备何时仍需要池化。