调查内存使用情况时，GC_FOR_ALLOC更“严重”吗？

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 {1}}只是意味着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开始。）