java 堆外内存 查看_JAVA堆外内存排查小结

最新推荐文章于 2025-04-03 10:46:49 发布
最新推荐文章于 2025-04-03 10:46:49 发布
阅读量2.9k 收藏 6
点赞数
文章标签： java 堆外内存 查看
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_29765215/article/details/114116042
版权
本文详述了一次针对Java服务堆外内存异常增长的排查过程，涉及pmap、gdb、perf等工具的使用，发现问题是由于GZIPInputStream未正确关闭导致的bzip内存泄漏。解决方案是确保及时关闭流以释放堆外内存。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

简介JVM堆外内存难排查但经常会出现问题，这可能是目前最全的JVM堆外内存排查思路。

通过本文，你应该了解：pmap 命令

gdb 命令

perf 命令

内存 RSS、VSZ的区别

java NMT

起因

这几天遇到一个比较奇怪的问题，觉得有必要和大家分享一下。我们的一个服务，运行在docker上，在某个版本之后，占用的内存开始增长，直到docker分配的内存上限，但是并不会OOM。版本的更改如下：升级了基础软件的版本

将docker的内存上限由4GB扩展到8GB

上上个版本的一项变动是使用了EhCache的Heap缓存

没有读文件，也没有mmap操作

使用jps 查看启动参数，发现分配了大约3GB的堆内存

[root]$ jps -v

75 Bootstrap -Xmx3000m -Xms3000m -verbose:gc -Xloggc:/home/logs/gc.log -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSCompactAtFullCollection -XX:MaxTenuringThreshold=10 -XX:MaxPermSize=128M -XX:SurvivorRatio=3 -XX:NewRatio=2 -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

使用ps查看进程使用的内存和虚拟内存 ( Linux内存管理 )。除了虚拟内存比较高达到17GB以外，实际使用的内存RSS也夸张的达到了7GB，远远超过了-Xmx的设定。

[root]$ ps -p 75 -o rss,vsz

RSS VSZ 7152568 17485844

排查过程

明显的，是有堆外内存的使用，不太可能是由于EhCache引起的(因为我们使用了heap方式)。了解到基础软件的升级涉及到netty版本升级，netty会用到一些DirectByteBuffer，第一轮排查我们采用如下方式：jmap -dump:format=b,file=75.dump 75 通过分析堆内存找到DirectByteBuffer的引用和大小

部署一个升级基础软件之前的版本，持续观察

部署另一个版本，更改EhCache限制其大小到1024M

考虑到可能由Docker的内存分配机制引起，部署一实例到实体机

结果4个环境中的服务，无一例外的都出现了内存超用的问题。问题很奇怪，宝宝睡不着觉。

pmap

为了进一步分析问题，我们使用pmap查看进程的内存分配，通过RSS升序序排列。结果发现除了地址000000073c800000上分配的3GB堆以外，还有数量非常多的64M一块的内存段，还有巨量小的物理内存块映射到不同的虚拟内存段上。但到现在为止，我们不知道里面的内容是什么，是通过什么产生的。

[root]$ pmap -x 75 | sort -n -k3

.....省略N行

0000000040626000 55488 55484 55484 rwx-- [ anon ]

00007fa07c000000 65536 55820 55820 rwx-- [ anon ]

00007fa044000000 65536 55896 55896 rwx-- [ anon ]

00007fa0c0000000 65536 56304 56304 rwx-- [ anon ]

00007f9db8000000 65536 56360 56360 rwx-- [ anon ]

00007fa0b8000000 65536 56836 56836 rwx-- [ anon ]

00007fa084000000 65536 57916 57916 rwx-- [ anon ]

00007f9ec4000000 65532 59752 59752 rwx-- [ anon ]

00007fa008000000 65536 60012 60012 rwx-- [ anon ]

00007f9e58000000 65536 61608 61608 rwx-- [ anon ]

00007f9f18000000 65532 61732 61732 rwx-- [ anon ]

00007fa018000000 65532 61928 61928 rwx-- [ anon ]

00007fa088000000 65536 62336 62336 rwx-- [ anon ]

00007fa020000000 65536 62428 62428 rwx-- [ anon ]

00007f9e44000000 65536 64352 64352 rwx-- [ anon ]

