运行demoServer后，多次请求接口，java程序内存占用会一直升高，且没有下降的趋势，想请教一下大佬是否存在内存泄露？ about sekiro-open HOT 13 CLOSED

from sekiro-open.

hi，请在内存占用高的情况，使用jmap命令dump内存布局文件：

jmap -dump:format=b,file=/path/to/savefile.bin pid

其中pid是Linux中demo server的进程号

之后你可以将这个.bin文件压缩一下。请通过百度云盘等方式传给我内存dump文件，便于我们分析是否存在内存泄漏

from sekiro-open.

dump文件链接

服务运行环境：

• macOS 13.0.1 (22A400)
• Apple M1 Pro

@iinti @mz135135 麻烦大佬看下

from sekiro-open.

hi,看起来整个堆空间只占用了4M内存，tcp连接数量只有不到20个。这个没发现有泄漏问题。

实际上java的程序正常内存占用应该都不小。就一般性情况来说，在出现内存泄漏的时候，内存dump文件都会是五六个G的大小，你这个dump文件才200M，距离内存泄漏还太早

另外，从dump结果来看，你的程序是老版本的，建议尽快升级到新版本

from sekiro-open.

前面发的dump是我只运行了半个小时的，如果挂上一周的话内存占用会到将近20个g，从活动监视器上面看，随着接口调用次数的增加，线程和端口的数量会一直增加，没有下降的情况，我重新dump了一下，这次是挂了一天的，内存占用已经5个G了，麻烦
@iinti 大佬在看下，另外附上dump文件

from sekiro-open.

这个程序我没有关，打算今天再挂一天，等他内存涨上去，到时候我再更新一个dump文件和内存占用截图

from sekiro-open.

hi,你这个计数应该是不准确的。我看实际上堆内存依然只有6M，看起来应该是你的macos的主机本身内存资源充足，其内存资源在操作系统不会及时GC。但是程序内部占用内存只有700M。你的dump文件整个只有700M的大小，一般来说不会是内存泄漏的表现。内存泄漏正常dump文件都是几个G的大小

from sekiro-open.

from sekiro-open.

dump文件

@iinti 挂了一周，内存已经到17G了，根据以往的经历来看，已经快到被系统主动清理的边缘了，我也想相信没有内存泄露，但是从统计来看这个内存一直涨总是有点问题的，我这台机器的配置并不高，按理说如果会GC的话应该不会一直上涨，麻烦大佬再看一下

from sekiro-open.

hi，文件过期了。

from sekiro-open.

@iinti dump文件

from sekiro-open.

文件太小了，才700M。堆空间肯定是没有泄漏的。我之前处理过很多次netty网络程序的泄漏问题，只要出现异常问题，dump文件基本立马看出问题点。

sekiro依赖netty，会使用堆外内存，即由c++分配内存空间，不被java GC之间管理，但是你的dump文件中显示堆外内存只有465个，本身考虑内存复用这些堆外内存就不会被清理。量级也远远达不到内存泄漏的地步

你这个17G是虚拟空间，应该是mac-os的机制，所有访问过的虚拟空间地址可能都会被缓存，但是实际上在malloc层面已经被free了。

java本身是有内存保护机制的，默认情况下jvm控制的可分配内存范围是 物理机器内存的1/64 到 1/4 之间，超过配额jvm本身就会直接crash。不可能达到需要操作系统干预回收的地步。

另外，sekiro已经在公司的环境中运行了好些年，除非命中特殊条件的bug，理论上不至于出现这种明显的问题。

** 请使用新版本的代码，为避免问题沟通基础讨论问题，原则上老版本代码不做问题回复。**
** 如果你依然对本文保有疑问，建议选择一台Linux的主机运行sekiro，应该不会有这个表现 **

from sekiro-open.

好的，感谢大佬的分析，我先更换成新版本试试，后续有问题在向你请教

from sekiro-open.