除了容量信息，内存使用率同样关键。运行jstat -gcutil pid可以统计GC的使用率百分比，直观看到各代内存的填充程度。同时，结合jstat -gcnew pid和jstat -gcnewcapacity pid，可以深入分析年轻代中Eden区和Survivor区的对象分布及回收情况，帮助定位新创建对象是否过早进入老年代。
如何分析和定位Java堆外内存泄漏？
理解jstat输出的术语含义是准确分析的基础。例如，S0C和S1C分别代表两个Survivor区的容量，S0U和S1U则是已使用空间。EC和EU对应Eden区的容量和已使用量。这些指标能帮助我们精确计算年轻代的内存分布，判断是否存在Survivor区空间不足导致对象提前晋升到老年代的情况。
为了更细致地观察各代内存的使用情况，可以执行jstat -gccapacity pid命令。这个命令能清晰展示Young、Old和Perm（或Metaspace）三代对象的实际占用大小与最大容量。比如PGCMN和PGCMX分别代表Perm代的最小和最大内存使用量，通过对比当前占用PGC与最大值，可以判断是否接近溢出。
针对Old代和Perm代的术语解析同样重要。OC和OU分别表示Old代的容量和已使用空间，PC和PU则对应Perm代。YGC和FGCT分别记录了Young GC和Full GC的次数及总耗时。如果GCT（总GC时间）占比过高，说明系统大量时间花在垃圾回收上，效率极低，需立即介入分析内存泄漏源头。
类加载信息的异常也可能间接反映内存问题。通过jstat -class pid命令，可以显示当前JVM加载类的数量及其所占用的空间。如果类的数量持续增加且不回收，可能导致元空间膨胀，进而引发OutOfMemoryError。这一步骤有助于排除因动态代理或框架滥用导致的类加载泄漏。
发现Java堆外内存泄漏的第一步是通过监控GC行为来初步判断。可以使用jstat -gc pid命令来查看GC的详细统计信息，特别是关注Young GC和Full GC的次数以及耗时。如果Full GC频率异常增高且内存未能有效释放，这往往是堆外内存或元空间出现问题的重要信号。
老年代的内存状况也不容忽视。使用jstat -gcold pid和jstat -gcoldcapacity pid可以获取Old代对象的具体信息和容量占用。如果Old代持续快速增长且Full GC后无明显下降，可能意味着存在大对象泄漏或静态集合引用未释放。此外，jstat -gcpermcapacity pid可用于监控Perm代（或元空间）的容量变化，这是堆外内存泄漏的高发区。
JVM内部的编译活动也是排查线索之一。执行jstat -compiler pid可以查看实时编译的数量和耗时，而jstat -printcompilation pid则显示当前VM正在执行的编译任务。虽然这些主要关注性能，但如果编译失败或频繁重置，可能暗示内存压力过大，间接影响堆外内存的稳定性。
年轻代的容量配置参数也需要关注。NGCMN和NGCMX定义了年轻代的最小和最大初始化大小，NGC则是当前容量。OGC和OGCMX分别对应Old代的当前和最大容量。通过监控这些参数，可以判断JVM的内存分配策略是否合理。如果Young代扩容频繁但回收效果不佳，可能需要调整堆大小或GC算法。
Perm代和Survivor区的最大容量限制也不容忽视。PGCMX和PGCMN定义了Perm代的最大和最小容量，而S0CMX、S1CMX和ECMX则分别定义了两个Survivor区和Eden区的最大容量。了解这些上限有助于判断是否因默认配置过小导致内存溢出。例如，DSS表示当Eden区满时，需要Survivor区的当前容量，若此值过大可能引发内存压力。
最后，持有次数限制TT和最大持有次数限制MTT是对象晋升策略的关键参数。TT决定了对象在Survivor区存活多久后会被移动到老年代。如果MTT设置不当，可能导致大量短命对象过早进入老年代，增加Full GC的频率。结合上述所有指标，综合判断JVM的内存健康状态，才能有效定位堆外内存泄漏的根本原因。