Java jmap实时堆转储如何包含无法访问的对象?

Java jmap实时堆转储如何包含无法访问的对象?,java,heap-dump,concurrent-mark-sweep,Java,Heap Dump,Concurrent Mark Sweep,我使用jmap使用CMS GC转储应用程序的活动堆: jmap -dump:live,format=b,file=heap.hprof <pid> 我认为使用-dump:live意味着它将只包含可访问的对象 应用程序的gc.log文件可疑地缺少由我调用jmap引起的任何完整gc,而是在我获取转储的任一侧显示以下行: 2019-07-17T09:32:59.808+0200: 33177.365: [GC (GCLocker Initiated GC) 2019-07-17T09:3

我使用jmap使用CMS GC转储应用程序的活动堆:

jmap -dump:live,format=b,file=heap.hprof <pid>
我认为使用
-dump:live
意味着它将只包含可访问的对象

应用程序的gc.log文件可疑地缺少由我调用jmap引起的任何完整gc,而是在我获取转储的任一侧显示以下行:

2019-07-17T09:32:59.808+0200: 33177.365: [GC (GCLocker Initiated GC) 2019-07-17T09:32:59.808+0200: 33177.365: [ParNew: 233127K->230550K(3397376K), 0.0265604 secs] 8029404K->8026859K(18496896K), 0.0267558 secs] [Times: user=0.92 sys=0.03, real=0.03 secs] 
2019-07-17T09:34:43.807+0200: 33281.363: [CMS-concurrent-preclean: 3.165/105.760 secs] [Times: user=143.74 sys=12.71, real=105.76 secs] 
在获取堆转储后第一次CMS重置后的第一个ParNew集合中,我看到堆的大小大致与堆转储中的大小相同(大约3-4Gb):


那么,在这种情况下,jmap可能没有触发一个完整的GC?这是可能的/可配置的吗?

看起来确实出乎意料

您可以尝试使用
jcmd GC.heap\u dump filename=MyHeapdump

这是新推荐的堆转储方法,默认情况下将强制执行完整的GC。 见:

GC.heap_dump[选项][参数]

生成Java堆的HPROF格式转储

影响:高-取决于Java堆大小和内容。除非指定了-all选项,否则请求完整GC


有这样一种说法,即年轻一代不是通过-dump:live收集的。我想这种行为没有改变。

您使用的是什么JDK?我相信我使用的是1.8.0版本
2019-07-17T09:32:59.808+0200: 33177.365: [GC (GCLocker Initiated GC) 2019-07-17T09:32:59.808+0200: 33177.365: [ParNew: 233127K->230550K(3397376K), 0.0265604 secs] 8029404K->8026859K(18496896K), 0.0267558 secs] [Times: user=0.92 sys=0.03, real=0.03 secs] 
2019-07-17T09:34:43.807+0200: 33281.363: [CMS-concurrent-preclean: 3.165/105.760 secs] [Times: user=143.74 sys=12.71, real=105.76 secs] 
2019-07-17T09:34:55.850+0200: 33293.407: [GC (GCLocker Initiated GC) 2019-07-17T09:34:55.850+0200: 33293.407: [ParNew: 3264332K->260834K(3397376K), 0.0435628 secs] 6814726K->3811241K(18496896K), 0.0438372 secs] [Times: user=1.45 sys=0.04, real=0.05 secs]