深陷好几天了。。堆内存占用不高， Java 进程内存占用非常高，不明白是什么情况...

[bubuXiaoqi]

找不到谁可以问问。。。 深陷几天了。。

1、top 查看显示占用 3.G 了 但是我用 jmap -head 拿下来的文件也就 1.2G 2、jstack -gc 查看的各代内存都很正常都是用了几百 M 完全没有满 加起来也就 1G 的样子 3、 不知道该怎么定位了，CPU 非常正常。。把机器内存快跑满的时候 CPU 和负载都很正常

[bubuXiaoqi]

而且我用 JProfiler 分析也看的内容大小只有 8 900M 看类分析也没有内存泄漏的情况，如果有的话堆内存应该比较高的吧

[b1gCi]

堆外内存看看，分析下类，是否有流没有正常关闭之类的，或者打开文件太多了来不及回收，上次被这个问题坑了

[bubuXiaoqi]

@b1gCi 堆外内存通过啥工具看哇。

[rigortek]

这种情况下似乎只能采用排除法，
一步一步不加载或不调用某些可疑模块，
慢慢缩少范围，直到找到“罪魁祸首”。

[bubuXiaoqi]

@rigortek 线上业务太多了。。。 而且好奇怪的是阿里云负载的相同比例的 6 个节点 有的节点啥事没有 有的节点就是慢慢、越来越大 但是拉 dump 下来就没有多少占用。。

[bubuXiaoqi]

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
37888.0 38912.0 21180.4 0.0 588288.0 224570.3 1320960.0 703979.1 216320.0 133734.7 27648.0 16647.6 72616 902.412 598 377.328 1279.741

[palmers]

你多 jmap 几次看看呢？

[jerrychaox]

看下 /dev/shm ?

[sagaxu]

gc 释放的内存，不一定会返还给 os

[pmispig]

要么你 top 读数错误，要么堆外内存

[Aresxue]

使用 Native Memory Tracker，加上-XX:NativeMemoryTracking=detail，
蒙一下 和 netty 或者文件流没有正确释放有关。

[lewis89]

@Aresxue #11 90% 跟 netty 有关，netty 堆外出事情 又不是一次两次了，关键是很多阿里系的中间件都喜欢把它引进去，在性能跟可靠性方面，我觉得绝大部分场景都不应该选这种黑魔法式的堆外内存管理方式，排查难度太大，而且它自己又搞了一套引用计数的内存管理方式，出问题了 你只能等官方去定位，除非你自己能定位到 netty 泄漏的地方。

[bubuXiaoqi]

@palmers 这几天 jmap 很多次了堆内内存没什么变化

[bubuXiaoqi]

@jerrychaox 是空文件夹

[zhanggg]

@bubuXiaoqi jvisualvm 装个插件能看

[2379920898]

先装个监控查看一下，清空下文件

[limbo0]

确定堆外内存的话，可以看看 direct 内存，网络连接多的话占用很多

[bubuXiaoqi]

@zhanggg 好我试试 好像加了一层 docker 还不明白怎么连接上。

[zhanggg]

@bubuXiaoqi docker 把相关端口挂出来，启动脚本里加上相关配置

[jerrychaox]

因为通常的垃圾收集日志等记录，并不包含 Direct Buffer 等信息，所以 Direct Buffer 内存诊断也是个比较头疼的事情。在 JDK 8 之后的版本，使用 Native Memory Tracking （ NMT ）特性来进行诊断，你可以在程序启动时加上下面参数：

-XX:NativeMemoryTracking={summary|detail}


// 打印 NMT 信息
jcmd <pid> VM.native_memory detail

// 进行 baseline，以对比分配内存变化
jcmd <pid> VM.native_memory baseline

// 进行 baseline，以对比分配内存变化
jcmd <pid> VM.native_memory detail.diff