正确理解内存回收log信息

当系统发生内存回收,会有logcat信息。
那么如何正确理解内存回收信息呢?

有两种类型的回收信息log:虚拟机时代的log和ART时代的log

虚拟机时代的log


每次产生GC时间,log格式如下:

D/dalvikvm(PID): GC_Reason Amount_freed, Heap_stats, External_memory_stats, Pause_time

示例:

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms

格式解析
GC_Reason

  • GC_CONCURRENT
    当堆开始填满时触发并发GC,回收内存
  • GC_FOR_MALLOC
    当应用尝试分配内存时,此时堆已经用完,系统不得不停止app和回收内存。
  • GC_HPROF_DUMP_HEAP
    当请求创建一个HPROF文件(用于分析内存),触发GC。
  • GC_EXPLICIT
    代码中明确的调用gc()(不建议如此使用)
  • GC_EXTERNAL_ALLOC
    这种内存回收在API版本为10及更小的版本发生。

Amount freed
本次回收的内存大小

Heap stats
堆内存状态:空闲堆内存百分比使用中的对象数/堆内存总大小

External memory stats
在API 10及之下版本,外部分配占用的堆内存大小/外部分配最大限制内存大小

Pause time
大的堆栈会有更长停顿时间。log显示两个停顿时间:开始回收时的停顿时间和结束时的停顿时间。

内存回收的log收集起来,查找堆状态的增长信息(3571K/9991K),如果一直在增长,可能存在内存泄漏。

ART时代log


不像虚拟机,ART不会记录非明确调用执行的GC。GC被打印仅仅是因为认为运行慢了。更准准确的说,GC停顿超过5ms或者GC过程停顿超过100ms。如果app没有处于可察觉停顿状态(如后台运行),那么没有GC被认为是慢的。确定的GC调用总会被记录。

ART的内存回收包含以下信息

I/art: GC_Reason GC_Name Objects_freed(Size_freed) AllocSpace Objects,
    Large_objects_freed(Large_object_size_freed) Heap_stats LOS objects, Pause_time(s)

例如

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects,
    21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms

内容解析
GC Reason
什么触发了GC和回收了什么?原因如下

  • Concurrent
    并发GC不会阻塞app线程。该GC运行在后台线程且不会阻止内存申请。
  • Alloc
    该GC被发起,是因为在堆内存已经申请使用完后再次申请内存。这种情况,GC运行在内存申请的线程。
  • Explicit
    内存回收被app直接的请求执行,例如,调用gc()。类似虚拟机,ART中最好的使用时详细系统GC,尽量避免直接调用GC。直接调用GC不鼓励使用,因为直接调用会阻塞申请内存的线程和不必要的浪费CPU时间片。直接调用GC,其他线程被抢占,也会导致无法预料的异常(如卡顿、抖动、停止运行)。
  • NativeAlloc
    本地内存申请存在压力,如Bitmaps或者渲染申请内存,会触发内存回收。
  • CollectorTransition
    回收被堆管理策略转换导致的。在运行时改变GC策略,触发GC(例如在app可察觉停顿状态下,app改变GC策略)。回收策略转换包括将所有对象从free-list backed space拷贝到 bump pointer space (or visa versa)。
  • HomogeneousSpaceCompact
    同构空间压缩是指从空闲列表空间到空闲列表空间的压缩,通常发生在应用程序移动到一个难以察觉的暂停进程状态时。这样做的主要原因是减少RAM的使用和整理堆的碎片。
  • DisableMovingGc
    这不是一个真正的GC事件原因,但需要注意的是,回收会因为调用GetPrimitiveArrayCritical被阻塞。当并发堆压缩发生时。一般情况下,强烈不鼓励使用GetPrimitiveArrayCritical,因为它对移动收集器有限制。
  • HeapTrim
    这不是一个真正的GC事件原因,但需要注意的是,回收会被阻塞指导堆内存被整理完成。

GC Name
ART有多种不同的GC可被执行。

  • Concurrent mark sweep (CMS)
    收集回收整个堆内存除了图像部分内存。
  • Concurrent partial mark sweep
    几乎全堆收集,收集除了图像和zygote以外的所有空间。
  • Concurrent sticky mark sweep
    分代收集器,只能释放自上次GC以来分配的对象。这种垃圾收集比完全或部分标记清理运行得更频繁,因为它速度更快,暂停时间更短。
  • Marksweep + semispace
    非并发的、复制的GC,用于堆转换和同质空间压缩(以整理堆的碎片)。

Objects freed
本次回收,从非大对象空间回收的对象数。
Sized freed
本次回收,从非大对象空间回收的字节数
Large Object freed
本次回收,从大对象空间回收的对象数
Heap stats
剩余堆内存百分比,使用中的对象数/整个堆大小。
Pause times
一般来说,停顿时间与GC运行时修改的对象引用的数量成比例。目前,ART CMS的GCs只有一次停顿,在GC快结束的时候。运行的GC有一个很长的停顿,在大部分GC持续时间中都是如此。

如果在log中看到大量的GC事件,关注堆状态增长的变化(如上例中的25MB/38MB)。如果堆使用一直在增长,不曾变小过,那么可能存在内存泄漏。另外,如果看到的GC都是因为“Alloc”触发的,那么app运行在一个接近所有堆容量的状态,在不久就会出现OOM的情况。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值