我目前正在调查我的Android应用程序中的垃圾回收问题,我很好奇是否GC_FOR_ALLOC比其他GC消息(例如GC_CONCURRENT)更能反映出一个更大的问题。
据我所知,GC_CONCURRENT正在执行垃圾回收器应该执行的操作。 堆已经达到了特定的限制,最好清理内存。
如果我正在尝试创建一个对象并且没有足够的内存来完成它,GC_FOR_ALLOC对我来说意味着有更严重的问题发生。
GC消息是否有优先级或“严重程度”级别?
我目前正在调查我的Android应用程序中的垃圾回收问题,我很好奇是否GC_FOR_ALLOC比其他GC消息(例如GC_CONCURRENT)更能反映出一个更大的问题。
据我所知,GC_CONCURRENT正在执行垃圾回收器应该执行的操作。 堆已经达到了特定的限制,最好清理内存。
如果我正在尝试创建一个对象并且没有足够的内存来完成它,GC_FOR_ALLOC对我来说意味着有更严重的问题发生。
GC消息是否有优先级或“严重程度”级别?
GC_FOR_ALLOC
比GC_CONCURRENT
更严重,因为GC_FOR_ALLOC
意味着没有足够的空闲内存来满足分配请求,因此需要进行垃圾回收,而GC_CONCURRENT
仅表示GC感觉到需要运行,通常是因为分配后可用的空闲内存量低于某个阈值。GC_FOR_ALLOC
本身并不是应用程序出现问题的标志:
GC_FOR_ALLOC
。在这种情况下,GC_FOR_ALLOC
是完全正常的。GC_FOR_ALLOC
是不可避免的。快速分配内存并不一定有问题。GC_BEFORE_OOM
,当分配请求失败甚至经过GC_FOR_ALLOC
并且应用程序堆已经增长到允许的最大值时执行。当这种情况发生时,作为最后的手段,Dalvik将尝试在进行内存分配的最后一次尝试之前释放SoftReferences,如果仍然失败,则抛出OutOfMemory异常。
如果您想查看此逻辑的代码,请查看dalvik.git/vm/alloc/Heap.cpp中的tryMalloc()
。
无论如何,如果您不介意的话,我觉得查看logcat输出并不是调试垃圾回收问题最有效的方法。我不知道您遇到了什么具体问题,但您是否尝试过使用DDMS中的Allocation Tracker工具,并借助hprof-conv工具分析堆转储?(例如,请参见http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html以开始。)