问题描述

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

I'm currently investigating garbage collection problems with my Android app, and I'm curious to know if GC_FOR_ALLOC is indicative of a bigger problem than other GC messages, such as GC_CONCURRENT.

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

From my understanding, GC_CONCURRENT is doing what the garbage collector should do. The heap has reached a particular limit, better go clean up memory.

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

GC_FOR_ALLOC suggests to me something more serious is happening if I'm trying to create an object and there's no memory left to do it.

GC 消息是否有优先级或严重性"级别?

Is there a priority or "seriousness" level for the GC messages?

推荐答案

从某种意义上说，GC_FOR_ALLOC比GC_CONCURRENT更严重，因为GC_FOR_ALLOC 表示没有足够的可用内存来满足分配请求，因此需要进行垃圾回收，而 GC_CONCURRENT 仅表示 GC 感觉像是在运行，通常是因为可用内存量低于分配后的某个阈值.

In a sense, GC_FOR_ALLOC is more serious than GC_CONCURRENT, because GC_FOR_ALLOC means there were not enough free memory to fulfill an allocation request, so a garbage collection was necessary, whereas GC_CONCURRENT just means that the GC felt like running, typically because the amount of free memory became lower than a certain threshold after an allocation.

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

A GC_FOR_ALLOC is by itself not a sign of a problem in your application however:

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

• Android applications start with a small heap which grows (up to a point) when applications require more and more memory, and a GC_FOR_ALLOC is done before increasing the size of the heap. In this case GC_FOR_ALLOC is perfectly normal.
• If you allocate memory faster than the concurrent GC has time to free it up, GC_FOR_ALLOC is inevitable. And there's nothing inherently wrong with allocating memory faster than the concurrent GC can free up memory.

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

A more serious type of GC on Android is GC_BEFORE_OOM, which is performed when an allocation request fails even after GC_FOR_ALLOC and when the application heap has grown as big as it is allowed to be. When this happen, as a last resort, Dalvik will try to release SoftReferences as well, before doing a final attempt at allocating memory and if that fails throw an OutOfMemory exception.

如果你想看看这个逻辑的代码，它在 tryMalloc() 中/dalvik.git;a=blob;f=vm/alloc/Heap.cpp;h=9eee817e5e5cc1115041c5548214292a7f6e1090;hb=HEAD">dalvik.git/vm/alloc/Heap.cpp

If you're curious to look at the code for this logic, it is in tryMalloc() in dalvik.git/vm/alloc/Heap.cpp

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

Anyway, if you don't mind, I doubt that looking at logcat output is the most efficient way to debug your garbage collection problems. I don't know what specific problem you are having, but have you looked into tools such as the Allocation Tracker in DDMS and analyzing heap dumps with the help of the hprof-conv tool? (See http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html for example to get started.)

这篇关于GC_FOR_ALLOC 是否更“严重"?在调查内存使用情况时?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！