内存泄漏：是指对象或者变量没有被引用，却一直占据在内存中，使得这一块内存不能够再被利用起来，造成内存的不可被用称为泄漏。
 
但是Java中有垃圾回收机制GC，GC能够将不再被使用的对象，自动从内存中清除。
 即使这样，Java中也存在着内存泄漏的情况：
 
一：当长生命周期的对象持有短生命周期的对象引用，就很可能发生内存泄漏。尽管短生命周期的对象已经不再需要，但是长生命周期的对象一直持有他的引用导致其无法被回收。例如，缓存系统；加载一个对象放在缓存系统中，一直不去使用这个对象，但是它一直被缓存引用，所以不会被回收导致缓存泄漏。
 
检查java中的内存泄漏，一定要将程序各个分支情况都完成执行至结束，然后看其是否被使用过，如果没有才能判定这个对象属于内存泄漏。
 
二：当一个对象被存储进HashSet集合中，就不可修改这个对象中用于计算哈希值的属性了。否则，对象修改后的哈希值与刚添加进HashSet集合时的哈希值不一样，此时如果将当前对象的引用作为参数，用contaions方法判断对象是否存在，则会返回找不到对象的结果。这会导致无法从HashSet单独删除当前对象，造成内存泄漏。

 
解决Java加载dll导致Java进程内存泄露在做网络监控系统的性能测试时，出现了内存泄露的问题，困扰了很久，现在终于算是解决了，但是根本原因尚不明确，拿出来大家讨论下，看看能不能完美解决～　　这个问题奇怪的地方在于是Java进程内存泄露，而不是平常的JVM内存泄露，用Jprofile等工具也无法看出问题所在。　　测试代码如下：System.loadLibrary("test1");int threadPoolSize =
 
解决Java加载dll导致Java进程内存泄露
 
在做网络监控系统的性能测试时，出现了内存泄露的问题，困扰了很久，现在终于算是解决了，但是根本原因尚不明确，拿出来大家讨论下，看看能不能完美解决～
 
这个问题奇怪的地方在于是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的
 
msimg32.dll
 
，Java进程内存会一直增长。
 
3.如果加载附件中test2的dll(需要安装C++运行环境vcredist_x86)，Java进程内存正常，不会一直增长。
 
DLL说明：
 
dll的工程源码在附件中，test1和test2的区别只在于编译选项，如附件：test1选择的是“使用标准Windows库”或“在静态库中使用MFC”，test2选择的是“在共享DLL中使用MFC”
 
此dll工程的特点在于使用了jni，并引入了mfc头文件【#include 】，如果不引入mfc头文件则不会引起内存泄漏
 
目前此问题的根本原因尚不明确，怀疑是jdk的bug(使用最新的jdk1.6.0.23也没用)，不知道大家有什么想法吗?欢迎大家讨论～
 
基于广大用户反馈，论坛附件下载策略全新上线，下载券全站通用，请放心下载 。
 
收藏0
 
打赏0
 
点赞0
 
分享至：
 
评论
 
文明留言，专业沟通
 

 
请先 登录，再评论！
 
全部评论
 
相关推荐

 
一、Java内存回收机制 不论哪种语言的内存分配方式，都需要返回所分配内存的真实地址，也就是返回一个指针到内存块的首地址。Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆(Heap)中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的。GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控，Java会使用有向图的方法进行管理内存，实时监控对象是否可以达到，如果不可到达，则就将其回收，这样也可以消除引用循环的问题。在Java语言中，判断一个内存空间是否符合垃圾收集标准有两个：一个是给对象赋予了空值null，以下再没有调用过，另一个是给对象赋予了新值，这样重新分配了内存空间。 二、Java内存泄露引起原因 首先，什么是内存泄露？经常听人谈起内存泄露，但要问什么是内存泄露，没几个说得清楚。内存泄露是指无用对象(不再使用的对象)持续占有内存或无用对象的内存得不到及时释放，从而造成的内存空间的浪费称为内存泄露。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你Out of memory。 那么，
 
Java内存泄露根本原因是什么呢？
 
长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。
 
具体主要有如下几大类：
 
