java内存泄露(normal).doc

一 问题的提出Java的一个重要优点就是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员认为Java不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC或JVM的问题。其实，这种想法是不正确的，因为Java也存在内存泄露，但它的表现与C+不同。随着越来越多的服务器程序采用Java技术，例如JSP，Servlet， EJB等，服务器程序往往长期运行。另外，在很多嵌入式系统中，内存的总量非常有限。内存泄露问题也就变得十分关键，即使每次运行少量泄漏，长期运行之后，系统也是面临崩溃的危险。二 Java是如何管理内存为了判断Java中是否有内存泄露，我们首先必须了解Java是如何管理内存的。Java的内存管理就是对象的分配和释放问题。分配内存的方式多种多样，取决于该种语言的语法结构。但不论是哪一种语言的内存分配方式，最后都要返回所分配的内存块的起始地址，即返回一个指针到内存块的首地址。在Java中，程序员需要通过关键字new为每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。另外，对象的释放是由GC决定和执行的。在Java中，内存的分配是由程序完成的，而内存的释放是有GC完成的，这种收支两条线的方法确实简化了程序员的工作。但同时，它也加重了JVM的工作。这也是Java程序运行速度较慢的原因之一。因为，GC为了能够正确释放对象，GC必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控。监视对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。为了更好理解GC的工作原理，我们可以将对象考虑为有向图的顶点，将引用关系考虑为图的有向边，有向边从引用者指向被引对象。另外，每个线程对象可以作为一个图的起始顶点，例如大多程序从main进程开始执行，那么该图就是以main进程顶点开始的一棵根树。在这个有向图中，根顶点可达的对象都是有效对象，GC将不回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被GC回收。以下，我们举一个例子说明如何用有向图表示内存管理。对于程序的每一个时刻，我们都有一个有向图表示JVM的内存分配情况。以下右图，就是左边程序运行到第6行的示意图。 Java使用有向图的方式进行内存管理，可以消除引用循环的问题，例如有三个对象，相互引用，只要它们和根进程不可达的，那么GC也是可以回收它们的。这种方式的优点是管理内存的精度很高，但是效率较低。另外一种常用的内存管理技术是使用计数器，例如COM模型采用计数器方式管理构件，它与有向图相比，精度行低(很难处理循环引用的问题)，但执行效率很高。在 Java 中，所有对象都驻留在堆内存，因此局部对象就不存在。当你创建一个对象时，Java 虚拟机（JVM）为该对象分配内存、调用构造器并开始跟踪你使用的对象。当你停止使用一个对象（就是说，当没有对该对象有效的引用时），JVM 通过垃圾回收器将该对象标记为释放状态。当垃圾回收器要释放一个对象的内存时，它首先调用该对象的finalize() 方法（如果该对象定义了此方法的话）。垃圾回收器以独立的低优先级的方式运行，所以只有当其他线程都挂起等待内存释放的情况出现时，它才开始释放对象的内存。三java垃圾收集器垃圾收集器线程是一种低优先级的线程，在一个Java程序的生命周期中，它只有在内存空闲的时候才有机会运行。垃圾收集器的特点和它的执行机制： 垃圾收集器系统有自己的一套方案来判断哪个内存块是应该被回收的，哪个是不符合要求暂不回收的。垃圾收集器在一个Java程序中的执行是自动的，不能强制执行，即使程序员能明确地判断出有一块内存已经无用了，是应该回收的，程序员也不能强制垃圾收集器回收该内存块。程序员唯一能做的就是通过调用System. gc 方法来建议执行垃圾收集器，但其是否可以执行，什么时候执行却都是不可知的。这也是垃圾收集器的最主要的缺点。当然相对于它给程序员带来的巨大方便性而言，这个缺点是瑕不掩瑜的。垃圾收集器的工作是发现应用程序不再需要的对象，并在这些对象不再被访问或引用时将它们删除。从根节点（在java应用程序的整个生存周期内始终存在的那些类）开始，遍历被应用的所有节点进行清除。在它遍历这些节点的同时，它跟踪哪些对象当前正被引用着。任何类只要不再被引用，它就符合垃圾收集的条件。当删除这些对象后，就将它们所占用的内存资源返回给jvm。（1）、垃圾收集器的主要特点： 1垃圾收集器的工作目标是回收已经无用的对象的内存空间，从而避免内存渗漏体的产生，节省内存资源，避免程序代码的崩溃。 2垃圾收集器判断一个对象的内存空间是否无用的标准是：如果该对象不能再被程序中任何一个活动的部分所引用，此时我们就说，该对象的内存空间已经无用。所谓活动的部分，是指程序中某部分参与程序的调用，正在执行过程中，尚未执行完毕。 3垃圾收集器线程虽然是作为低优先级的线程运行，但在系统可用内存量过低的时候，它可能会突发地执行来挽救内存资源。当然其执行与否也是不可预知的。 4垃圾收集器不可以被强制执行，但程序员可以通过调用System. gc方法来建议执行垃圾收集器。 5不能保证一个无用的对象一定会被垃圾收集器收集，也不能保证垃圾收集器在一段Java语言代码中一定会执行。因此在程序执行过程中被分配出去的内存空间可能会一直保留到该程序执行完毕，除非该空间被重新分配或被其他方法回收。由此可见，完全彻底地根绝内存渗漏体的产生也是不可能的。但是请不要忘记，Java的垃圾收集器毕竟使程序员从手工回收内存空间的繁重工作中解脱了出来。设想一个程序员要用C或C+来编写一段10万行语句的代码，那么他一定会充分体会到Java的垃圾收集器的优点！ 6同样没有办法预知在一组均符合垃圾收集器收集标准的对象中，哪一个会被首先收集。 7循环引用对象不会影响其被垃圾收集器收集。 8可以通过将对象的引用变量（reference variables，即句柄handles）初始化为null值，来暗示垃圾收集器来收集该对象。但此时，如果该对象连接有事件监听器（典型的 AWT组件），那它还是不可以被收集。所以在设一个引用变量为null值之前，应注意该引用变量指向的对象是否被监听，若有，要首先除去监听器，然后才可以赋空值。 9每一个对象都有一个finalize( )方法，这个方法是从Object类继承来的。 10finalize( )方法用来回收内存以外的系统资源，就像是文件处理器和网络连接器。该方法的调用顺序和用来调用该方法的对象的创建顺序是无关的。换句话说，书写程序时该方法的顺序和方法的实际调用顺序是不相干的。请注意这只是finalize( )方法的特点。 11每个对象只能调用finalize( )方法一次。如果在finalize( )方法执行时产生异常（exception），则该对象仍可以被垃圾收集器收集。 12垃圾收集器跟踪每一个对象，收集那些不可到达的对象（即该对象没有被程序的任何活的部分所调用），回收其占有的内存空间。但在进行垃圾收集的时候，垃圾收集器会调用finalize( )方法，通过让其他对象知道它的存在，而使不可到达的对象再次复苏为可到达的对象。既然每个对象只能调用一次finalize( )方法，所以每个对象也只可能复苏一次。 13finalize( )方法可以明确地被调用，但它却不能进行垃圾收集。 14finalize( )方法可以被重载（overload），但只有具备初始的finalize( )方法特点的方法才可以被垃圾收集器调用。 15子类的finalize( )方法可以明确地调用父类的finalize( )方法，作为该子类对象的最后一次适当的操作。但Java编译器却不认为这是一次覆盖操作（overriding），所以也不会对其调用进行检查。 16当finalize( )方法尚未被调用时，System. runFinalization( )方法可以用来调用finalize( )方法，并实现相同的效果，对无用对象进行垃圾收集。 此时容易引起一个误解大家可能想finalize() 方法是安全的，这时一些重要的事情需要注意：首先，只有当垃圾回收器释放该对象的内存时，才会执行finalize()。如果在 Applet 或应用程序退出之前垃圾回收器没有释放内存，垃圾回收器将不会调用finalize()。其次，除非垃圾回收器认为Applet或应用程序需要额外的内存，否则它不会试图释放不再使用的对象的内存。换句话说，有可能出现这样的情况：一个 Applet 给少量的对象分配了内存，但没有造成严重的内存需求，于是垃圾回收器没有释放这些对象的内存程序就退出了。显然，如果为某个对象定义了finalize() 方法，JVM可能不会调用它，因为垃圾回收器不曾释放过那些对象的内存。即使调用System.gc() 也可能不会起作用，因为它仅仅是给 JVM 的一个建议而不是命令，所以finalize()方法的作用也就不是那么明显。Java 1.1中有一个System.runFinalizersOnExit()方法部分地解决了这个问题。（不要将这个方法与 Java1.0中的System.runFinalizations()方法相混淆。）不象System.gc() 方法那样，System.runFinalizersOnExit()方法并不立即试图启动垃圾回收器。而是当应用程序或 Applet 退出时，它调用每个对象的finalize()方法。结论：不应当依靠垃圾回收器或finalize() 来执行你的 Applet 和应用程序的资源清除工作。取而代之，应当使用确定的方法来清除那些资源或创建一个try.finally 块（或类似的机制）来实现。17当一个方法执行完毕，其中的局部变量就会超出使用范围，此时可以被当作垃圾收集，但以后每当该方法再次被调用时，其中的局部变量便会被重新创建。 18Java语言使用了一种标记交换区的垃圾收集算法。该算法会遍历程序中每一个对象的句柄，为被引用的对象做标记，然后回收尚未做标记的对象。所谓遍历可以简单地理解为检查每一个。 19Java语言允许程序员为任何方法添加finalize( )方法，该方法会在垃圾收集器交换回收对象之前被调用。但不要过分依赖该方法对系统资源进行回收和再利用，因为该方法调用后的执行结果是不可预知的。 通过以上对垃圾收集器特点的了解，你应该可以明确垃圾收集器的作用，和垃圾收集器判断一块内存空间是否无用的标准。简单地说，当你为一个对象赋值为null并且重新定向了该对象的引用者，此时该对象就符合垃圾收集器的收集标准。典型地，GC不会自动执行，直到程序需要的内存比当前可用内存多时才调用，此时，jvm将首先尝试激活GC以得到更多的可用内存，如果仍得不到充足的可用内存，jvm将转向从操作系统申请更多的内存，直到最终超过分配的最大内存而导致java.lang.OutOfMemoryError四 什么是Java中的内存泄露（1）、java内存泄漏在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。在C+中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C+中没有GC，这些内存将永远收不回来。在Java中，这些不可达的对象都由GC负责回收，因此程序员不需要考虑这部分的内存泄露。通过分析，我们得知，对于C+，程序员需要自己管理边和顶点，而对于Java程序员只需要管理边就可以了(不需要管理顶点的释放)。通过这种方式，Java提高了编程的效率。因此，通过以上分析，我们知道在Java中也有内存泄漏，但范围比C+要小一些。因为Java从语言上保证，任何对象都是可达的，所有的不可达对象都由GC管理。对于程序员来说，GC基本是透明的，不可见的。虽然，我们只有几个函数可以访问GC，例如运行GC的函数System.gc()，但是根据Java语言规范定义， 该函数不保证JVM的垃圾收集器一定会执行。因为，不同的JVM实现者可能使用不同的算法管理GC。通常，GC的线程的优先级别较低。JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。除非在一些特定的场合，GC的执行影响应用程序的性能，例如对于基于Web的实时系统，如网络游戏等，用户不希望GC突然中断应用程序执行而进行垃圾回收，那么我们需要调整GC的参数，让GC能够通过平缓的方式释放内存，例如将垃圾回收分解为一系列的小步骤执行，Sun提供的HotSpot JVM就支持这一特性。下面给出了一个简单的内存泄露的例子。在这个例子中，我们循环申请Object对象，并将所申请的对象放入一个Vector中，如果我们仅仅释放引用本身，那么Vector仍然引用该对象，所以这个对象对GC来说是不可回收的。因此，如果对象加入到Vector后，还必须从Vector中删除，最简单的方法就是将Vector对象设置为null。Vector v=new Vector(10);for (int I=1;IA4的应用A2-A4的引用AA6A1A3A7A4A8A2A5A9cb类对象指向图（4）、经验总结、预防措施和规范建议1、 容器的removeall()方法当类从Jpanel或Jdialog或其它容器类继承的时候，删除该对象之前不妨调用它的removeall()方法2、 线程的interrupe()方法当类对象是一个Thread的时候，删除该对象之前不妨调用它的interrupe()方法3、 JfileChooser的removeChoosableFileFilter()如果创建了一个JfileChooser，并且加入了自己的文件过滤器，删除该对象之前不妨调用它的removeChoosableFileFilter()方法4、 调用Timer和TimerTask的Cancel()方法5、 当不需要一个类时，最好删除它的监听器6、 内存检测过程中不仅要关注自己编写的类对象，同时也要关注一些基本类型的对象，例如：int,String,char等等。7、在确认一个对象无用后，将其所有引用显式的置为null六 如何检测内存泄漏最后一个重要的问题，就是如何检测Java的内存泄漏。目前，我们通常使用一些工具来检查Java程序的内存泄漏问题。市场上已有几种专业检查Java内存泄漏的工具，它们的基本工作原理大同小异，都是通过监测Java程序运行时，所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员将根据这些信息判断程序是否有内存泄漏问题。这些工具包括Optimizeit Profiler，JProbe Profiler，JinSight , Rational 公司的Purify等。下面，我们将简单介绍Optimizeit的基本功能和工作原理。Optimizeit Profiler版本4.11支持Application，Applet，Servlet和Romote Application四类应用，并且可以支持大多数类型的JVM，包括SUN JDK系列，IBM的JDK系列，和Jbuilder的JVM等。并且，该软件是由Java编写，因此它支持多种操作系统。Optimizeit系列还包括Thread Debugger和Code Coverage两个工具，分别用于监测运行时的线程状态和代码覆盖面