小型对象的池是否比Android的Java垃圾收集器更高效？

Question

所以,我正在阅读这篇文章:http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html ,其中说:"公共服务公告:对象池现在是一个严重的性能损失,除了最重量级的对象,即使这样,在不引入并发性瓶颈的情况下做到正确也很棘手,"并将其视为面值.本文讨论了分代GC,解除分配,线程局部分配和转义分析.

但是,我脑子里只有一个小小的声音问我,"但这对Android中的垃圾收集器实现是否正确？" 而且我不知道答案.我甚至不知道如何找到答案.

我记得当我为经常使用的小对象实现池化时,在我的Android应用程序中运行GC的频率较低.不确定这是否意味着更快的应用程序..此外,GC运行更频繁而没有池(根据logcat),所以我认为Android的GC实现失去了汇集..但这个假设几乎没有支持,因为我没有注意到任何显着的性能差异,无论是否合并.

所以..这里的任何人都知道,对于经常使用的小物件,池的效率是否比Android的GC更高效？

Answer 1

这里的任何人都知道,对于经常使用的小对象,池化是否比Android的GC更高效？

这取决于你如何测量"有效","小"和"经常".

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

• (和kin)的整个Adapter框架是围绕对象池设计的,这次是针对相对较重的对象(例如,一行很容易就是几十KB)AdapterViewListViewListView

• SensorEvent 对象被回收,这次对于每秒使用数十次的轻量级对象

• AttributeSet物品被回收,作为View通货膨胀的一部分

等等.

其中一些是基于早期版本的Android中Dalvik的早期版本,当时我们的目标是使用纯粹的解释语言和相当天真的GC引擎,在100MHz以下的CPU.

但是,即使在今天,对象池还有一个超越即时性能的巨大优势:堆碎片.

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

对象池避免了堆碎片,只是通过防止池化对象再次收集垃圾并且不经常为池分配新对象(仅当池需要由于同时使用太多而需要增长时).

游戏开发者长期以来一直在Android中使用对象池,这源于Android的垃圾收集非并发时的回归,当GC进行时"停止世界".现在,大多数Android设备都使用并发垃圾收集器,这可以减轻一些人的痛苦.

因此,对象池肯定仍然是一种相关技术.但是,大多数情况下,我认为它可以用作对检测到的问题的反应(例如,Traceview在GC中显示太多时间,Traceview在对象构造函数中显示太多时间,MAT显示您有足够的堆但是你得到OutOfMemoryErrors).例外是游戏开发 - 游戏开发者可能有自己的启发式,因为现代Android设备仍然需要池化.