jmap -dump:live为啥会触发Full GC

昨天组里的新人小朋友问是不是每执行一次jmap -dump:live都会触发一次Full GC,因为当时他在做性能测试时某应用已经好几个小时没有一次FGC了，结果他执行了下dump就增加了次FGC。

我当时模糊回答应该会，以前看过哪篇文章好像提过^-^，不过本着严谨不误导新人小朋友的原则，还是找时间抽空验证实践了把：

测试环境：linux , sun jdk 1.6.07 , 32位

测试结果： jmap -dump:live 以及 jmap -histo:live都会触发Full GC，即使加上JVM参数-XX:+DisableExplicitGC也不影响结果

那么为什么呢？ 其实大概猜也能知道，live选项的，如果FGC后，看到的活的对象比没有FGC的自然更精确。

我们来通过源码验证学习一下：

入口自然是$j2se/src/share/classes/sun/tools/JMap.java

关键点是

VirtualMachine vm = attach(pid);
InputStream in = ((HotSpotVirtualMachine)vm).
heapHisto(live ? LIVE_OBJECTS_OPTION : ALL_OBJECTS_OPTION);

以及

InputStream in = ((HotSpotVirtualMachine)vm).
dumpHeap((Object)filename,
(live ? LIVE_OBJECTS_OPTION : ALL_OBJECTS_OPTION));

于是找到这里

HotSpotVirtualMachine.java:

public InputStream dumpHeap(Object … args) throws IOException {
return executeCommand(“dumpheap”, args);

}

和
public InputStream heapHisto(Object … args) throws IOException {
return executeCommand(“inspectheap”, args);
}

接着看到

LinuxVirtualMachine.java:

先是创建UNIX socket，然后连到target VM，把dumpheap或inspectheap命令通过socket发过去。

那么具体的inspectheap在sun hotspot核心代码里是如何处理的呢？

看这个 $hotspot/src/share/vm/services/attachListener.cpp

heap_inspection函数有如下关键代码：

VM_GC_HeapInspection heapop(out, live_objects_only /* request full gc */, true /* need_prologue */);

同样dumpheap在hotspot里也是这个文件里处理的：

jint dump_heap(AttachOperation* op, outputStream* out) {
…
// Request a full GC before heap dump if live_objects_only = true
// This helps reduces the amount of unreachable objects in the dump
// and makes it easier to browse.
HeapDumper dumper(live_objects_only /* request GC */);
int res = dumper.dump(op->arg(0));
…
这下我们就明白了，与实验结果也对上号了

参考资料： http://forums.java.net/jive/message.jspa?messageID=115907