java - 调查内存使用情况时，GC_FOR_ALLOC 是否更多 "serious"？

Question

我目前正在调查我的 Android 应用程序的垃圾收集问题，我很想知道 GC_FOR_ALLOC 是否表明存在比其他 GC 消息(例如 GC_CONCURRENT)更大的问题。

据我了解，GC_CONCURRENT 正在做垃圾收集器应该做的事情。堆已达到特定限制，最好清理内存。

GC_FOR_ALLOC 向我表明，如果我试图创建一个对象并且没有剩余内存可以做，那么会发生更严重的事情。

GC 消息是否有优先级或“严重性”级别？

Answer 1

从某种意义上说，GC_FOR_ALLOC比GC_CONCURRENT更严重，因为GC_FOR_ALLOC意味着没有足够的空闲内存来完成分配请求，所以垃圾回收是必要的，而 GC_CONCURRENT 只是意味着 GC 感觉就像在运行，通常是因为分配后可用内存量低于某个阈值。

GC_FOR_ALLOC 本身并不表示您的应用程序存在问题:

• Android 应用程序从一个小堆开始，当应用程序需要越来越多的内存时，它会增长(直到某个点)，并且在增加堆大小之前完成 GC_FOR_ALLOC。在这种情况下 GC_FOR_ALLOC 是完全正常的。
• 如果你分配内存的速度快于并发 GC 释放它的时间，GC_FOR_ALLOC 是不可避免的。分配内存的速度比并发 GC 释放内存的速度快并没有本质上的错误。

Android 上更严重的 GC 类型是 GC_BEFORE_OOM，当分配请求失败时执行，即使在 GC_FOR_ALLOC 之后，并且当应用程序堆增长到与它一样大时被允许。当这种情况发生时，作为最后的手段，Dalvik 也会尝试释放 SoftReferences，然后再进行最后一次分配内存的尝试，如果失败则抛出 OutOfMemory 异常。

如果你想看看这个逻辑的代码，它在 dalvik.git/vm/alloc/Heap.cpp 的 tryMalloc() 中。

无论如何，如果您不介意，我怀疑查看 logcat 输出是调试垃圾收集问题的最有效方法。我不知道您遇到了什么具体问题，但是您是否研究过诸如 DDMS 中的分配跟踪器之类的工具并在 hprof-conv 工具的帮助下分析堆转储？ (参见 http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html 示例以开始使用。)