关于OpenJDK 11应用GC内存占用及NMT统计的技术咨询

看起来你在生产环境碰到了OpenJDK 11应用突然开始swap的棘手问题，结合NMT的统计数据，咱们一步步拆解你的两个疑问：

一、为什么NMT detail模式下统计的GC条目总和不等于顶层GC统计值？ #

你提到只搜索reserved and committed 1MB for GC这类条目加起来和NMT顶层显示的GC (reserved=4253MB, committed=4253MB)对不上，这是因为你漏统计了大部分GC相关的内存块：

• NMT顶层的GC统计是所有GC子系统内存的总和，涵盖了多种不同类型、不同大小的内存分配，而你只找了1MB的零散条目，自然会漏掉大部分。
• GC相关的内存包括：G1的标记缓冲区、回收线程栈、Remembered Set（RSet）的各类结构（比如Card Table、Region Maps）、GC临时工作区域、内部数据结构等，这些内存块有的是大页分配，有的是小内存块，并非都是1MB规格。
• 如果想手动核对，你需要在detail输出里把所有带GC前缀的条目（比如GC (G1 Young Generation)、GC (Card Table)、GC (RSet)等）的reserved/committed值全部加起来，才会接近顶层的统计结果。

二、如何查看GC具体的内存占用构成（除了开启debug日志外）？ #

你猜测是Remembered Set（RSet）占用过大的方向是对的——尤其是G1 GC下，MaxGCPauseMillis=100的设置会让G1更频繁地触发年轻代收集，为了严格控制暂停时间，会提前维护RSet，导致其内存占用上升。除了开启G1SummarizeRSetStatsPeriod和gc+remset=debug日志外，还有几个实用方法：

• 用jstat监控GC容量趋势：执行jstat -gccapacity <PID> 1000，观察各代（G1YoungGen、G1OldGen）以及GC相关区域的容量变化；也可以用jstat -gc <PID> 1000实时查看GC的内存使用、回收频率，间接判断RSet的压力。
• 分析GC日志和堆快照：开启-Xlog:gc,heap=info级别的GC日志，能看到每次GC时RSet的扫描时间、更新次数，从这些指标可以间接判断RSet是否过大。另外，堆快照里可以排查跨代引用的情况——如果老代有大量引用年轻代对象的情况，RSet必然会膨胀，这时候可以优化对象生命周期，减少跨代引用。
• 调整GC参数并观察变化：你打算把MaxGCPauseMillis调至200ms是很合理的尝试，更大的暂停时间允许G1在收集时做更充分的整理，减少RSet的维护开销。另外可以尝试调整G1RSetUpdatingPauseTimePercent（默认10%），如果这个值过小，G1会在后台消耗更多内存维护RSet，适当增大该值可能降低RSet的内存占用。
• 借助jcmd的其他命令：比如jcmd <PID> GC.heap_info可以获取堆的分区细节，jcmd <PID> VM.info能查看当前GC的配置和运行状态，辅助定位GC内存的占用点。

最后补充一点：既然RSS接近NMT统计的Java Heap + GC内存总和，说明应用的内存占用确实超出了物理内存，才触发swap。除了调整GC参数，也建议排查最近的代码变更、业务量变化，看是否引入了大对象、内存泄漏，或者堆分配模式的改变，这些都可能是GC内存突增的根源。

内容来源于stack exchange