00007f9ec0000000 65528 64928 64928 rwx-- [ anon ]

00007fa050000000 65532 65424 65424 rwx-- [ anon ]

00007f9e08000000 65512 65472 65472 rwx-- [ anon ]

00007f9de0000000 65524 65512 65512 rwx-- [ anon ]

00007f9dec000000 65532 65532 65532 rwx-- [ anon ]

00007f9dac000000 65536 65536 65536 rwx-- [ anon ]

00007f9dc8000000 65536 65536 65536 rwx-- [ anon ]

00007f9e30000000 65536 65536 65536 rwx-- [ anon ]

00007f9eb4000000 65536 65536 65536 rwx-- [ anon ]

00007fa030000000 65536 65536 65536 rwx-- [ anon ]

00007fa0b0000000 65536 65536 65536 rwx-- [ anon ]

000000073c800000 3119140 2488596 2487228 rwx-- [ anon ]

total kB 17629516 7384476 7377520

通过google，找到以下资料 Linux glibc >= 2.10 (RHEL 6) malloc may show excessive virtual memory usage)

文章指出造成应用程序大量申请64M大内存块的原因是由Glibc的一个版本升级引起的，通过export MALLOC_ARENA_MAX=4可以解决VSZ占用过高的问题。虽然这也是一个问题，但却不是我们想要的，因为我们增长的是物理内存，而不是虚拟内存。

NMT

幸运的是 JDK1.8有Native Memory Tracker可以帮助定位。通过在启动参数上加入-XX:NativeMemoryTracking=detail就可以启用。在命令行执行jcmd可查看内存分配。

#jcmd 75 VM.native_memory summary

