在调查内存使用情况时,GC_FOR_ALLOC是否更“严重”?

我目前正在调查Android应用程序的垃圾收集问题,我很想知道GC_FOR_ALLOC是否比GC_CONCURRENT等其他GC消息有更大的问题。

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

GC_FOR_ALLOC向我暗示,如果我正在尝试创build一个对象,并且没有剩余的内存,那么就会发生更严重的事情。

GC消息有优先级还是“严重”级别?

Solutions Collecting From Web of "在调查内存使用情况时,GC_FOR_ALLOC是否更“严重”?"

从某种意义上说, GC_FOR_ALLOCGC_CONCURRENT更严重,因为GC_FOR_ALLOC意味着没有足够的空闲内存来完成分配请求,所以垃圾收集是必要的,而GC_CONCURRENT只是意味着GC感觉像是在运行,通常是因为free内存分配后低于一定的门槛。

然而, GC_FOR_ALLOC本身并不是您应用程序中存在问题的标志:

  • 当应用程序需要越来越多的内存时,Android应用程序以一个小的堆开始(一直到一点), GC_FOR_ALLOC在增加堆的大小之前完成。 在这种情况下, GC_FOR_ALLOC是完全正常的。
  • 如果分配内存的速度比并发GC有时间释放更快, GC_FOR_ALLOC是不可避免的。 而且,分配内存的速度比并发GC可以释放内存的速度更快。

Android上更严重的GCtypes是GC_BEFORE_OOM ,当GC_BEFORE_OOM发生分配请求失败时,以及应用程序堆增长到允许的GC_FOR_ALLOC时, GC_FOR_ALLOC会执行GC_FOR_ALLOC 。 发生这种情况时,作为最后的手段,Dalvik将尝试释放SoftReferences,最后尝试分配内存,如果失败则抛出OutOfMemoryexception。

如果您好奇地查看这个逻辑的代码,它在dalvik.git / vm / alloc / Heap.cpp中的tryMalloc()

无论如何,如果你不介意,我怀疑看logcat输出是debugging垃圾收集问题的最有效的方法。 我不知道你有什么具体的问题,但是你有没有看过DDMS中的Allocation Tracker等工具,并借助hprof-conv工具分析堆转储? (参见http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html例如开始。)