关于Golang GC的一些误解，真的比Java算法更领先吗？

上面显示了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。

（编辑：孝感站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!