|
精华帖 (0) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：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就确定有内存泄露了？这个要等稳定了再看吧？ |
| 返回顶楼 | |
|
发表时间：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就确定有内存泄露了？这个要等稳定了再看吧？ 嗯。。。确实如你所说，回归你之前说的线程导致增量问题,的确耐人寻味了，这位同学，有待研究。 我先去请教下大牛，嘿。 |
| 返回顶楼 | |
|
发表时间：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 |
| 返回顶楼 | |
|
发表时间：2011-06-29
建议先对dll中的方法进行压力测试 推荐.Net memory profiler工具
然后在使用Jprofiler对你的java应用程序进行跟踪 不管是java还是微软的代码 要想高效、及时的回收内存，需要在对象释放的时候显示地切掉与外部的引用，不然可能垃圾要回收好几次才能回收掉 |
| 返回顶楼 | |
|
发表时间：2011-06-30
wangyazhen 写道 建议先对dll中的方法进行压力测试 推荐.Net memory profiler工具
然后在使用Jprofiler对你的java应用程序进行跟踪 不管是java还是微软的代码 要想高效、及时的回收内存，需要在对象释放的时候显示地切掉与外部的引用，不然可能垃圾要回收好几次才能回收掉 dll的压力测试没有做过，不过这个核心程序ping.cpp是网上的开源代码，已经好多年，看历史可以看出从98年开始，这么长的时间如果有问题，应该早就发现了吧 Jprofiler也只能跟踪JVM的内存使用吧，这个程序是进程内存泄露，JVM内存的使用是正常的，在JProfiler看不出什么问题 个人感觉还是因为JNI加载dll，才导致了Java进程内存泄露 |
| 返回顶楼 | |
