关于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。

（编辑：湖南网）

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