Native Memory Tracking: Total: reserved=5074027KB, committed=3798707KB - Java Heap (reserved=3072000KB, committed=3072000KB) (mmap: reserved=3072000KB, committed=3072000KB) - Class (reserved=1075949KB, committed=28973KB) (classes #4819) (malloc=749KB #13158) (mmap: reserved=1075200KB, committed=28224KB) - Thread (reserved=484222KB, committed=484222KB) (thread #470) (stack: reserved=482132KB, committed=482132KB) (malloc=1541KB #2371) (arena=550KB #938) - Code (reserved=253414KB, committed=25070KB) (malloc=3814KB #5593) (mmap: reserved=249600KB, committed=21256KB) - GC (reserved=64102KB, committed=64102KB) (malloc=54094KB #255) (mmap: reserved=10008KB, committed=10008KB) - Compiler (reserved=542KB, committed=542KB) (malloc=411KB #543) (arena=131KB #3) - Internal (reserved=50582KB, committed=50582KB) (malloc=50550KB #13713) (mmap: reserved=32KB, committed=32KB) - Symbol (reserved=6384KB, committed=6384KB) (malloc=4266KB #31727) (arena=2118KB #1) - Native Memory Tracking (reserved=1325KB, committed=1325KB) (malloc=208KB #3083) (tracking overhead=1117KB) - Arena Chunk (reserved=231KB, committed=231KB) (malloc=231KB) - Unknown (reserved=65276KB, committed=65276KB) (mmap: reserved=65276KB, committed=65276KB)

虽然pmap得到的内存地址和NMT大体能对的上，但仍然有不少内存去向成谜。虽然是个好工具但问题并不能解决。

gdb

非常好奇64M或者其他小内存块中是什么内容，接下来通过gdb dump出来。读取/proc目录下的maps文件，能精准的知晓目前进程的内存分布。

以下脚本通过传入进程id，能够将所关联的内存全部dump到文件中(会影响服务，慎用)。

grep rw-p /proc/$1/maps | sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' | while read start stop; do gdb --batch --pid $1 -ex "dump memory $1-$start-$stop.dump 0x$start 0x$stop"; done

更多时候，推荐之dump一部分内存。(再次提醒操作会影响服务，注意dump的内存块大小，慎用)。

gdb --batch --pid 75 -ex "dump memory a.dump 0x7f2bceda1000 0x7f2bcef2b000

[root]$ du -h *

dump 4.0K

55-00600000-00601000.dump 400K

55-00eb7000-00f1b000.dump 0

55-704800000-7c0352000.dump 47M

55-7f2840000000-7f2842eb8000.dump 53M

55-7f2848000000-7f284b467000.dump 64M

55-7f284c000000-7f284fffa000.dump 64M

55-7f2854000000-7f2857fff000.dump 64M

55-7f285c000000-7f2860000000.dump 64M

55-7f2864000000-7f2867ffd000.dump 1016K

55-7f286a024000-7f286a122000.dump 1016K

55-7f286a62a000-7f286a728000.dump 1016K

55-7f286d559000-7f286d657000.dump

是时候查看里面的内容了

[root]$ view 55-7f284c000000-7f284fffa000.dump

^@^@X+^?^@^@^@^@^@d(^?^@^@^@ ÿ^C^@^@^@^@^@ ÿ^C^@^@^@^@^@^@^@^@^@^@^@^@±<97>p^C^@^@^@^@ 8^^Z+^?^@^@ ^@^@d(^?^@^@ 8^^Z+^?^@^@ ^@^@d(^?^@^@

achine":524993642,"timeSecond":1460272569,"inc":2145712868,"new":false},"device":{"client":"android","uid":"xxxxx","version":881},"

device_android":{"BootSerialno":"xxxxx","CpuInfo":"0-7","MacInfo":"2c:5b:b8:b0:d5:10","RAMSize":"4027212","SdcardInfo":"xxxx","Serialno":"xxxx",

"android_id":"488aedba19097476","buildnumber":"KTU84P/1416486236","device_ip":"0.0.0.0","mac":"2c:5b:b8:b0:d5:10","market_source":"12","model":"OPPO ...more

纳尼？这些内容不应该在堆里面么？为何还会使用额外的内存进行分配？上面已经排查netty申请directbuffer的原因了，那么还有什么地方在分配堆外内存呢？

perf

传统工具失灵，快到了黔驴技穷的时候了，是时候祭出神器perf了。

使用 perf record -g -p 55 开启监控栈函数调用。运行一段时间后Ctrl+C结束，会生成一个文件perf.data。

执行perf report -i perf.data查看报告。

如图，进程大量执行bzip相关函数。搜索zip，结果如下：

-.-!

进程调用了Java_java_util_zip_Inflater_inflatBytes() 申请了内存，仅有一小部分调用Deflater释放内存。与pmap内存地址相比对，确实是bzip在搞鬼。

解决

java项目搜索zip定位到代码，发现确实有相关bzip压缩解压操作，而且GZIPInputStream有个地方没有close。

GZIPInputStream使用Inflater申请堆外内存，Deflater释放内存，调用close()方法来主动释放。如果忘记关闭，Inflater对象的生命会延续到下一次GC。在此过程中，堆外内存会一直增长。

原代码：

public byte[] decompress ( byte[] input) throws IOException {

ByteArrayOutputStream out = new ByteArrayOutputStream();

IOUtils.copy(new GZIPInputStream(new ByteArrayInputStream(input)), out);

return out.toByteArray();

}

修改后：

public byte[] decompress(byte[] input) throws IOException {

ByteArrayOutputStream out = new ByteArrayOutputStream();

GZIPInputStream gzip = new GZIPInputStream(new ByteArrayInputStream(input));

IOUtils.copy(gzip, out);

gzip.close();

return out.toByteArray();

}

经观察，问题解决。

佯良
关注
java 查看堆外内存占用_Java堆外内存排查小结
weixin_30646537的博客
02-24 7661
简介JVM堆外内存难排查但经常会出现问题，这可能是目前最全的JVM堆外内存排查思路。通过本文，你应该了解：pmap 命令gdb 命令perf 命令内存 RSS、VSZ的区别java NMT起因这几天遇到一个比较奇怪的问题，觉得有必要和大家分享一下。我们的一个服务，运行在docker上，在某个版本之后，占用的内存开始增长，直到docker分配的内存上限，但是并不会OOM。版本的更改如下：升级了基础...
java 非堆内存泄露_记一次堆外内存泄漏排查过程
weixin_39878549的博客
02-27 1334
本文涉及以下内容开启NMT查看JVM内存使用情况通过pmap命令查看进程物理内存使用情况smaps查看进程内存地址gdb命令dump内存块背景最近收到运维反馈，说有项目的一个节点的RSS已经是Xmx的两倍多了，因为是ECS机器所以项目可以一直运行，幸亏机器内存充足，不然就可能影响到其他应用了。排查问题通过跳板机登录到目标机器，执行top命令，再按c，看到对应的进程所占用的RES有8个多G(这里当时...
Java堆外内存泄露场景总结.pdf
05-08
Java堆外内存泄露场景总结，包含几个常用的可能，如：JNI，NIO，AWT/Swing，Inflater&Deflater;
java 堆外内存 查看_JAVA堆外内存
weixin_28997071的博客
02-13 491
JVM可以使用的内存分外2种：堆内存和堆外内存.堆内存完全由JVM负责分配和释放，如果程序没有缺陷代码导致内存泄露，那么就不会遇到java.lang.OutOfMemoryError这个错误。使用堆外内存，就是为了能直接分配和释放内存，提高效率。JDK5.0之后，代码中能直接操作本地内存的方式有2种：使用未公开的Unsafe和NIO包下ByteBuffer。关于Unsafe对象的简介和获取方式,可...
- 如何监控和诊断JVM堆内和堆外内存使用？
最新发布
qq_33240556的博客
04-03 892
上一讲我介绍了JVM内存区域的划分，总结了相关的一些概念，今天我将结合JVM参数、工具等方面，进一步分析JVM内存结构，包括外部资料相对较少的堆外部分。今天我要问你的问题是，如何监控和诊断JVM堆内和堆外内存使用？
Java 堆外内存
CodeFlight
04-14 1641
在 Java 虚拟机中，分配对象基本上都是在堆上进行的，然而在有些情况下，缓存的数据量非常大时，使用磁盘或者分布式缓存就会比较合适，这时**堆外缓存**就是一个比较合适的选择。一般会认为 Java 进程启动后，除了分配的堆（heap）内存之外的内存都为堆外内存。堆外内存在没有引用时，也会被 Java 垃圾收集器进行回收。
如何监控和诊断JVM堆内和堆外内存使用？
qq_24095055的博客
03-27 1289
文章目录 典型回答 了解 JVM 内存的方法有很多，具体能力范围也有区别，简单总结如下： 可以使用综合性的图形化工具，如 JConsole、VisualVM（注意，从 Oracle JDK 9 开始，VisualVM 已经不再包含在 JDK 安装包中）等。这些工具具体使用起来相对比较直观，直接连接到 Java 进程，然后就可以在图形化界面里掌握内存使用情况。 以 JConsole 为例，其内存页面可以显示常见的堆内存和各种堆外部分使用状态。 也可以使用命令行工具进行运行时查询，如 jstat 和 jm
Java服务堆外内存问题排查
qq_32000519的博客
12-29 3547
Java服务堆外内存问题排查思路
Java jcmd内存远大于top_Java堆外内存排查小结
weixin_35172715的博客
02-26 893
问题描述通过本文，你应该了解：1. pmap 命令2. gdb 命令3. perf 命令4. 内存 RSS、VSZ的区别5. java NMT这几天遇到一个比较奇怪的问题，觉得有必要和大家分享一下。我们的一个服务，运行在docker上，在某个版本之后，占用的内存开始增长，直到docker分配的内存上限，但是并不会OOM。版本的更改如下：升级了基础软件的版本将docker的内存上限由4GB扩展到8G...
JAVA堆外内存排查小结
LeZiJie的博客
06-01 502
简介 JVM堆外内存难排查但经常会出现问题，这可能是目前最全的JVM堆外内存排查思路。 通过本文，你应该了解： pmap 命令 gdb 命令 perf 命令 内存 RSS、VSZ的区别 java NMT 起因 这几天遇到一个比较奇怪的问题，觉得有必要和大家分享一下。我们的一个服务，运行在docker上，在某个版本之后，占用的内存开始增长，直到docker分配的内存上限，但是并不会OOM。版本的更改如下： 升级了基础软件的版本 将docker的内存上限由4GB扩展到8GB 上上...
Java堆外内存的使用
01-21
近经常有人问我在Java中使用堆外（off heap）内存的好处与用途何在。我想其他面临几样选择的人应该也会对这个答案感兴趣吧。 　　堆外内存其实并无特别之处。线程栈，应用程序代码，NIO缓存用的都是堆外内存。事实上在C或者C++中，你只能使用未托管内存，因为它们默认是没有托管堆（managed heap）的。在Java中使用托管内存或者“堆”内存是这门语言的一个特性。注意：Java并非这么做的语言。 　　new Object() vs 对象池 vs 堆外内存 　　new Object() 　　在Java 5.0以前，对象池一度非常流行。那个时候创建对象的开销是非常昂贵的。然而，从Ja
Java堆外内存
Bristor的博客
08-25 551
1. 首先了解堆内内存on-heap memory 2. 定义：off-heap memory 堆外内存就是把内存对象分配在Java虚拟机的堆以外的内存。这些内存直接受操作系统管理（而不是虚拟机）， 这样做的结果就是能够在一定程度上减少垃圾回收对应用程序造成的影响。 3. 特点 1、减少了垃圾回收 因为垃圾回收会暂停其他的工作。 2、加快了复制的速度 ...
JVM 堆外内存查看方法
Andrew_Chenwq的博客
10-23 1650
1：针对不知道怎么面试，面试没有信心的小伙伴，我们会给你一个offer保障。2：我们会监督你15-20天内把面试体系技术点掌握至少7成，这样足够你去找到满意的工作了。3：我们是面向面试学习指导，不会带你们去写代码，会把项目真实开发的迭代过程和技术细节如何实现业务功能都详细教清楚，你能在面试中流畅表达清楚就行了，项目经验你不用担心(技术老师提供的真实项目经验肯定拿的出手)，自己学和别人带着系统学，效率完全不一样。详情请点击这里offer突击训练营，给你一个offer的保障，求职跳槽的看过来！
转发 堆外内存讲解
zhoucs86的博客
06-06 425
最近看了一篇文章《蚂蚁消息中间件 (MsgBroker) 在 YGC 优化上的探索》。 文章涉及JVM的垃圾回收，主要讲的是通过使用「堆外内存」对Young GC进行优化。 文章中介绍，MsgBroker消息中间件会对消息进行缓存，JVM需要为被缓存的消息分配内存，首先会被分配到年轻代。 当缓存中的消息由于各种原因，一直投递不成功，这些消息会进入老年代。 最终呈现的问题是YGC时间太长。 ...
java堆外内存排查方式
lz710117239的博客
04-22 402
堆外内存泄漏”排查及经验总结 https://zhuanlan.zhihu.com/p/60976273
java jvm 进程内存占用排查. 除了堆之外
fei33423的专栏
04-28 5713
java 内存可分为: 堆和meta space .查看堆: jmap -heap pid查看metaSpace: 使用 jstat -gc pid mc mu.查看进程内的其他占用: top 里的rs占用 减去 jmap -heap 里的占用. /proc/$PID/mapssmaps是更详细的信息 pamp pid :anon 的意思是内存分配. $cat...
【Java进阶】如何监控和诊断JVM堆内和堆外内存使用？
兴趣是最好的老师
07-19 2467
结合 JVM 参数和特性，系统地分析了 JVM 堆内和堆外内存结构，相信你一定对JVM 内存结构有了比较深入的了解，在定制 Java 运行时或者处理 OOM 等问题的时候，思路也会更加清晰。
java 查看堆外内存占用_java问题之2：JVM堆外内存问题排查--删除
weixin_34776437的博客
02-19 2292
首先确认堆占用jmap 查看heap内存使用情况jmap -heap pid1可以查看到MetaspaceSize,CompressedClassSpaceSize,MaxMetaSizejmap和jdk版本有关系，有些jdk版本会查看不到内存信息，可以使用jstat来查看统计信息jstat 收集统计信息jstat -gc pid 10001S0C/S0U S1C/S1U EC/EU CCSC/C...
用pmap查看进程的堆内存和堆外内存
03-29
<think>好的，用户的问题是关于如何使用pmap来分析Java进程的堆内存和堆外内存的使用情况。我需要先回忆一下pmap的基本用法，以及Java内存管理相关的知识。 首先，pmap是Linux下的一个工具，可以显示进程的内存映射情况。每个条目对应一段虚拟内存区域，包括地址、大小、权限、映射文件等信息。用户可能已经知道这些，但需要指导如何具体分析堆和堆外内存。 Java的内存分为堆内存（Heap）和堆外内存（Native Memory）。堆内存由JVM的垃圾回收器管理，而堆外内存则包括直接内存（如NIO的DirectBuffer）、JNI分配的内存、线程栈、元数据区等。这些堆外内存不会显示在标准的JVM内存监控工具中，比如jstat，所以pmap可能是一个补充手段。 接下来，用户提供的引用中提到NMT（Native Memory Tracking）和pmap结合使用。引用[2]和[3]提到NMT可以跟踪JVM内部的内存使用，而pmap查看进程的地址空间。所以，可能需要先启用NMT来获取更详细的信息，再结合pmap的结果进行分析。 首先，如何启用NMT呢？启动JVM时加上参数-XX:NativeMemoryTracking=detail，然后使用jcmd命令来获取NMT的数据。例如jcmd <pid> VM.native_memory detail。这可以帮助用户看到JVM自身对Native Memory的使用情况，比如内部数据结构、线程、代码缓存等。但用户的问题是用pmap来分析，所以需要将pmap的输出和NMT的数据结合起来。 pmap的输出中有多个内存区域，其中堆内存通常对应的是Java堆，也就是通过-Xmx设置的最大堆大小。在pmap中，堆内存可能显示为匿名内存块（anon），并且大小接近-Xmx的值。例如，如果用户设置了-Xmx4G，pmap中可能会有一个大约4G的匿名内存段，这可能就是堆内存。 而堆外内存则可能包括其他部分，比如由JVM分配的元空间（Metaspace）、线程栈、JNI库、直接缓冲区等。这些在pmap中可能表现为不同的内存区域，比如映射到文件的内存（比如libjvm.so）、匿名内存等。需要注意的是，pmap显示的是虚拟内存，而实际使用的物理内存（RSS）可能不同，用户可能更关心实际占用情况。 用户可能需要用pmap -x <pid>来查看更详细的信息，包括RSS。然后，他们可以过滤出较大的内存块进行分析。例如，查找大的匿名内存块，其中可能包括堆和直接内存。但如何区分堆和堆外呢？ 堆的大小通常由JVM参数控制，所以用户可以根据启动参数中的-Xmx和-Xms来估计堆内存的大小。而堆外内存可能包括多个部分，如NMT中显示的Internal（代码缓存、GC内部结构等）、Thread（线程栈）、Arena（内存分配区）等。这些在pmap中可能分散在不同的内存区域。 例如，元空间（Metaspace）在Java 8之后使用本地内存，所以如果用户看到较大的匿名内存块，并且不属于堆的大小，可能是Metaspace。线程栈通常每个线程分配一定的内存（如1MB），所以如果有100个线程，大约会有100MB的栈内存，这在pmap中可能有多个相同大小的区域。 此外，直接内存（Direct Buffer）是通过ByteBuffer.allocateDirect分配的，这部分内存也会在pmap中显示为匿名内存。用户可能需要结合NMT的数据，查看DirectBuffer的大小，然后在pmap中找到对应的大块内存。 可能的步骤是： 1. 使用NMT获取详细的堆外内存分配情况。 2. 使用pmap查看进程的内存映射，找出大块的内存区域。 3. 对比两者的信息，确定哪些区域属于堆，哪些属于堆外内存。 用户还可能需要注意，pmap中的内存区域可能有重复统计，因为不同的内存段可能属于不同的类别。例如，JVM本身的代码和库文件会映射到内存中，但这些通常属于只读或共享内存，可能不是用户关注的堆外内存部分。 另外，用户可能需要关注anon（匿名内存）和堆（heap）的关系。在pmap中，堆内存通常是连续的匿名内存块，而其他如mmap分配的内存可能是文件映射或匿名大页内存。 用户可能遇到的问题是如何确定某个匿名内存块是否属于堆。这时候可以结合JVM的堆地址范围，通过pmap的输出中的地址空间来判断。例如，JVM启动时可能会输出堆的起始地址，或者在NMT的输出中给出堆的地址范围，然后和pmap中的地址进行比对。 不过，这可能比较复杂。更简单的方法可能是根据大小来判断，比如堆的大小由-Xmx决定，所以最大的匿名内存块可能就是堆。剩下的较大匿名块可能是直接内存或其他堆外分配。 总结起来，用户需要： 1. 启用NMT，获取详细的堆外内存信息。 2. 使用pmap -x查看进程的内存映射，关注RSS较大的区域。 3. 结合NMT的数据，分析各个内存区域的归属，如堆、Metaspace、Direct Buffer等。 可能还需要注意，pmap显示的是虚拟内存大小，而实际使用的物理内存可能不同，所以关注RSS列更为准确。此外，JVM的内存管理可能存在碎片，所以多个小块的匿名内存可能属于堆外分配。 最后，用户可能需要一个具体的例子来说明这个过程。例如，使用pmap输出中的某个大块anon内存，对应NMT中的某个部分，如Internal或Direct Buffer。通过这样的对比，用户可以确定堆外内存的主要使用情况。</think>### 分步说明：如何通过 pmap 分析 Java 进程的堆内存与堆外内存 #### 1. **获取目标进程的 PID** 使用 `jps` 或 `ps` 命令获取 Java 进程的 PID： ```bash jps -l ``` #### 2. **使用 pmap 查看内存映射** 执行以下命令，查看进程的详细内存映射（重点关注 **RSS（实际物理内存占用）** 和 **Anonymous（匿名内存）** 字段）： ```bash pmap -x <PID> | less ``` **输出示例**： ``` Address Kbytes RSS Dirty Mode Mapping 0000000000400000 4 4 0 r-x-- java 0000000000600000 4 4 4 rw--- java ... 00007f3d80000000 4194304 1048576 1048576 rw--- [anon] <-- 可能是堆内存 00007f3dc0000000 262144 0 0 ----- [anon] ... ``` #### 3. **识别堆内存** - **堆内存特点**： - 通常是最大的匿名内存块（`[anon]`），大小接近 JVM 参数 `-Xmx` 设置的值。 - 在 pmap 中表现为连续的大块 `rw---` 权限的匿名内存（如示例中的 `00007f3d80000000` 段）。 - **验证方法**： 结合 JVM 启动参数 `-Xmx` 的值，确认匿名内存块是否匹配。例如，若 `-Xmx4g`，则堆内存可能对应约 `4,194,304 KB`（即 4GB）的匿名内存段。 #### 4. **分析堆外内存（Native Memory）** - **堆外内存组成**： - **直接内存（Direct Buffer）**：通过 `ByteBuffer.allocateDirect()` 分配。 - **元空间（Metaspace）**：存储类元数据，由 `-XX:MaxMetaspaceSize` 控制。 - **线程栈**：每个线程默认约 1MB（由 `-Xss` 控制）。 - **JNI 代码与本地库**：如 `libjvm.so` 或第三方本地库。 - **识别方法**： 1. **直接内存**：查找较大的匿名内存块（`[anon]`），结合 NMT 数据确认（见下文）。 2. **元空间**：通常为分散的中等大小匿名内存块。 3. **线程栈**：多个固定大小（如 1024KB）的 `rw---` 匿名内存段。 4. **本地库**：映射到 `.so` 文件的段（如 `libjvm.so`），RSS 可能较高但通常为共享内存。 #### 5. **结合 NMT 验证堆外内存** - **启用 NMT**： 启动 JVM 时添加参数 `-XX:NativeMemoryTracking=detail`。 - **获取 NMT 报告**： ```bash jcmd <PID> VM.native_memory detail ``` - **关键字段解释**： - `Total`：总占用量。 - `Reserved`：保留的虚拟内存。 - `Committed`：实际提交的物理内存。 - 分类：`Internal`（GC 内部结构）、`Thread`（线程栈）、`Arena`（内存分配区）、`Other`（直接内存等）。 #### 6. **交叉分析示例** - **NMT 输出片段**： ``` Native Memory Tracking: Total: reserved=5GB, committed=2GB - Java Heap
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值