1、静态集合类引起内存泄露： 像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。 例: Static Vector v = new Vector(10); for (int i = 1; i<100; i++) { Object o = new Object(); v.add(o); o = null; }// 在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身(o=null)，那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。
 
2、当集合里面的对象属性被修改后，再调用remove()方法时不起作用。 例： public static void main(String[] args) { Set set = new HashSet(); Person p1 = new Person("唐僧","pwd1",25); Person p2 = new Person("孙悟空","pwd2",26); Person p3 = new Person("猪八戒","pwd3",27); set.add(p1); set.add(p2); set.add(p3); System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:3 个元素! p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变 set.remove(p3); //此时remove不掉，造成内存泄漏 set.add(p3); //重新添加，居然添加成功 System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:4 个元素! for (Person person : set) { System.out.println(person); } }
 
3、监听器 在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。
 
4、各种连接 比如数据库连接(dataSourse.getConnection())，网络连接(socket)和io连接，除非其显式的调用了其close()方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象(关闭其中一个，另外一个也会关闭)，否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。
 
5、内部类和外部模块等的引用 内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如： public void registerMsg(Object b); 这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。
 
6、单例模式 不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在(以静态变量的方式)，如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露，考虑下面的例子： class A{ public A(){ B.getInstance().setA(this); } .... } //B类采用单例模式 class B{ private A a; private static B instance=new B(); public B(){} public static B getInstance(){ return instance; } public void setA(A a){ this.a=a; } //getter... } 显然B采用singleton模式，它持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较复杂的对象或者集合类型会发生

 
此问题在项目中被发现，经查看JDK源码(JDK1.6)，String类的public String substring(int beginIndex, int endIndex)的实现让我很意外。
 
想重现这个场景很容易，请看代码。
 
1
 
importjava.util.ArrayList;2importjava.util.List;34
 
publicclassLeakTest{5
 
publicstaticvoidmain(String
 
args){6        Listhandler=newArrayList();7
 
for(inti=0; i<100000; i++){8            Huge h=newHuge();9            handler.add(h.getSubString(1,5));10        }11    }12}1314
 
classHuge{15privateString str=newString(newchar[100000]);16
 
publicString getSubString(intbegin,intend){17returnstr.substring(begin, end);18    }19}
 
执行此代码结果：
 
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
 
问题就出在Huge类的 getSubString 方法，它调用了String类的substring方法。
 
来让我们看看 substring 类的实现吧，JDK源码如下：
 
1
 

 
publicString substring(intbeginIndex,intendIndex){2
 
if(beginIndex<0){3thrownewStringIndexOutOfBoundsException(beginIndex);4    }5
 
if(endIndex>count){6thrownewStringIndexOutOfBoundsException(endIndex);7    }8
 
if(beginIndex>endIndex){9thrownewStringIndexOutOfBoundsException(endIndex-beginIndex);10    }11return((beginIndex==0)&&(endIndex==count))?this:12newString(offset+beginIndex, endIndex-beginIndex, value);13    }
 
再让我们接下来看看 new String(offset + beginIndex, endIndex - beginIndex, value); 的实现：
 
1
 
//Package private constructor which shares value array for speed.2
 
String(intoffset,intcount,charvalue[]){3this.value=value;4this.offset=offset;5this.count=count;6    }
 
char[] value 数组被共享了。
 
在我们的main函数里的循环中，每循环一次后，我们希望Huge对象被回收，且释放它占有的内存。
 
但实际上 private String str = new String(new char[100000]); 占有的内存并不会被释放。
 
因为 我们通过 Huge 类的 getSubString 方法得到的 String 对象还存在(存在于handler的列表中)，
 
它虽然是 length 只有 4 的对象，却享有着 char[100000] 的空间。
 
解决方案：
 
可以修改Huge 类的 getSubString 方法如下：
 
1
 

 
publicString getSubString(intbegin,intend){2returnnewString(str.substring(begin, end));3    }
 
只要再套一个String的构造方法即可。
 
至于为什么，看看JDK源码，一看便知了。这里就不贴出来了。
 
唉，以后写代码得多多小心啊。
 
----2010年08月27日
 
本文为原创，欢迎转载，转载请注明出处BlogJava。