上面显示了GC trace(1405)。最终将涉及其中大部分内容,但是现在只关注1045 GC trace的内存部分。
- // Memory7MB : Heap memory in-use before the Marking started
- 11MB : Heap memory in-use after the Marking finished
- 6MB : Heap memory marked as live after the Marking finished
- 10MB : Collection goal for heap memory in-use after Marking finished
通过此GC trace可以看出,在标记工作开始之前,使用中的堆内存量为7MB。标记工作完成后,使用中的堆内存量达到11MB。这意味着在收集过程中有4MB新分配内存。标记工作完成后活动堆内存量为6MB。这意味着在下一次垃圾收集启动前,应用程序可以将堆内存增加到12MB。
你可以看到垃圾收集器Mark的目标和实际值之间有1MB差异。标记工作完成后正在使用的堆内存量为11MB而不是10MB。因为Mark目标是根据当前正在使用的堆内存量等信息计算出来的。应用程序的改变导致在Marking之后使用更多堆内存。
如果查看下一个GC trace(1406),可以看到在2ms内发生了很多变化。
- gc 1406 @6.070s 11%: 0.051+1.8+0.076 ms clock, 0.61+2.0/2.5/0+0.91 ms cpu, 8->11->6 MB, 13 MB goal, 12 P
-
- // Memory
- 8MB : Heap memory in-use before the Marking started
- 11MB : Heap memory in-use after the Marking finished
- 6MB : Heap memory marked as live after the Marking finished
- 13MB : Collection goal for heap memory in-use after Marking finished
这里显示了本次垃圾收集在上一次垃圾收集开始后2ms(6.068s对6.070s)就开始,使用中的堆内存达到8MB。由于应用程序大量分配内存,并且垃圾收集器希望减少此收集期间的因为Mark Assist导致的延迟,垃圾收集可能会提前。
还有两点需要注意。这次垃圾收集器完成了目标。标记完成后正在使用的堆内存量为11MB而不是13MB,少了2 MB。标记完成后活动堆内存依然是6MB。
可以通过添加gcpacertrace = 1从GC trace中获取更多详细信息。这会导致垃圾收集器打印有关并发起搏器内部状态的信息。
- $ export GODEBUG=gctrace=1,gcpacertrace=1 ./app
-
- Sample output:
- gc 5 @0.071s 0%: 0.018+0.46+0.071 ms clock, 0.14+0/0.38/0.14+0.56 ms cpu, 29->29->29 MB, 30 MB goal, 8 P
- pacer: sweep done at heap size 29MB; allocated 0MB of spans; swept 3752 pages at +6.183550e-004 pages/byte
- pacer: assist ratio=+1.232155e+000 (scan 1 MB in 70->71 MB) workers=2+0
- pacer: H_m_prev=30488736 h_t=+2.334071e-001 H_T=37605024 h_a=+1.409842e+000 H_a=73473040 h_g=+1.000000e+000 H_g=60977472 u_a=+2.500000e-001 u_g=+2.500000e-001 W_a=308200 goalΔ=+7.665929e-001 actualΔ=+1.176435e+000 u_a/u_g=+1.000000e+000
运行GC trace可以告诉你很多关于应用程序的运行状况和收集器速度的信息。收集器运行的速度在收集过程中起着重要作用。
起博
垃圾收集器使用调步算法,该算法用于确定何时开始垃圾收集。该算法依赖于运行中的应用程序的信息以及应用程序分配内存的压力。压力即应用程序在给定时间内分配堆内存的速度。正是压力决定了垃圾回收器的速度。
(编辑:ASP站长网)
|