Java加载dll，导致Java进程内存泄露

By zhaoch
在做网络监控系统的性能测试时，出现了内存泄露的问题，困扰了很久，现在终于算是解决了，但是根本原因尚不明确，拿出来大家讨论下，看看能不能完美解决～

这个问题奇怪的地方在于是Java进程内存泄露，而不是平常的JVM内存泄露，用Jprofile等工具也无法看出问题所在。

测试代码如下：

        System.loadLibrary("test1");

        int threadPoolSize = 400;
        ExecutorService service = Executors.newFixedThreadPool(threadPoolSize);

        for (int i = 0; i < 400; i++) {
            service.submit(new Runnable() {
                public void run() {
                    while (true) {
                        try {
                            Thread t = new Thread();
                            t.start();
                            Thread.sleep(100);
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                    }
                }
            });
        }

说明：此段代码所做的工作就是加载一个dll，然后不断的启动线程（线程什么也不做，直接终止）。
注：线程池只是为了加速问题复现，无其他用处。

现象：
1.如果不加载dll，只不断的启动线程，Java进程内存正常，不会一直增长。
2.如果加载附件中test1的dll，Java进程内存会一直增长。
3.如果加载附件中test2的dll（需要安装C++运行环境vcredist_x86），Java进程内存正常，不会一直增长。

dll说明：
dll的工程源码在附件中，test1和test2的区别只在于编译选项，如附件：test1选择的是“使用标准Windows库”或“在静态库中使用MFC”，test2选择的是“在共享DLL中使用MFC”
此dll工程的特点在于使用了jni，并引入了mfc头文件【#include <afxwin.h>】，如果不引入mfc头文件则不会引起内存泄漏


目前此问题的根本原因尚不明确，怀疑是jdk的bug（使用最新的jdk1.6.0.23也没用），不知道大家有什么想法吗？欢迎大家讨论～

评论

34 楼 flyiclj 2011-06-30  

wangyazhen 写道

建议先对dll中的方法进行压力测试 推荐.Net memory profiler工具
然后在使用Jprofiler对你的java应用程序进行跟踪
不管是java还是微软的代码 要想高效、及时的回收内存，需要在对象释放的时候显示地切掉与外部的引用，不然可能垃圾要回收好几次才能回收掉

dll的压力测试没有做过，不过这个核心程序ping.cpp是网上的开源代码，已经好多年，看历史可以看出从98年开始，这么长的时间如果有问题，应该早就发现了吧
Jprofiler也只能跟踪JVM的内存使用吧，这个程序是进程内存泄露，JVM内存的使用是正常的，在JProfiler看不出什么问题

个人感觉还是因为JNI加载dll，才导致了Java进程内存泄露

33 楼 wangyazhen 2011-06-29  

建议先对dll中的方法进行压力测试 推荐.Net memory profiler工具
然后在使用Jprofiler对你的java应用程序进行跟踪
不管是java还是微软的代码 要想高效、及时的回收内存，需要在对象释放的时候显示地切掉与外部的引用，不然可能垃圾要回收好几次才能回收掉

32 楼 flyiclj 2011-06-29  

kingkan 写道

嗯。。。确实如你所说，回归你之前说的线程导致增量问题,的确耐人寻味了，这位同学，有待研究。

我先去请教下大牛，嘿。

可以参考一下之前的回复，这样修改确实可以解决问题，也许原因说的并不完全对，但应该也十分值得参考

cyj86 写道

此问题得到解决
公司技术专家回复如下:

引用

将CWinApp theApp; 放在ping.cpp文件中的最后一行即可。

1. 这不是Java的BUG
2. 这也不是MFC的BUG
3. 这也不能说是程序员造成的BUG
4. 应该是MFC框架结构的特点造成的用法问题（但MSDN上没有说明）。

CWinApp必须定义为全局变量，由C++启动代码运行。
在构造的时候，会初始化MFC中使用的全局数据。
在MFC代码appcore.cpp中可以看到在CWinApp的构造与析构函数中，
对程序使用的一些MFC架构资源进行了分配与释放。

静态链接与动态链接的一个区别是内存的共享，猜测在静态链接时，
CWinApp初始化的内容为全局共享的，在没有进行这个初始化时，
各个线程使用的资源可能会独立申请（没有释放）。

经测试,如此修改后问题不再出现
王总实在V5~
orz

31 楼 kingkan 2011-06-29  

flyiclj 写道

kingkan 写道

flyiclj 写道

试了一下，只new Object内存不会涨，不知道你用的什么版本jdk？ 我用的是jdk1.5.0_22
只new对象进程内存动都不带动的，看不出变化

JDK1.6.0.22,持续创建对象情况下，每NEW GC一次，进程内存都会增长。

用JDK1.6.0_23试了一下，未出现内存泄露，进程内存最终会稳定在固定数值

为了加速复现，我去掉了 Thread.sleep(100);，并给JVM增加了参数 -verbose:gc -Xms2m -Xmx4m

加载dll，进程内存最终稳定在22936K
不加载dll，进程内存最终稳定在22012K

不知道你是不是只看了前几次GC就确定有内存泄露了？这个要等稳定了再看吧？

嗯。。。确实如你所说，回归你之前说的线程导致增量问题,的确耐人寻味了，这位同学，有待研究。

我先去请教下大牛，嘿。

30 楼 flyiclj 2011-06-29  

kingkan 写道

flyiclj 写道

试了一下，只new Object内存不会涨，不知道你用的什么版本jdk？ 我用的是jdk1.5.0_22
只new对象进程内存动都不带动的，看不出变化

JDK1.6.0.22,持续创建对象情况下，每NEW GC一次，进程内存都会增长。

用JDK1.6.0_23试了一下，未出现内存泄露，进程内存最终会稳定在固定数值

为了加速复现，我去掉了 Thread.sleep(100);，并给JVM增加了参数 -verbose:gc -Xms2m -Xmx4m

加载dll，进程内存最终稳定在22936K
不加载dll，进程内存最终稳定在22012K

不知道你是不是只看了前几次GC就确定有内存泄露了？这个要等稳定了再看吧？

29 楼 kingkan 2011-06-29  

flyiclj 写道

试了一下，只new Object内存不会涨，不知道你用的什么版本jdk？ 我用的是jdk1.5.0_22
只new对象进程内存动都不带动的，看不出变化

JDK1.6.0.22,持续创建对象情况下，每NEW GC一次，进程内存都会增长。

28 楼 flyiclj 2011-06-28  

ppgunjack 写道

所以全局变量我觉得解释不通
多线程不会导致共享库的全局变量的拷贝，因为这些线程处于同一虚拟地址空间，都能以相同地址访问动态共享库中的全局变量
如果是多进程访问动态共享库才会出现，每个进程访问共享库会出现拷贝共享库中定义的全局变量的情况

不过修改了之后确实好了,也许还有别的原因吧

27 楼 ppgunjack 2011-06-28  

所以全局变量我觉得解释不通
多线程不会导致共享库的全局变量的拷贝，因为这些线程处于同一虚拟地址空间，都能以相同地址访问动态共享库中的全局变量
如果是多进程访问动态共享库才会出现，每个进程访问共享库会出现拷贝共享库中定义的全局变量的情况

26 楼 flyiclj 2011-06-28  

ppgunjack 写道

cyj86 写道

此问题得到解决
公司技术专家回复如下:

引用

将CWinApp theApp; 放在ping.cpp文件中的最后一行即可。

1. 这不是Java的BUG
2. 这也不是MFC的BUG
3. 这也不能说是程序员造成的BUG
4. 应该是MFC框架结构的特点造成的用法问题（但MSDN上没有说明）。

CWinApp必须定义为全局变量，由C++启动代码运行。
在构造的时候，会初始化MFC中使用的全局数据。
在MFC代码appcore.cpp中可以看到在CWinApp的构造与析构函数中，
对程序使用的一些MFC架构资源进行了分配与释放。

静态链接与动态链接的一个区别是内存的共享，猜测在静态链接时，
CWinApp初始化的内容为全局共享的，在没有进行这个初始化时，
各个线程使用的资源可能会独立申请（没有释放）。

经测试,如此修改后问题不再出现
王总实在V5~
orz

线程看到的链接库资源应该是一份都是同一个地址空间，全局变量出现拷贝的情况是多进程共享

这里没有用到多进程啊，只有多线程

25 楼 flyiclj 2011-06-28  

kingkan 写道

cyj86 写道

kingkan 写道

flyiclj 写道

所谓load的时候就开始泄露是指什么?为什么不新建线程内存就不会增长呢?难道泄露停止了?

可以确认是dll的问题,所以卸载了dll内存泄露自然就终止了

现在要讨论的是 新建线程 和 dll内存泄露 之间有什么联系,要如何修改才能避免这种情况发生?

这位同学，新建线程 和 dll内存泄露 没关系滴。

首先谢谢这位兄弟关注并讨论
确实,按理说新建线程和dll泄漏应该没关系

但现象是只有不断的新建线程 这个dll内存泄漏现象才会体现出来
源码中的连接池正是因为此才可以加速复现问题

不知道你有何方法复现dll泄漏现象 而不新建线程么？

把

Thread t = new Thread();
t.start();

换成

Object o = new Object();

内存照样泄露，只要加载了这个DLL，你new对象的时候，进程内存都在增长。
我估计是这个DLL做了某些行为导致这样的，至于做了什么行为，在下的C++功力不够看不出来，呵呵

试了一下，只new Object内存不会涨，不知道你用的什么版本jdk？ 我用的是jdk1.5.0_22
只new对象进程内存动都不带动的，看不出变化

24 楼 ppgunjack 2011-06-27  

cyj86 写道

此问题得到解决
公司技术专家回复如下:

引用

将CWinApp theApp; 放在ping.cpp文件中的最后一行即可。

1. 这不是Java的BUG
2. 这也不是MFC的BUG
3. 这也不能说是程序员造成的BUG
4. 应该是MFC框架结构的特点造成的用法问题（但MSDN上没有说明）。

CWinApp必须定义为全局变量，由C++启动代码运行。
在构造的时候，会初始化MFC中使用的全局数据。
在MFC代码appcore.cpp中可以看到在CWinApp的构造与析构函数中，
对程序使用的一些MFC架构资源进行了分配与释放。

静态链接与动态链接的一个区别是内存的共享，猜测在静态链接时，
CWinApp初始化的内容为全局共享的，在没有进行这个初始化时，
各个线程使用的资源可能会独立申请（没有释放）。

经测试,如此修改后问题不再出现
王总实在V5~
orz

线程看到的链接库资源应该是一份都是同一个地址空间，全局变量出现拷贝的情况是多进程共享

23 楼 kingkan 2011-06-27  

cyj86 写道

kingkan 写道

flyiclj 写道

所谓load的时候就开始泄露是指什么?为什么不新建线程内存就不会增长呢?难道泄露停止了?

可以确认是dll的问题,所以卸载了dll内存泄露自然就终止了

现在要讨论的是 新建线程 和 dll内存泄露 之间有什么联系,要如何修改才能避免这种情况发生?

这位同学，新建线程 和 dll内存泄露 没关系滴。

首先谢谢这位兄弟关注并讨论
确实,按理说新建线程和dll泄漏应该没关系

但现象是只有不断的新建线程 这个dll内存泄漏现象才会体现出来
源码中的连接池正是因为此才可以加速复现问题

不知道你有何方法复现dll泄漏现象 而不新建线程么？

把

Thread t = new Thread();
t.start();

换成

Object o = new Object();

内存照样泄露，只要加载了这个DLL，你new对象的时候，进程内存都在增长。
我估计是这个DLL做了某些行为导致这样的，至于做了什么行为，在下的C++功力不够看不出来，呵呵

22 楼 cyj86 2011-06-27  

此问题得到解决
公司技术专家回复如下:

引用

将CWinApp theApp; 放在ping.cpp文件中的最后一行即可。

1. 这不是Java的BUG
2. 这也不是MFC的BUG
3. 这也不能说是程序员造成的BUG
4. 应该是MFC框架结构的特点造成的用法问题（但MSDN上没有说明）。

CWinApp必须定义为全局变量，由C++启动代码运行。
在构造的时候，会初始化MFC中使用的全局数据。
在MFC代码appcore.cpp中可以看到在CWinApp的构造与析构函数中，
对程序使用的一些MFC架构资源进行了分配与释放。

静态链接与动态链接的一个区别是内存的共享，猜测在静态链接时，
CWinApp初始化的内容为全局共享的，在没有进行这个初始化时，
各个线程使用的资源可能会独立申请（没有释放）。

经测试,如此修改后问题不再出现
王总实在V5~
orz

21 楼 cyj86 2011-06-25  

kingkan 写道

flyiclj 写道

kingkan 写道

flyiclj 写道

即使DLL本身有泄露，那也只会在load的时候泄露一次，现在的现象是在java中每建一个线程，内容就会增长，而load只做了一次

呵呵，这位兄台，麻烦你先run一下楼主的这个程序吧。

第一，test1.dll这个DLL在load的时候就开始泄漏，这跟一次两次是没关系，内部泄漏的实现你可以看到，是不断的泄漏。

第二，楼主的java程序并没有造成JVM大内存的消耗，新建的线程很快就被回收，整个过程也只是保持在415个线程左右，堆内存除了新生区new GC比较频繁以外，JVM的内存并没有继续扩容。

第三，该java进程的内存不断的增长，在windows下你可以通过listdlls工具看到，该java进程加载的所有DLL，包括test1.dll也在里面，当你把test1.dll动态卸载时，系统会把进程中test1.dll的内存马上清除，并且java进程也停止增长了喔。

所谓load的时候就开始泄露是指什么?为什么不新建线程内存就不会增长呢?难道泄露停止了?

可以确认是dll的问题,所以卸载了dll内存泄露自然就终止了

现在要讨论的是 新建线程 和 dll内存泄露 之间有什么联系,要如何修改才能避免这种情况发生?

这位同学，新建线程 和 dll内存泄露 没关系滴。

首先谢谢这位兄弟关注并讨论
确实,按理说新建线程和dll泄漏应该没关系

但现象是只有不断的新建线程 这个dll内存泄漏现象才会体现出来
源码中的连接池正是因为此才可以加速复现问题

不知道你有何方法复现dll泄漏现象 而不新建线程么？

20 楼 kingkan 2011-06-24  

flyiclj 写道

kingkan 写道

flyiclj 写道

即使DLL本身有泄露，那也只会在load的时候泄露一次，现在的现象是在java中每建一个线程，内容就会增长，而load只做了一次

呵呵，这位兄台，麻烦你先run一下楼主的这个程序吧。

第一，test1.dll这个DLL在load的时候就开始泄漏，这跟一次两次是没关系，内部泄漏的实现你可以看到，是不断的泄漏。

第二，楼主的java程序并没有造成JVM大内存的消耗，新建的线程很快就被回收，整个过程也只是保持在415个线程左右，堆内存除了新生区new GC比较频繁以外，JVM的内存并没有继续扩容。

第三，该java进程的内存不断的增长，在windows下你可以通过listdlls工具看到，该java进程加载的所有DLL，包括test1.dll也在里面，当你把test1.dll动态卸载时，系统会把进程中test1.dll的内存马上清除，并且java进程也停止增长了喔。

所谓load的时候就开始泄露是指什么?为什么不新建线程内存就不会增长呢?难道泄露停止了?

可以确认是dll的问题,所以卸载了dll内存泄露自然就终止了

现在要讨论的是 新建线程 和 dll内存泄露 之间有什么联系,要如何修改才能避免这种情况发生?

这位同学，新建线程 和 dll内存泄露 没关系滴。

19 楼 flyiclj 2011-06-24  

kingkan 写道

flyiclj 写道

即使DLL本身有泄露，那也只会在load的时候泄露一次，现在的现象是在java中每建一个线程，内容就会增长，而load只做了一次

呵呵，这位兄台，麻烦你先run一下楼主的这个程序吧。

第一，test1.dll这个DLL在load的时候就开始泄漏，这跟一次两次是没关系，内部泄漏的实现你可以看到，是不断的泄漏。

第二，楼主的java程序并没有造成JVM大内存的消耗，新建的线程很快就被回收，整个过程也只是保持在415个线程左右，堆内存除了新生区new GC比较频繁以外，JVM的内存并没有继续扩容。

第三，该java进程的内存不断的增长，在windows下你可以通过listdlls工具看到，该java进程加载的所有DLL，包括test1.dll也在里面，当你把test1.dll动态卸载时，系统会把进程中test1.dll的内存马上清除，并且java进程也停止增长了喔。

所谓load的时候就开始泄露是指什么?为什么不新建线程内存就不会增长呢?难道泄露停止了?

可以确认是dll的问题,所以卸载了dll内存泄露自然就终止了

现在要讨论的是 新建线程 和 dll内存泄露 之间有什么联系,要如何修改才能避免这种情况发生?

18 楼 kingkan 2011-06-23  

flyiclj 写道

即使DLL本身有泄露，那也只会在load的时候泄露一次，现在的现象是在java中每建一个线程，内容就会增长，而load只做了一次

呵呵，这位兄台，麻烦你先run一下楼主的这个程序吧。

第一，test1.dll这个DLL在load的时候就开始泄漏，这跟一次两次是没关系，内部泄漏的实现你可以看到，是不断的泄漏。

第二，楼主的java程序并没有造成JVM大内存的消耗，新建的线程很快就被回收，整个过程也只是保持在415个线程左右，堆内存除了新生区new GC比较频繁以外，JVM的内存并没有继续扩容。

第三，该java进程的内存不断的增长，在windows下你可以通过listdlls工具看到，该java进程加载的所有DLL，包括test1.dll也在里面，当你把test1.dll动态卸载时，系统会把进程中test1.dll的内存马上清除，并且java进程也停止增长了喔。

17 楼 flyiclj 2011-06-23  

kingkan 写道

cyj86 写道

kingkan 写道

flyiclj 写道

kingkan 写道

JVM动态加载的DLL归属于系统进程级别的管理，而DLL的内存资源是自己管理但与进程挂钩。

所以当你的test1.dll的内部内存不断增长而又不释放的话，进程的内存资源会不断增加。但并不影响JVM管理范围内的内存。

这个DLL只加载了一次，而且不做任何调用，即使它的内部内存有泄露，应该也不会影响到JAVA端吧

嗯，不调用是不会影响JVM。但当该进程的使用内存增长到一定程度，JVM或者系统不够内存用的时候，JVM会当掉的。

这是肯定的 系统内存如果都不够了 JVM当然也会出问题
但是和本话题就关系不大了

这里的重点是
dll只加载了一次
而且不做任何调用

DLL本身就有泄漏，System.load进来时，进程内存就开始泄漏了。这个test1.dll就是这种情况啦，除非有些dll非得到执行其内部某些方法才会泄漏，那就不同。关键是DLL内存泄漏点是加载就触发还是调用内部API时触发。

即使DLL本身有泄露，那也只会在load的时候泄露一次，现在的现象是在java中每建一个线程，内容就会增长，而load只做了一次

16 楼 kingkan 2011-06-23  

cyj86 写道

kingkan 写道

flyiclj 写道

kingkan 写道

JVM动态加载的DLL归属于系统进程级别的管理，而DLL的内存资源是自己管理但与进程挂钩。

所以当你的test1.dll的内部内存不断增长而又不释放的话，进程的内存资源会不断增加。但并不影响JVM管理范围内的内存。

这个DLL只加载了一次，而且不做任何调用，即使它的内部内存有泄露，应该也不会影响到JAVA端吧

嗯，不调用是不会影响JVM。但当该进程的使用内存增长到一定程度，JVM或者系统不够内存用的时候，JVM会当掉的。

这是肯定的 系统内存如果都不够了 JVM当然也会出问题
但是和本话题就关系不大了

这里的重点是
dll只加载了一次
而且不做任何调用

DLL本身就有泄漏，System.load进来时，进程内存就开始泄漏了。这个test1.dll就是这种情况啦，除非有些dll非得到执行其内部某些方法才会泄漏，那就不同。关键是DLL内存泄漏点是加载就触发还是调用内部API时触发。

15 楼 cyj86 2011-06-23  

kingkan 写道

flyiclj 写道

kingkan 写道

JVM动态加载的DLL归属于系统进程级别的管理，而DLL的内存资源是自己管理但与进程挂钩。

所以当你的test1.dll的内部内存不断增长而又不释放的话，进程的内存资源会不断增加。但并不影响JVM管理范围内的内存。

这个DLL只加载了一次，而且不做任何调用，即使它的内部内存有泄露，应该也不会影响到JAVA端吧

嗯，不调用是不会影响JVM。但当该进程的使用内存增长到一定程度，JVM或者系统不够内存用的时候，JVM会当掉的。

这是肯定的 系统内存如果都不够了 JVM当然也会出问题
但是和本话题就关系不大了

这里的重点是
dll只加载了一次
而且不做任何调用