欧阳辰,
周欣,

2002 年 10 月 21 日

Java的一个重要优点就是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员认为Java不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC或JVM的问题。其实，这种想法是不正确的，因为Java也存在内存泄露，但它的表现与C++不同。

问题的提出

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中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为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;i<100; i++)

            {

            Object o=new Object();

            v.add(o);

            o=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两个工具，分别用于监测运行时的线程状态和代码覆盖面。

当设置好所有的参数了，我们就可以在OptimizeIt环境下运行被测程序，在程序运行过程中，Optimizeit可以监视内存的使用曲线(如下图)，包括JVM申请的堆(heap)的大小，和实际使用的内存大小。另外，在运行过程中，我们可以随时暂停程序的运行，甚至强行调用GC，让GC进行内存回收。通过内存使用曲线，我们可以整体了解程序使用内存的情况。这种监测对于长期运行的应用程序非常有必要，也很容易发现内存泄露。

在运行过程中，我们还可以从不同视角观查内存的使用情况，Optimizeit提供了四种方式：

• 堆视角。 这是一个全面的视角，我们可以了解堆中的所有的对象信息(数量和种类)，并进行统计、排序，过滤。了解相关对象的变化情况。
• 方法视角。通过方法视角，我们可以得知每一种类的对象，都分配在哪些方法中，以及它们的数量。
• 对象视角。给定一个对象，通过对象视角，我们可以显示它的所有出引用和入引用对象，我们可以了解这个对象的所有引用关系。
• 引用图。 给定一个根，通过引用图，我们可以显示从该顶点出发的所有出引用。

在运行过程中，我们可以随时观察内存的使用情况，通过这种方式，我们可以很快找到那些长期不被释放，并且不再使用的对象。我们通过检查这些对象的生存周期，确认其是否为内存泄露。在实践当中，寻找内存泄露是一件非常麻烦的事情，它需要程序员对整个程序的代码比较清楚，并且需要丰富的调试经验，但是这个过程对于很多关键的Java程序都是十分重要的。

综上所述，Java也存在内存泄露问题，其原因主要是一些对象虽然不再被使用，但它们仍然被引用。为了解决这些问题，我们可以通过软件工具来检查内存泄露，检查的主要原理就是暴露出所有堆中的对象，让程序员寻找那些无用但仍被引用的对象。

Java 语言要求 java 程序中（无论是谁写的代码），所有抛出（ throw ）的异常都必须是从 Throwable 派生而来。 当然，实际的 Java 编程中，由于 JDK 平台已经为我们设计好了非常丰富和完整的异常对象分类模型。因此， java 程序员一般是不需要再重新定义自己的异常对象。而且即便是需要扩展自定义的异常对象，也往往会从 Exception 派生而来。所以，对于 java 程序员而言，它一般只需要在它的顶级函数中 catch(Exception ex) 就可以捕获出所有的异常对象。 所有异常对象的根基类是 Throwable ， Throwable 从 Object 直接继承而来（这是 java 系统所强制要求的），并且它实现了 Serializable 接口（这为所有的异常对象都能够轻松跨越 Java 组件系统做好了最充分的物质准备）。从 Throwable 直接派生出的异常类有 Exception 和 Error 。 Exception 是 java 程序员所最熟悉的，它一般代表了真正实际意义上的异常对象的根基类。也即是说， Exception 和从它派生而来的所有异常都是应用程序能够 catch 到的，并且可以进行异常错误恢复处理的异常类型。而 Error 则表示 Java 系统中出现了一个非常严重的异常错误，并且这个错误可能是应用程序所不能恢复的，例如 LinkageError ，或 ThreadDeath 等。
首先还是看一个例子吧！代码如下：
import java.io.*;
public class Trans
{
public static void main(String[] args)
{
try
{
BufferedReader rd=null;
Writer wr=null;
try
{
File srcFile = new File((args[0]));
File dstFile = new File((args[1]));
rd = new BufferedReader(new InputStreamReader(new FileInputStream(srcFile), args[2]));
wr = new OutputStreamWriter(new FileOutputStream(dstFile), args[3]);
// 注意下面这条语句，它有什么问题吗？
if (rd == null || wr == null) throw new Exception("error! test!");
while(true)
{
String sLine = rd.readLine();
if(sLine == null) break;
wr.write(sLine);
wr.write("\r\n");
}
}
finally
{
wr.flush();
wr.close();
rd.close();
}
}
catch(IOException ex)
{
ex.printStackTrace();
}
}
}
熟悉 java 语言的程序员朋友们，你们认为上面的程序有什么问题吗？编译能通过吗？如果不能，那么原因又是为何呢？好了，有了自己的分析和预期之后，不妨亲自动手编译一下上面的小程序，呵呵！结果确实如您所料？是的，的确是编译时报错了，错误信息如下：
E:\Trans.java:20: unreported exception java.lang.Exception; must be caught or declared to be thrown
if (rd == null || wr == null) throw new Exception("error! test!");
1 error
上面这种编译错误信息，相信 Java 程序员肯定见过（可能还是屡见不鲜！）！
相信老练一些的 Java 程序员一定非常清楚上述编译出错的原因。那就是如错误信息中（“ must be caught ”）描述的那样， 在 Java 的异常处理模型中，要求所有被抛出的异常都必须要有对应的“异常处理模块” 。也即是说，如果你在程序中 throw 出一个异常，那么在你的程序中（函数中）就必须要 catch 这个异常（处理这个异常）。例如上面的例子中，你在第 20 行代码处，抛出了一个 Exception 类型的异常，但是在该函数中，却没有 catch 并处理掉此异常的地方。因此，这样的程序即便是能够编译通过，那么运行时也是致命的（可能导致程序的崩溃），所以， Java 语言干脆在编译时就尽可能地检查（并卡住）这种本不应该出现的错误，这无疑对提高程序的可靠性大有帮助。
但是，在 Java 语言中，这就是必须的。 如果一个函数中，它运行时可能会向上层调用者函数抛出一个异常，那么，它就必须在该函数的声明中显式的注明（采用 throws 关键字） 。还记得刚才那条编译错误信息吗？“ must be caught or declared to be thrown ”，其中“ must be caught ”上面已经解释了，而后半部分呢？“ declared to be thrown ”是指何意呢？其实指的就是“必须显式地声明某个函数可能会向外部抛出一个异常”，也即是说，如果一个函数内部，它可能抛出了一种类型的异常，但该函数内部并不想（或不宜） catch 并处理这种类型的异常，此时，它就必须使用 throws 关键字来声明该函数可能会向外部抛出一个异常，以便于该函数的调用者知晓并能够及时处理这种类型的异常。下面列出了这几种情况的比较，代码如下：
// 示例程序 1 ，这种写法能够编译通过
package com.ginger.exception;
import java.io.*;
public class Trans {
        public static void main(String[] args) {
                try {
                        test();
                } catch (Exception ex) {
                        ex.printStackTrace();
                }
        }
        static void test() {
                try {
                        throw new Exception("To show Exception Successed");
                } catch (Exception ex) {
                        ex.printStackTrace();
                }
        }
}
// 示例程序 2 ，这种写法就不能够编译通过
import java.io.*;
public class Trans {
        public static void main(String[] args) {
                try {
                        test();
                }
                // 虽然这里能够捕获到 Exception 类型的异常
                catch (Exception ex) {
                        ex.printStackTrace();
                }
        }
        static void test() {
                throw new Exception("test");
        }
}
// 示例程序 3 ，这种写法又能够被编译通过
import java.io.*;
public class Trans
{
public static void main(String[] args)
{
try
{
test();
}
catch(Exception ex)
{
ex.printStackTrace();
}
}
// 由于函数声明了可能抛出 Exception 类型的异常
static void test() throws Exception
{
throw new Exception("test");
}
}
// 示例程序 4 ，它又不能够被编译通过了
import java.io.*;
public class Trans
{
public static void main(String[] args)
{
try
{
// 虽然 test() 函数并没有真正抛出一个 Exception 类型的异常
// 但是由于它函数声明时，表示它可能抛出一个 Exception 类型的异常
// 所以，这里仍然不能被编译通过。
// 呵呵！体会到了 Java 异常处理模型的严谨吧！
test();
}
catch(IOException ex)
{
ex.printStackTrace();
}
}
static void test() throws Exception
{
}
}
不知上面几个有联系的示例是否能够给大家带来“豁然开朗”的感觉，坦率的说， Java 提供的异常处理模型并不复杂，相信太多太多 Java 程序员有着比我更深刻的认识。最后，补充一种例外情况，请看如下代码：
import java.io.*;
public class Trans {
        public static void main(String[] args) {
                try {
                        test();
                } catch (Exception ex) {
                        ex.printStackTrace();
                }
        }
        static void test() throws Error {
                throw new Error(" 故意抛出一个 Error");
        }
}
朋友们！上面的程序能被编译通过吗？注意，按照刚才上面所总结出的规律：在 Java 的异常处理模型中，要求所有被抛出的异常都必须要有对应的 catch 块！那么上面的程序肯定不能被编译通过，因为 Error 和 Exception 都是从 Throwable 直接派生而来，而 test 函数声明了它可能抛出 Error 类型的异常，但在 main 函数中却并没有 catch(Error) 或 catch(Throwable) 块，所以它理当是会编译出错的！真的吗？不妨试试！呵呵！结果并非我们之预料，而它恰恰是正确编译通过了。为何？ WHY ？ WHY ？
其实，原因很简单，那就是因为 Error 异常的特殊性。 Java 异常处理模型中规定： Error 和从它派生而来的所有异常，都表示系统中出现了一个非常严重的异常错误，并且这个错误可能是应用程序所不能恢复的（其实这在前面的内容中已提到过）。因此，如果系统中真的出现了一个 Error 类型的异常，那么则表明，系统已处于崩溃不可恢复的状态中，此时，作为编写 Java 应用程序的你，已经是没有必要（也没能力）来处理此等异常错误。所以， javac 编译器就没有必要来保证：“在编译时，所有的 Error 异常都有其对应的错误处理模块”。当然， Error 类型的异常一般都是由系统遇到致命的错误时所抛出的，它最后也由 Java 虚拟机所处理。而作为 Java 程序员的你，可能永远也不会考虑抛出一个 Error 类型的异常。因此 Error 是一个特例情况！
特别关注一下 RuntimeException
上面刚刚讨论了一下 Error 类型的异常处理情况， Java 程序员一般无须关注它（处理这种异常）。另外，其实在 Exception 类型的异常对象中，也存在一种比较特别的“异常”类型，那就是 RuntimeException ，虽然它是直接从 Exception 派生而来，但是 Java 编译器（ javac ）对 RuntimeException 却是特殊待遇，而且是照顾有加。不信，看看下面的两个示例吧！代码如下：
// 示例程序 1
// 它不能编译通过，我们可以理解
import java.io.*;

public class Trans {
        public static void main(String[] args) {
                test();
        }

        static void test() {
                // 注意这条语句
                throw new Exception(" 故意抛出一个 Exception");
        }
}
// 示例程序 2
// 可它却为什么能够编译通过呢？
import java.io.*;

public class Trans {
        public static void main(String[] args) {
                test();
        }

        static void test() {
                // 注意这条语句
                throw new RuntimeException(" 故意抛出一个 RuntimeException");
        }
}
对上面两个相当类似的程序， javac 编译时却遭遇了两种截然不同的处理，按理说，第 2 个示例程序也应该像第 1 个示例程序那样，编译时报错！但是 javac 编译它时，却例外地让它通过它，而且在运行时， java 虚拟机也捕获到了这个异常，并且会在 console 打印出详细的异常信息。运行结果如下：
java.lang.RuntimeException: 故意抛出一个 RuntimeException
at Trans.test(Trans.java:13)
at Trans.main(Trans.java:8)
Exception in thread "main"
为什么对于 RuntimeException 类型的异常（以及从它派生而出的异常类型）， javac 和 java 虚拟机都特殊处理呢？要知道，这可是与“ Java 异常处理模型更严谨和更安全”的设计原则相抵触的呀！究竟是为何呢？这简直让人不法理解呀！
只不过， Java 语言中， RuntimeException 被统一纳入到了 Java 语言和 JDK 的规范之中。请看如下代码，来验证一下我们的理解！
import java.io.*;
public class Trans
{
public static void main(String[] args)
{
test();
}
static void test()
{
int i = 4;
int j = 0;
// 运行时，这里将触发了一个 ArithmeticException
// ArithmeticException 从 RuntimeException 派生而来
System.out.println("i / j = " + i / j);
}
}
运行结果如下：
java.lang.ArithmeticException: / by zero
at Trans.test(Trans.java:16)
at Trans.main(Trans.java:8)
Exception in thread "main"
又如下面的例子，也会产生一个 RuntimeException ，代码如下：
import java.io.*;
public class Trans
{
public static void main(String[] args)
{
test();
}
static void test()
{
String str = null;
// 运行时，这里将触发了一个 NullPointerException
// NullPointerException 从 RuntimeException 派生而来
str.compareTo("abc");
}
}
所以，针对 RuntimeException 类型的异常， javac 是无法通过编译时的静态语法检测来判断到底哪些函数（或哪些区域的代码）可能抛出这类异常（这完全取决于运行时状态，或者说运行态所决定的），也正因为如此， Java 异常处理模型中的“ must be caught or declared to be thrown ”规则也不适用于 RuntimeException （所以才有前面所提到过的奇怪编译现象，这也属于特殊规则吧）。但是， Java 虚拟机却需要有效地捕获并处理此类异常。当然， RuntimeException 也可以被程序员显式地抛出，而且为了程序的可靠性，对一些可能出现“运行时异常（ RuntimeException ）”的代码区域，程序员最好能够及时地处理这些意外的异常，也即通过 catch(RuntimeExcetion) 或 catch(Exception) 来捕获它们。如下面的示例程序，代码如下：
import java.io.*;
public class Trans
{
public static void main(String[] args)
{
try
{
test();
}
// 在上层的调用函数中，最好捕获所有的 Exception 异常！
catch(Exception e)
{
System.out.println("go here!");
e.printStackTrace();
}
}
// 这里最好显式地声明一下，表明该函数可能抛出 RuntimeException
static void test() throws RuntimeException
{
String str = null;
// 运行时，这里将触发了一个 NullPointerException
// NullPointerException 从 RuntimeException 派生而来
str.compareTo("abc");
}
}

摘要

　　Java开发人员做出的有关架构的最重要的决定之一便是如何使用Java异常模型。Java异常处理成为社区中讨论最多的话题之一。一些人认为 Java语言中的已检查异常（Checked Exceptions）是一次失败的尝试。本文认为错误并不在于Java模型本身，而在于Java库设计人员没有认识到方法失败的两个基本原因。本文提倡 思考异常情况的本质，并描述了有助于用户设计的设计模式。最后，本文讨论了异常处理在面向方面编程（Aspect Oriented Programming）模型中作为横切关注点（crosscutting concern）的情况。如果使用得当，Java异常将对程序开发人员大有裨益。本文将帮助读者正确使用Java异常。

为什么异常非常重要

　　Java应用程序中的异常处理可以告诉用户构建应用程序的架构强度。架构是指在应用程序的各个层面上所做出的并始终遵守的决策。其中最重要的决 策之一便是应用程序中类、子系统或层之间进行互相通信的方式。方法通过Java异常可以为操作传递另一种结果，因此应用程序架构特别值得我们去关注。

　 　判断Java架构师技能的高低和开发团队是否训练有素，其中比较好的方法是查看应用程序中的异常处理代码。首先需要观察的是有多少代码专门用于捕捉异 常、记录异常、确定发生的事件和异常转化。简洁、紧凑和有条理的异常处理表明团队有使用Java异常的一致方法。当异常处理代码的数量将要超过其他方面的 代码时，可以断定团队成员之间的沟通已经打破（或者这种沟通从一开始就不存在），每个人都用自己的方法来处理异常。

　　临时异常处理的结果 非常具有预见性。如果问团队成员为什么在代码的某个特定点丢弃、捕捉、或忽略某个异常，回答通常是：“除此之外，我不知道怎么做。”如果问他们在编写代码 的异常实际发生时会产生什么情况，他们通常会皱眉，回答类似于：“我不知道。我们从来没有测试过。”

　　要判断Java组件是否有效地利用 了Java异常，可以查看其客户端的代码。如果客户端代码中包含大量计算操作失败时间、原因和处理方法的逻辑，原因几乎都是由于组件的错误报告设计。有缺 陷的报告会在客户端产生大量的“记录和遗留”（log and forget）代码，而没有任何用途。最糟糕的是扭曲的逻辑路径、互相嵌套的try/catch/finally程序块，以及其他导致脆弱和无法管理的应 用程序的混乱。

　　事后处理异常（或者根本不处理）是造成软件项目混乱和延迟的主要原因。异常处理关系到软件设计的各个方面。为异常建立架构约定应该是项目中首先要做出的决定之一。合理使用Java异常模型将对保持应用程序的简洁性、可维护性和正确性大有帮助。

挑战异常准则

　　如何正确使用Java异常模型已经成为大量讨论的主题。Java并不是支持异常语义的第一种语言；但是，通过Java编译器可强制使用规则来控 制如何声明和处理特定的异常。许多人认为编译时异常检查对精确软件设计有帮助，它与其他语言特征能够很好地协调起来。图1表明了Java异常的层次结构。

　 　通常，Java编译器会根据java.lang.Throwable强制方法抛出异常，包括其声明中“throw”子句的异常。同样，编译器会验证方法 的客户端是捕获声明异常类型还是指定自己抛出异常类型。这些简单的规则对于全世界的Java开发人员产生了深远的影响。

　　编译器针对 Throwable继承树的两个分支放宽了异常检查行为。java.lang.Error和java.lang.RuntimeException的子类 免于编译时检查。在两者中，软件设计人员通常对运行时异常更感兴趣。通常使用术语“未检查异常”（unchecked exception）来区分其他的所有“已检查异常”（checked exception）

图 1 Java异常层次结构

我认为已检查异常会受到那些重视Java语言中强类型的人的欢迎。毕竟，由编译器对数据类型产生的约束会鼓励严格编码和精确思维。编译时类型检查有 助于防止在运行时产生难以应付的意外事件。编译时异常检查将起到相同的效果，提醒开发人员注意的是，方法会有潜在的其他结果需要进行处理。

　 　在早期，推荐无论何处都尽量使用已检查异常，以便充分借助编译器生产出无差错软件。Java API库的设计人员显然赞成已检查异常准则，并广泛使用这些异常来模仿在库方法中发生的任何意外事件。在J2SE 5.1 API规范中，已检查异常类型仍然比未检查异常类型多，比例要超过二比一。

　　对于程序员来说，Java类库中的绝大多数公共方法好像为每一个可能的失败都声明了已检查异常。例如，java.io包对已检查异常IOException的依赖性特别大。至少63个Java库包直接或间接通过其数十个子类之一发布了此异常。

　 　I/O失败很严重但也很少见。另外，程序代码通常没有能力从失败中恢复。Java程序员发现他们必须提供IOException和类似在简单的Java 库方法调用时可能发生的不可恢复的事件。捕捉这些异常只会打乱原有简洁的代码，因为捕捉块并不能改善此类情况。而不捕捉这些异常可能会更糟糕，因为编译器 要求将这些异常加入到方法所抛出的异常列表中。这公开了一些实现细节，优秀的面向对象设计自然会将这些细节隐藏起来。

　　这种无法成功的情况导致许多严重违反Java编程模式的异常处理。当今的程序员经常被告诫要提防这些情况。同样，在创建工作区方面也产生大量正确和错误的建议。

　　一些Java天才开始质疑Java已检查异常模型是否是一次失败的尝试。可以确定某个地方出了问题，但是这和Java语言中的异常检查无关。失败的原因是Java API设计人员的思考方式，即他们认为大多数失败情况都相同，并且可以用相同类型的异常来传达。

错误和意外事件

　　假想金融应用软件中的CheckingAccount类。CheckingAccount属于客户，维护当前余额，并且可以接受存款，根据支票 接受终止支付命令，以及处理入帐的支票。CheckingAccount对象必须协调并发线程的访问，因为每一个线程都可以改变它的状态。 CheckingAccount的processCheck()方法将Check对象作为参数，从账户余额中正常扣除支票金额。但是调用 processCheck()的支票结算客户端必须为两类意外事件做好准备。首先，CheckingAccount 可能有为支票注册的终止支付命令。第二，账户中可能没有足够的资金来支付支票金额。

　　所以，processCheck()方法使用三种可 能的方式来响应其调用者。正常的响应方式是支票得到处理，在方法签名中声明的结果返回给调用服务。这两类意外事件响应代表了金融领域非常真实的情况，它们 需要与支票结算客户端进行通信。所有这三种processCheck()响应都是为模仿典型的支票账户行为而精心设计的。

　　在Java中 表示意外事件响应的通常方法是定义两种异常，即StopPaymentException和InsufficientFundsException。客户 端忽略这两个异常是不正确的，因为在应用程序正常操作时会被抛出这两个异常。这两个异常有助于表达方法的所有行为，和方法签名一样十分重要。

　　客户端可以轻松地处理这两类异常。如果终止支票的支付，客户端可以取得支票进行特殊处理。如果没有足够的资金，为支付此支票，客户端将从客户的储蓄帐户中转移资金，并重新尝试。

　　这些意外事件可以预见，它是使用CheckingAccount API的自然结果。它们并不表示软件或执行环境的失败。将这些异常条件与实际的失败对比，实际的失败是由于CheckingAccount类的内部实现细节问题造成的。

　 　假设CheckingAccount在数据库中维持持久的状态并使用JDBC API进行访问。在该API中，几乎每一个数据库访问方法都有失败的可能性，但原因与CheckingAccount实现无关。例如，有人会忘记打开数据 库服务器、不小心拔下了网线，或改变了访问数据库的密码。

　　JDBC依靠单独的已检查异常SQLException来报告一切可能的错 误。大多数错误都与数据库的配置、连接和硬件设备有关。processCheck()方法并不能以有意义的方式处理这些异常条件。很遗憾，因为 processCheck()至少知道它自己的实现方式。调用堆栈中的上游方法能够处理这些问题的可能性会更小。

　　CheckingAccount示例解释了导致方法执行不能返回预期结果的两个基本原因。下面首先介绍一些描述性术语：

意外事件

　　 是一种可以预见的情况，要求方法做出某种响应，以便能够表达方法所期望的目的。方法的调用者预见这些情况并采取策略应付这些情况。

错误

　　 是一种计划外的情况，它阻止方法达到其预期目的，并且如果不引用方法的内部实现，则无法描述这种情况。

　　从这两个术语来看，终止支付命令和透支是processCheck()方法两个可能的意外事件。SQL问题代表了可能的错误异常条件。processCheck()的调用者应当提供一种处理意外事件的方式，但当错误发生时，并不能合理地处理该错误。

映射Java异常

　　对于意外事件和错误，思考其原因将有助于为应用程序架构中的Java异常建立约定。

　　意外事件异常条件完美地映射到Java已检查异常。由于它们是方法语义契约中不可或缺的一部分，因此必须借助编译器来确保问题得到了处理。如果 开发人员坚持在编译器有问题时处理或声明意外事件异常，此时编译器会成为一种阻碍，可以断定此软件设计必须进行部分重构。这其实是一件好事。

　 　错误条件对编程人员来说能够引起关注，而对于软件逻辑却并非如此。“软件诊断学家”收集错误信息以诊断和修复引起错误发生的根源。因此，未检查Java 异常是错误的完美表现方式，它们可以使错误通知完整地过滤调用堆栈上的所有方法，传递到专门用于捕捉错误的层，捕获其中所包含的诊断信息，并为此活动提供 一份受约束的合理结论。错误产生方法并不需要声明，上游代码也不需要捕获它们，方法的实现得到了有效的隐藏——产生最少的代码混乱。

　　较 新的Java API（比如Spring Framework和Java Data Object库）很少或根本不依赖于已检查异常。Hibernate ORM framework从release 3.0起重新定义了关键设备，以免于使用已检查异常。这反映了由这些框架报告的绝大部分异常异常条件是不可恢复的，这些异常源于方法调用的不正确编码或数 据库服务器失效等基本组件原因。实际上，强制调用者去捕捉或声明这样异常几乎没有任何益处。

架构中的错误处理

　　 在架构中有效处理错误的第一步是承认处理错误的必要性。承认这一点对于工程师来说有困难，因为他们认为自己有能力创造无缺陷的软件，并引以为豪。下面这些 理由可能有所帮助。首先，应用程序开发会在常见错误上花费大量的时间。提供程序员产生的错误将使团队诊断和修复这些错误变得十分简单。第二，对于错误异常 条件过度使用Java库中的已检查异常将强制代码来处理这些错误，即使调用顺序完全正确。如果没有适当的错误处理框架，由此产生的暂时异常处理将向应用程 序中插入平均信息量。

　　成功的错误处理框架必须达到四个目标：

• 使代码混乱最小化
• 捕捉并保留诊断信息
• 通知合适的人员
• 比较得体地退出活动

　　错误会分散应用程序的真正目的。因此，用于错误处理的代码数量应当最小化，并在理想情况下，应与程序的语义部分隔离。错误处理必须满足纠错人员 的需要。他们需要知道是否发生错误并且获取相关信息以判断错误原因。尽管从定义上说，错误不可恢复，但可靠的错误处理措施将以得体地方式终结出现错误的活 动。

对于错误异常条件使用未检查异常

　　 有许多原因使我们做出使用未检查异常表示错误异常条件的架构性决定。作为对编程错误的回报，Java运行时将抛出RuntimeException的子类 （比如ArithmeticException和ClassCastException），针对架构设定先例。未检查异常使上游方法摆脱了包含无关代码的 要求，从而最大限度地减少了混乱。

　　错误处理策略应当承认Java库和其他API中的方法可能使用已检查异常来表示应用程序环境下的错误异常条件。在这种情况下，采用架构惯例在其出现的地方捕捉API异常，将它作为错误，并抛出未检查异常来说明错误异常条件并捕捉诊断信息。

　 　在这种情况下抛出的特定异常类型应当由架构本身定义。不要忘记错误异常的主要目的是传达诊断信息并记录，以帮助开发人员发现问题产生的原因。使用多错误 异常类型可能有些过度，因为架构会对它们进行完全相同的处理。在绝大多数情况下，把良好的描述性文本消息嵌入到单独的错误类型中，便可完成此项工作。使用 Java的一般RuntimeException来表示错误条件很容易进行防御。从Java 1.4时起，RuntimeException同其他throwable类一样，支持异常处理链式机制，允许设计人员捕捉并报告导致错误的已检查异常。

　 　设计人员可以定义自己的未检查异常进行报告错误。如果需要使用不支持异常链接机制的Java 1.3或更早版本，这一步是必需的。实现相似的链接功能去捕捉并转换引起应用程序错误的异常相当简单。在错误报告异常中，应用程序可能需要特别的行为。这 可能是为架构创建RuntimeException子类的另一个原因。

建立错误屏障

　　 决定哪些异常要抛出以及何时抛出将成为错误处理框架的重要决定。同样重要的问题是何时捕捉错误异常及其后如何做。这里的目标是使应用程序的功能部分从处理错误的职责中分离出来。关注点分离通常是比较好的做法。负责处理错误的中央设备将为您带来很多的好处。

　 　在错误屏障（fault barrier）模式下，任何应用程序组件都可以抛出错误异常，但只有作为“错误屏障”的组件才可以捕捉到错误异常。开发人员为了处理错误问题在应用程序 中插入了大量复杂代码，而采用此模式可消除大部分此类代码。从逻辑上讲，错误屏障存在于靠近调用堆栈的顶端。在这里，它可以阻断异常向上传播，以避免触发 默认动作。默认动作根据应用程序类型的不同而不同。对于独立的Java应用程序来说，默认动作意味着终止活动线程。对于驻留在应用服务器上的Web应用程 序，默认动作意味着应用服务器会向浏览器发送不友好的（且令人为难的）响应。

　　错误屏障组件的首要职责是记录包含在错误异常中的信息，以 便进行下一步行动。应用程序日志是迄今为止做这件事情最理想的方法。异常的链信息、堆栈跟踪等对于诊断专家来说都是有价值的信息。发送错误信息最差的地方 是通过用户界面。将客户牵涉到应用程序的排错过程中，将对开发人员或客户没有任何益处。如果开发人员真的把诊断信息添加到了用户界面上，这说明开发人员的 记录策略需要改进。

　　错误屏障的下一个职责是以受控方式停止操作。这个职责的含义由应用程序的设计决定，但是通常会涉及到为等待响应的客 户端发出总体响应。如果应用程序是Web service，这意味着使用soap:Server的和普通失败消息将 SOAP 元素嵌入到响应中。如果应用程序与Web浏览器进行通信，屏障将安排发送普通的HTML响应，表示无法处理此请求。

　 　在Struts应用程序中，错误屏障采用全局异常处理程序的形式，配置成可以处理RuntimeException的任何子类。错误屏障类将扩展 org.apache.struts.action.ExceptionHandler，在需要实现自定义处理时重写方法。这将处理由于疏忽产生的错误条 件和处理Struts操作中明显发现的错误条件。图2显示了意外事件异常和错误异常。

图2 意外事件异常和错误异常

　　当架构包含错误屏障并且开发人员也意识到了它的存在时，编写一劳永逸的错误异常处理代码的吸引力急剧下降。结果是在应用程序中产生更简洁和更易维护的代码。

架构中的意外事件处理

　　随着错误处理委托给屏障，主要组件之间的意外事件通信变得更加简单。意外事件代表了另一种方法结果，此结果与主要返回结果同样重要。因此，已检 查异常类型是传递意外事件条件存在性并提供对付异常条件所需信息的良好工具。最佳实践是借助Java编译器来提醒开发人员他们正在使用API的所有方面， 同样需要提供方法结果的全部范围。

　　通过单独使用方法的返回类型，可以传递简单的意外事件。例如，返回null引用而非实际对象可以说明 此对象由于明确的原因而无法创建。Java I/O方法通常返回整数值-1，而不是字节值或字节计数，用来表明文件的结束。如果方法的语义非常简单允许这样做，另一种返回值可以使用这种方式，因为它 们消除了由异常而带来的开销。不利方面是方法调用者负责检测返回值，来查看它是主要结果还是意外事件结果。然而，编译器并不强制调用者做这样的测试。

　 　如果方法具有void返回类型，异常将是表明意外事件发生的唯一方法。如果方法返回对象引用，则返回值所表达的意思仅限于两个值（null和non- null）。如果方法返回整数值，通过选择确保与主要返回值不相冲冲突的值，就可以表达数个意外事件条件。但是现在已经进入了错误代码检查的范畴，这是 Java异常模型需要避免的情况。

提供有用的信息

　　 定义不同的错误报告异常类型没有任何道理，因为错误屏障会对它们进行同样的处理。意外事件异常差异很大，因为它们会向方法调用者传达各种条件。您的架构可能明确指定这些异常都应该扩展java.lang.Exception或指定的基类。

　 　不要忘记这些异常是完整的Java类型，可以调整特定的字段、方法以及为特殊目的而构建的构造函数。例如，假想的CheckingAccount processCheck()方法抛出的InsufficientFundsException类型可能包括OverdraftProtection对 象，此对象能够转移资金以弥补另一个账户的资金短缺，此账户的身份取决于设置核算账户的方式。

记录还是不记录

　　 记录错误异常有实际意义是因为它们的目的是吸引开发人员去注意需要纠正的情况。但这并不适用于意外事件异常。它们可能代表相对少见的事件，但是在应用程序 的生命周期内，这些意外事件依然会发生。它们表明了如发生异常应用程序将按照其设计意图进行工作。按照惯例，在意外事件捕捉模块中加入记录代码只会增加混 乱代码而没有任何益处。如果意外事件表示重要事件，最好为方法产生一条记录项，用于在抛出意外事件异常并通知其调用者之前记录此事件。

异常方面

　　在面向方面编程（Aspect Oriented Programming (AOP)）中，错误和意外事件的处理是横切关注点。例如，要实现错误屏障模式，所有参与的类都必须遵守公共约定：

• 错误屏障方法必须驻留在遍历参与类的方法调用的头部。
• 它们都必须使用未检查异常来表示错误条件。
• 它们都必须使用特定的未检查异常类型，以便错误屏障能够接收到。
• 它们都必须从较低层方法中捕捉并转换已检查异常，这些异常在它们的执行环境中被视为错误。
• 它们不能干扰错误异常到屏障的传播。

　　这些关注点跨越了其他不相关类的边界。结果产生了少量分散错误处理代码并致使屏障类与参与者之间的隐式耦合（尽管对于完全没有使用模式来说是一 次重大改进）。AOP允许将错误处理关注点封装到应用于参与类的公共Aspect中。Java AOP框架（比如AspectJ和Spring AOP）把异常处理作为联接点，错误处理行为（或建议）能够附加到上面。这样，在错误屏障模式中绑定参与者的惯例就有所放宽。错误处理现在可以存在于独立 的非内联方面（out-of-line aspect）中，避免了将“屏障”方法置于方法调用序列的前面。

　　如果开发人员在架构中使用AOP，错误和意外事件的处理是方面在整个应用程序中应用的理想候选对象。完全探究错误和意外事件处理在AOP中如何运作，这是个令人感兴趣的话题，留作以后讨论。

结束语

　　尽管Java异常模型在其生命周期内已经引发了激烈的争论，但是当Java异常模型运用得当时，将会带来巨大的价值。作为架构师，应当决定如何 建立最大限度利用模型的惯例。思考一下错误和意外事件异常能够帮助开发人员做出正确的选择。Java异常模型使用得当，将保持应用程序的简洁性、可维护性 和正确性。把面向方面编程技术的错误和意外事件处理作为横切关注点，可为应用程序的架构带来某些明显的优势。

2007-04-12 12:41     推荐:2129    收藏:1369    评论:0     来源:IT168
编者按：Java内存泄漏是每个Java程序员都会遇到的问题，程序在本地运行一切正常，可是布署到远端就会出现内存无限制的增长，最后系统瘫痪，那么如何最快最好的检测程序的稳定性，防止系统崩盘，作者用自已的亲身经历与各位网友分享解决这些问题的办法。

作为Internet最流行的编程语言之一,Java现正非常流行。我们的网络应用程序就主要采用Java语言开发，大体上分为客户端、服务器和数据库三 个层次。在进入测试过程中，我们发现有一个程序模块系统内存和CPU资源消耗急剧增加，持续增长到出现 java.lang.OutOfMemoryError为止。经过分析Java内存泄漏是破坏系统的主要因素。这里与大家分享我们在开发过程中遇到的 Java内存泄漏的检测和处理解决过程.

一. Java是如何管理内存

为了判断Java中是否有内存泄露，我们首先必须了解Java是如何管理内存的。Java的内存管理就是对象的分配和释放问题。在Java中，内存的分配 是由程序完成的，而内存的释放是由垃圾收集器(Garbage Collection，GC)完成的，程序员不需要通过调用函数来释放内存，但它只能回收无用并且不再被其它对象引用的那些对象所占用的空间。

Java的内存垃圾回收机制是从程序的主要运行对象开始检查引用链，当遍历一遍后发现没有被引用的孤立对象就作为垃圾回收。GC为了能够正确释放对象，必 须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控。监视对象状态是为了更加准确地、及时地释放对象，而释放对象的 根本原则就是该对象不再被引用。

在Java中，这些无用的对象都由GC负责回收，因此程序员不需要考虑这部分的内存泄露。虽然，我们有几个函数可以访问GC，例如运行GC的函数 System.gc()，但是根据Java语言规范定义，该函数不保证JVM的垃圾收集器一定会执行。因为不同的JVM实现者可能使用不同的算法管理 GC。通常GC的线程的优先级别较低。JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行 GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。

一. 什么是Java中的内存泄露

导致内存泄漏主要的原因是，先前申请了内存空间而忘记了释放。如果程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收 器GC验证这些对象是否不再需要。如果存在对象的引用，这个对象就被定义为"有效的活动"，同时不会被释放。要确定对象所占内存将被回收，我们就要务必确 认该对象不再会被使用。典型的做法就是把对象数据成员设为null或者从集合中移除该对象。但当局部变量不需要时，不需明显的设为null，因为一个方法 执行完毕时，这些引用会自动被清理。

在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是有被引用的，即在有向树形图中，存在树枝通路可以与其相连； 其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回 收，然而它却占用内存。

这里引用一个常看到的例子，在下面的代码中，循环申请Object对象，并将所申请的对象放入一个Vector中，如果仅仅释放对象本身，但因为 Vector仍然引用该对象，所以这个对象对GC来说是不可回收的。因此，如果对象加入到Vector后，还必须从Vector中删除，最简单的方法就是 将Vector对象设置为null。

实际上这些对象已经是无用的，但还被引用，GC就无能为力了(事实上GC认为它还有用)，这一点是导致内存泄漏最重要的原因。 再引用另一个例子来说明Java的内存泄漏。假设有一个日志类Logger，其提供一个静态的log(String msg)，任何其它类都可以调用Logger.Log(message)来将message的内容记录到系统的日志文件中。

Logger类有一个类型为HashMap的静态变量temp，每次在执行log(message)的时候，都首先将message的值写入temp中 (以当前线程+当前时间为键)，在退出之前再从temp中将以当前线程和当前时间为键的条目删除。注意，这里当前时间是不断变化的，所以log在退出之前 执行删除条目的操作并不能删除执行之初写入的条目。这样，任何一个作为参数传给log的字符串最终由于被Logger的静态变量temp引用，而无法得到 回收，这种对象保持就是我们所说的Java内存泄漏。 总的来说，内存管理中的内存泄漏产生的主要原因：保留下来却永远不再使用的对象引用。

三. 几种典型的内存泄漏

我们知道了在Java中确实会存在内存泄漏，那么就让我们看一看几种典型的泄漏，并找出他们发生的原因和解决方法。

3.1 全局集合
在大型应用程序中存在各种各样的全局数据仓库是很普遍的，比如一个JNDI-tree或者一个session table。在这些情况下，必须注意管理储存库的大小。必须有某种机制从储存库中移除不再需要的数据。

通常有很多不同的解决形式，其中最常用的是一种周期运行的清除作业。这个作业会验证仓库中的数据然后清除一切不需要的数据。

另一种管理储存库的方法是使用反向链接(referrer)计数。然后集合负责统计集合中每个入口的反向链接的数目。这要求反向链接告诉集合何时会退出入口。当反向链接数目为零时，该元素就可以从集合中移除了。
　　
3.2 缓存
缓存一种用来快速查找已经执行过的操作结果的数据结构。因此，如果一个操作执行需要比较多的资源并会多次被使用，通常做法是把常用的输入数据的操作结果进 行缓存，以便在下次调用该操作时使用缓存的数据。缓存通常都是以动态方式实现的,如果缓存设置不正确而大量使用缓存的话则会出现内存溢出的后果，因此需要 将所使用的内存容量与检索数据的速度加以平衡。

常用的解决途径是使用java.lang.ref.SoftReference类坚持将对象放入缓存。这个方法可以保证当虚拟机用完内存或者需要更多堆的时候，可以释放这些对象的引用。

3.3 类装载器
Java类装载器的使用为内存泄漏提供了许多可乘之机。一般来说类装载器都具有复杂结构，因为类装载器不仅仅是只与"常规"对象引用有关，同时也和对象内 部的引用有关。比如数据变量，方法和各种类。这意味着只要存在对数据变量，方法，各种类和对象的类装载器，那么类装载器将驻留在JVM中。既然类装载器可 以同很多的类关联，同时也可以和静态数据变量关联，那么相当多的内存就可能发生泄漏。

四. 如何检测和处理内存泄漏
如何查找引起内存泄漏的原因一般有两个步骤:第一是安排有经验的编程人员对代码进行走查和分析，找出内存泄漏发生的位置;第二是使用专门的内存泄漏测试工具进行测试。

第一个步骤在代码走查的工作中，可以安排对系统业务和开发语言工具比较熟悉的开发人员对应用的代码进行了交叉走查，尽量找出代码中存在的数据库连接声明和结果集未关闭、代码冗余等故障代码。

第二个步骤就是检测Java的内存泄漏。在这里我们通常使用一些工具来检查Java程序的内存泄漏问题。市场上已有几种专业检查Java内存泄漏的工具， 它们的基本工作原理大同小异，都是通过监测Java程序运行时，所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员将根 据这些信息判断程序是否有内存泄漏问题。这些工具包括Optimizeit Profiler，JProbe Profiler，JinSight , Rational 公司的Purify等。

4.1检测内存泄漏的存在
这里我们将简单介绍我们在使用Optimizeit检查的过程。通常在知道发生内存泄漏之后，第一步是要弄清楚泄漏了什么数据和哪个类的对象引起了泄漏。

一般说来，一个正常的系统在其运行稳定后其内存的占用量是基本稳定的，不应该是无限制的增长的。同样，对任何一个类的对象的使用个数也有一个相对稳定的上 限，不应该是持续增长的。根据这样的基本假设，我们持续地观察系统运行时使用的内存的大小和各实例的个数，如果内存的大小持续地增长，则说明系统存在内存 泄漏，如果特定类的实例对象个数随时间而增长（就是所谓的“增长率”），则说明这个类的实例可能存在泄漏情况。

另一方面通常发生内存泄漏的第一个迹象是：在应用程序中出现了OutOfMemoryError。在这种情况下，需要使用一些开销较低的工具来监控和查找 内存泄漏。虽然OutOfMemoryError也有可能应用程序确实正在使用这么多的内存；对于这种情况则可以增加JVM可用的堆的数量，或者对应用程 序进行某种更改，使它使用较少的内存。

但是，在许多情况下，OutOfMemoryError都是内存泄漏的信号。一种查明方法是不间断地监控GC的活动，确定内存使用量是否随着时间增加。如果确实如此，就可能发生了内存泄漏。

4.2处理内存泄漏的方法
一旦知道确实发生了内存泄漏，就需要更专业的工具来查明为什么会发生泄漏。JVM自己是不会告诉您的。这些专业工具从JVM获得内存系统信息的方法基本上 有两种：JVMTI和字节码技术(byte code instrumentation)。Java虚拟机工具接口(Java Virtual Machine Tools Interface，JVMTI)及其前身Java虚拟机监视程序接口(Java Virtual Machine Profiling Interface，JVMPI)是外部工具与JVM通信并从JVM收集信息的标准化接口。字节码技术是指使用探测器处理字节码以获得工具所需的信息的技 术。

Optimizeit是Borland公司的产品，主要用于协助对软件系统进行代码优化和故障诊断，其中的Optimizeit Profiler主要用于内存泄漏的分析。Profiler的堆视图就是用来观察系统运行使用的内存大小和各个类的实例分配的个数的。

首先，Profiler会进行趋势分析，找出是哪个类的对象在泄漏。系统运行长时间后可以得到四个内存快照。对这四个内存快照进行综合分析，如果每一次快 照的内存使用都比上一次有增长，可以认定系统存在内存泄漏，找出在四个快照中实例个数都保持增长的类，这些类可以初步被认定为存在泄漏。通过数据收集和初 步分析，可以得出初步结论:系统是否存在内存泄漏和哪些对象存在泄漏(被泄漏)。

接下来，看看有哪些其他的类与泄漏的类的对象相关联。前面已经谈到Java中的内存泄漏就是无用的对象保持，简单地说就是因为编码的错误导致了一条本来不 应该存在的引用链的存在(从而导致了被引用的对象无法释放)，因此内存泄漏分析的任务就是找出这条多余的引用链，并找到其形成的原因。查看对象分配到哪里 是很有用的。同时只知道它们如何与其他对象相关联（即哪些对象引用了它们）是不够的，关于它们在何处创建的信息也很有用。

最后，进一步研究单个对象，看看它们是如何互相关联的。借助于Profiler工具，应用程序中的代码可以在分配时进行动态添加，以创建堆栈跟踪。也有可 以对系统中所有对象分配进行动态的堆栈跟踪。这些堆栈跟踪可以在工具中进行累积和分析。对每个被泄漏的实例对象，必然存在一条从某个牵引对象出发到达该对 象的引用链。处于堆栈空间的牵引对象在被从栈中弹出后就失去其牵引的能力，变为非牵引对象。因此，在长时间的运行后，被泄露的对象基本上都是被作为类的静 态变量的牵引对象牵引。
总而言之, Java虽然有自动回收管理内存的功能,但内存泄漏也是不容忽视,它往往是破坏系统稳定性的重要因素。

　1．InputStream

◇ 从流中读取数据：
int read( ); //读取一个字节，返回值为所读的字节
int read( byte b[ ] ); //读取多个字节，放置到字节数组b中，通常
//读取的字节数量为b的长度，返回值为实际
//读取的字节的数量
int read( byte b[ ], int off, int len ); //读取len个字节，放置
//到以下标off开始字节
//数组b中，返回值为实
//际读取的字节的数量
int available( ); 　　//返回值为流中尚未读取的字节的数量
long skip( long n )； //读指针跳过n个字节不读，返回值为实际
//跳过的字节数量

◇ 关闭流：
close( ); //流操作完毕后必须关闭

◇ 使用输入流中的标记：
void mark( int readlimit ); //记录当前读指针所在位置，readlimit
//表示读指针读出readlimit个字节后
//所标记的指针位置才失效
void reset( ); 　　　 //把读指针重新指向用mark方法所记录的位置
boolean markSupported( );　//当前的流是否支持读指针的记录功能

有关每个方法的使用，详见java API。


2．OutputStream

◇ 输出数据：
void write( int b ); 　　//往流中写一个字节b
void write( byte b[ ] ); //往流中写一个字节数组b
void write( byte b[ ], int off, int len ); //把字节数组b中从
//下标off开始，长度为len的字节写入流中

◇ flush( ) 　　　　　　//刷空输出流，并输出所有被缓存的字节
由于某些流支持缓存功能，该方法将把缓存中所有内容强制输出到流中。

◇ 关闭流：
close( ); 　　　　　　//流操作完毕后必须关闭

4．4．3 I/O中的例外

　　进行I/O操作时可能会产生I/O例外，属于非运行时例外，应该在程序中处理。如：FileNotFoundException, EOFException, IOException

4．5 文件处理

I/O处理中，最常见的是对文件的操作，java.io包中有关文件处理的类有：File、FileInputStream、 FileOutputStream、RamdomAccessFile和FileDescriptor；接口有：FilenameFilter。

4．5．1 文件描述

类File提供了一种与机器无关的方式来描述一个文件对象的属性。下面我们介绍类File中提供的各种方法。

　◇ 文件或目录的生成

public File(String path)；/*如果path是实际存在的路径，则该File对象
/*表示的是目录；如果path是文件名，则该File对象表示的是文件。*/
public File(String path,String name)；//path是路径名，name是文件名
public File(File dir,String name)；//dir是路径名，name是文件名

◇ 文件名的处理

String getName( )； //得到一个文件的名称（不包括路径）
String getPath( )； //得到一个文件的路径名
String getAbsolutePath( )；//得到一个文件的绝对路径名
String getParent( )； //得到一个文件的上一级目录名
String renameTo(File newName); //将当前文件名更名为给定文件的
完整路径

◇ 文件属性测试

boolean exists( )； //测试当前File对象所指示的文件是否存在
boolean canWrite( )；//测试当前文件是否可写
boolean canRead( )；//测试当前文件是否可读
boolean isFile( )； //测试当前文件是否是文件（不是目录）
boolean isDirectory( )； //测试当前文件是否是目录

◇ 普通文件信息和工具

long lastModified( );//得到文件最近一次修改的时间
long length( ); //得到文件的长度，以字节为单位
boolean delete( ); //删除当前文件

◇ 目录操作

boolean mkdir( ); //根据当前对象生成一个由该对象指定的路径
String list( ); //列出当前目录下的文件

【例4-3】
import java.io.*; //引入java.io包中所有的类
public class FileFilterTest{
public static void main(String args[]){
File dir=new File("d://ex"); //用File 对象表示一个目录
Filter filter=new Filter("java"); //生成一个名为java的过滤器
System.out.println("list java files in directory "+dir);
String files[]=dir.list(filter); //列出目录dir下，文件后缀名
为java的所有文件
for(int i=0;i<files.length;i++){
File f=new File(dir,files[i]); //为目录dir 下的文件或目录
创建一个File 对象
if(f.isFile()) //如果该对象为后缀为java的文件，
则打印文件名
System.out.println("file "+f);
else
System.out.println("sub directory "+f ); //如果是目录
则打印目录名
}
}
}
class Filter implements FilenameFilter{
String extent;
Filter(String extent){
this.extent=extent;
}
public boolean accept(File dir,String name){
return name.endsWith("."+extent); //返回文件的后缀名
}
}

其他内容请看：

http://www.bc-cn.net/Article/kfyy/java/jc/200410/81_4.html

补充日期: 2005-03-15 10:31:37

4．5．2 文件的顺序处理 类FileInputStream和FileOutputStream用来进行文件I/O处理，由它们所提供的方法可以打开本地主机上的文件，并进行 顺序的读/写。例如，下列的语句段是顺序读取文件名为text的文件里的内容，并显示在控制台上面，直到文件结束为止。 　　FileInputStream fis; try{ fis = new FileInputStream( "text" ); System.out.print( "content of text is : "); int b; while( (b=fis.read())!=-1 ) //顺序读取文件text里的内容并赋值 给整型变量b,直到文件结束为止。 { 　　　　　　　　　　　　　 System.out.print( (char)b ); } }catch( FileNotFoundException e ){ System.out.println( e ); }catch( IOException e ){ System.out.println( e ); } 4．5．3 随机访问文件 对于InputStream 和OutputStream 来说，它们的实例都是顺序访问流，也就是说，只能对文件进行顺序地读/写。随机访问文件则允许对文件内容进行随机读/写。在java中，类RandomAccessFile 提供了随机访问文件的方法。类RandomAccessFile的声明为： public class RandomAccessFile extends Object implements DataInput, DataOutput 　　接口DataInput 中定义的方法主要包括从流中读取基本类型的数据、读取一行数据、或者读取指定长度的字节数。如：readBoolean( )、readInt( )、readLine( )、readFully( ) 等。 接口DataOutput 中定义的方法主要是向流中写入基本类型的数据、或者写入一定长度的字节数组。如：writeChar( )、writeDouble( )、write( ) 等。 下面详细介绍RandomAccessFile类中的方法。 ◇ 构造方法： RandomAccessFile(String name,String mode); //name是文件名，mode //是打开方式，例如"r"表示只读，"rw"表示可读写，" RandomAccessFile(File file,String mode); //file是文件对象 ◇ 文件指针的操作 long getFilePointer( ); //用于得到当前的文件指针 void seek( long pos ); //用于移动文件指针到指定的位置 int skipBytes( int n ); //使文件指针向前移动指定的n个字节 4．6 过滤流 过滤流在读/写数据的同时可以对数据进行处理，它提供了同步机制，使得某一时刻只有一个线程可以访问一个I/O流，以防止多个线程同时对一个I/O流进行 操作所带来的意想不到的结果。类FilterInputStream和FilterOutputStream分别作为所有过滤输入流和输出流的父类 　过滤流类层次： 　　　　　　  java.lang.Object   |   +----java.io.InputStream   |   +----java.io.FilterInputStream 为了使用一个过滤流，必须首先把过滤流连接到某个输入/出流上，通常通过在构造方法的参数中指定所要连接的输入/出流来实现。例如： FilterInputStream( InputStream in ); FilterOutputStream( OutputStream out ); 4．6．1 几种常见的过滤流 　　◇ BufferedInputStream和BufferedOutputStream 缓冲流，用于提高输入/输出处理的效率。 ◇ DataInputStream 和 DataOutputStream 不仅能读/写数据流，而且能读/写各种的java语言的基本类型，如：boolean，int，float等。 ◇ LineNumberInputStream 除了提供对输入处理的支持外，LineNumberInputStream可以记录当前的行号。 ◇ PushbackInputStream 提供了一个方法可以把刚读过的字节退回到输入流中，以便重新再读一遍。 ◇ PrintStream 打印流的作用是把Java语言的内构类型以其字符表示形式送到相应的输出流。 4．7 字符流的处理 java中提供了处理以16位的Unicode码表示的字符流的类，即以Reader和Writer 为基类派生出的一系列类。 4．7．1 Reader和Writer 　  这两个类是抽象类，只是提供了一系列用于字符流处理的接口，不能生成这两个类的实例，只能通过使用由它们派生出来的子类对象来处理字符流。 1．Reader类是处理所有字符流输入类的父类。 ◇ 读取字符 public int read() throws IOException; //读取一个字符，返回值为读取的字符 public int read(char cbuf[]) throws IOException; /*读取一系列字符到数组cbuf[]中，返回值为实际读取的字符的数量*/ public abstract int read(char cbuf[],int off,int len) throws IOException; /*读取len个字符，从数组cbuf[]的下标off处开始存放，返回值为实际读取的字符数量，该方法必须由子类实现*/ ◇ 标记流 public boolean markSupported(); //判断当前流是否支持做标记 public void mark(int readAheadLimit) throws IOException; //给当前流作标记，最多支持readAheadLimit个字符的回溯。 public void reset() throws IOException; //将当前流重置到做标记处 ◇ 关闭流 public abstract void close() throws IOException; 2． Writer类是处理所有字符流输出类的父类。 ◇ 向输出流写入字符 public void write(int c) throws IOException； //将整型值c的低16位写入输出流 public void write(char cbuf[]) throws IOException； //将字符数组cbuf[]写入输出流 public abstract void write(char cbuf[],int off,int len) throws IOException； //将字符数组cbuf[]中的从索引为off的位置处开始的len个字符写入输出流 public void write(String str) throws IOException； //将字符串str中的字符写入输出流 public void write(String str,int off,int len) throws IOException； //将字符串str 中从索引off开始处的len个字符写入输出流 ◇ flush( ) 刷空输出流，并输出所有被缓存的字节。 ◇ 关闭流 public abstract void close() throws IOException；

补充日期: 2005-03-15 10:39:31

关于 java IO 流 ；这个也不错，只是拷贝不下来。 http://edu.cn700.com/Print.asp?ArticleID=18540

补充日期: 2005-03-15 10:45:25

4．7．2 InputStreamReader和OutputStreamWriter java.io包中用于处理字符流的最基本的类,用来在字节流和字符流之间作为中介。 　 ◇ 生成流对象 　　public InputStreamReader(InputStream in); /*in是字节流，而InputStreamReader是字符流，但是其来源是字节流in， 因此InputStreamReader就可以把字节流in转换成字符流处理。/* public InputStreamReader(InputStream in,String enc) throws UnsupportedEncodingException; /*enc是编码方式，就是从字节流到字符流进行转换时所采用的编码方式， 例如 ISO8859-1，UTF-8，UTF-16等等*/ public OutputStreamWriter(OutputStream out); /*out是字节流，而OutputStreamReader是字符流 */ public OutputStreamWriter(OutputStream out,String enc) throws UnsupportedEncodingException; //enc是编码方式 InputStreamReader和OutputStreamWriter的方法： ◇ 读入和写出字符 基本同Reader和Writer。 ◇ 获取当前编码方式 public String getEncoding(); ◇ 关闭流 public void close() throws IOException; 4．7．3 BufferedReader和BufferedWriter 　◇ 生成流对象 public BufferedReader(Reader in); //使用缺省的缓冲区大小 public BufferedReader(Reader in, int sz); //sz为缓冲区的大小 public BufferedWriter(Writer out); public BufferedWriter(Writer out, int sz); ◇ 读入/写出字符 除了Reader和Writer中提供的基本的读写方法外，增加对整行字符的处理。 public String readLine() throws IOException; //读一行字符 public void newLine() throws IOException; //写一行字符 【例4-4】 import java.io.*; public class NumberInput{ public static void main(String args[]){ try{ InputStreamReader ir; BufferedReader in; ir=new InputStreamReader(System.in); //从键盘接收了一个字符串的输入，并创建了一个字符输入流的对象 in=new BufferedReader(ir); String s=in.readLine(); //从输入流in中读入一行，并将读取的值赋值给字符串变量s System.out.println("Input value is: "+s); int i = Integer.parseInt(s);//转换成int型 i*=2; System.out.println("Input value changed after doubled: "+i); }catch(IOException e) {System.out.println(e);} } } 运行结果 D:\>java NumberInput 123 Input value is 123 Input value changed after doubled： 246 注意：在读取字符流时，如果不是来自于本地的，比如说来自于网络上某处的与本地编码方式不同的机器，那么我们在构造输入流时就不能简单地使用本地缺省的编码方式，否则读出的字符就不正确；为了正确地读出异种机上的字符，我们应该使用下述方式构造输入流对象： ir = new InputStreamReader(is, "8859_1"); 采用ISO 8859_1编码方式，这是一种映射到ASCII码的编码方式，可以在不同平台之间正确转换字符。

补充日期: 2005-03-15 10:56:05

4．8 对象的串行化(Serialization) 4．8．1 串行化的定义 　　1． 什么是串行化 对象的寿命通常随着生成该对象的程序的终止而终止。有时候，可能需要将对象的状态保存下来，在需要时再将对象恢复。我们把对象的这种能记录自己的状态 以便将来再生的能力，叫做对象的持续性(persistence)。对象通过写出描述自己状态的数值来记录自己，这个过程叫对象的串行化 (Serialization)。 　　2． 串行化的目的 串行化的目的是为java的运行环境提供一组特性，其主要任务是写出对象实例变量的数值。 4．8．2 串行化方法 在java.io包中，接口Serializable用来作为实现对象串行化的工具，只有实现了Serializable的类的对象才可以被串行化。 　1． 定义一个可串行化对象 public class Student implements Serializable{ int id; //学号 String name; //姓名 int age; //年龄 String department //系别 public Student(int id,String name,int age,String department){ this.id = id; this.name = name; this.age = age; this.department = department; } } 2． 构造对象的输入/输出流 要串行化一个对象，必须与一定的对象输入/输出流联系起来，通过对象输出流将对象状态保存下来，再通过对象输入流将对象状态恢复。 java.io包中，提供了ObjectInputStream和ObjectOutputStream将数据流功能扩展至可读写对象。在 ObjectInputStream中用readObject()方法可以直接读取一个对象，ObjectOutputStream中用 writeObject()方法可以直接将对象保存到输出流中。 Student stu=new Student(981036,"Liu Ming",18, "CSD"); FileOutputStream fo=new FileOutputStream("data.ser"); //保存对象的状态 ObjectOutputStream so=new ObjectOutputStream(fo); try{ so.writeObject(stu); so.close(); }catch(IOException e ) {System.out.println(e);} FileInputStream fi=new FileInputStream("data.ser"); ObjectInputStream si=new ObjectInputStream(fi); //恢复对象的状态 try{ stu=(Student)si.readObject(); si.close(); }catch(IOException e ) {System.out.println(e);} 在 这个例子中，我们首先定义一个类Student，实现了 Serializable接口，然后通过对象输出流的writeObject()方法将Student对象保存到文件data.ser中。之后，通过对象 输入流的readObject()方法从文件data.ser中读出保存下来的Student对象。 4．8．3 串行化的注意事项 　1．串行化能保存的元素 只能保存对象的非静态成员变量，不能保存任何的成员方法和静态的成员变量，而且串行化保存的只是变量的值，对于变量的任何修饰符，都不能保存。 2．transient关键字 对于某些类型的对象，其状态是瞬时的，这样的对象是无法保存其状态的，例如一个Thread对象，或一个FileInputStream对象，对于这些字段，我们必须用transient关键字标明 3． 定制串行化 缺省的串行化机制，对象串行化首先写入类数据和类字段的信息，然后按照名称的上升排列顺序写入其数值。如果想自己明确地控制这些数值的写入顺序和写入 种类，必须定义自己的读取数据流的方式。就是在类的定义中重写writeObject()和readObject()方法。 例如可在4.8.2的例子中，加入重写的writeObject()和readObject()方法，对Student 类定制其串行化。 private void writeObject(ObjectOutputStream out)throws IOException { out.writeInt(id); out.writeInt(age); out.writeUTF(name); out.writeUTF(department); } private void readObject(ObjectInputStream in)throws IOException { id=in.readInt(); age=in.readInt(); name=in.readUTF(); department=in.readUTF(); }

补充日期: 2005-03-15 11:14:20

4．9 其它常用的流 4．9．1 管道流 　　管道用来把一个程序、线程或代码块的输出连接到另一个程序、线程或代码块的输入 。 管道输入流作为一个通信管道的接收端，管道输出流作为发送端。在使用管道之前，管道输出流和管道输入流必须进行连接。下面有两种连接的方法： 1． 构造方法中连接 PipedInputStream(PipedOutputStream src); PipedOutputStream(PipedInputStream snk); 2． connect()方法进行连接 类PipedInputStream中定义为： void connect(PipedOutputStream src); 类PipedOutputStream中定义为： void connect(PipedInputStream snk); 4．9．2 内存的读/写 　1． ByteArrayInputStream和ByteArrayOutputStream ByteArrayInputStream //从字节数组中读取以字节为单位的数据 ByteArrayOutputStream //向字节数组中写入以字节为单位的数据 2． StringBufferInputStream和StringBufferOutputStream StringBufferInputStream //从字符串缓冲区StringBuffer中读取以字符为单位的数据 StringBufferOutputStream //向字符串缓冲区StringBuffer中写入以字符为单位的数据 4．9．3 顺序输入流 　　SequenceInputStream 把几个输入流顺序连接起来。顺序输入流提供了把若干不同的流统一为同一个流的功能，使得程序变得更加简洁。 【本讲小结】 　　例外处理是java语言中一个独特之处，主要使用捕获例外和声明抛弃例外两种方法来处理程序中可能出现例外的语句块，其中捕获例外的方法是一种积极地处理例外的方法，而声明抛弃例外是一种消极的处理例外的方法。 Java中的输入／输出处理是通过使用流技术，用统一的接口表示而实现的。输入／输出流中，最常见的是对文件的处理。Java语言中提供专门处理文件 和目录的类，例如：java.io.File，java.io.FileInputStream，java.io.FileOutputStream， java.io.RandomAccessFile和接口java.io.FilenameFilter。输入／输出流根据处理的内容，分为字符流和字节 流两种，其中字节流是以byte为基本处理单位的流；而字符流是以16位的Unicode码为处理单位的流。

补充日期: 2005-03-30 09:56:05

java文件操作,再看

http://www.tiantiansoft.com/Article_Show.asp?ArticleID=163

Dennis M. Sosnoski
总裁, Sosnoski Software Solutions, Inc.
2001 年 9 月

在本文中，Java 顾问 Dennis Sosnoski 比较几个 Java 文档模型的性能和功能。当选择模型时，无法做到每次都权衡得很清楚，如果以后改变主意，则需要大量编码来进行切换。作者将性能结果放入特性集合的上下文中 并遵循标准，对所要求的正确选择给出了一些建议。本文包含用于这组测试的几张图表和源代码。

使用内存中 XML 文档的 Java 开发者可以选择使用标准 DOM 表示或几个 Java 特定模型中的任何一个。该灵活性已经帮助将 Java 建立成 XML 工作的出色平台。但是，由于不同模型数量的增加，已经更加难以确定如何比较模型的功能、性能和易用性。

关于使用“Java 中的 XML”系列中的第一篇文章研究了 Java 中一些领先的 XML 文档模型的特性和性能。它包括一组性能测试的结果(带有可下载的测试代码，请参阅 参考资料）。在系列中的第二篇文章将通过比较为实现同样任务所使用的不同模型的样本代码来研究易用性问题。

文档模型
Java 中的可用文档模型数一直在增加。对于本文，我已经涵盖了最常用的模型和几项选择，这演示了那些可能还未被广泛了解或使用的特别令人感兴趣的特性。随着“XML 名称空间”的重要性增加，我已经包含了仅支持该功能的模型。下面列出了带有简要介绍和版本信息的模型。

仅为说明本文中所使用的术语：

• 解析器是指解释 XML 文本文档结构的程序
• 文档表示是指程序用于内存中文档的数据结构
• 文档模型是指支持使用文档表示的库和 API

某些 XML 应用程序根本不需要使用文档模型。如果应用程序可以通过文档的一次遍历搜集它需要的信息，则可能直接使用解析器。该方法可能需要增加一些工作量，但是它的性能总是优于在内存中构建文档表示。

DOM
DOM（“文档对象模型”）是用与平台和语言无关的方式表示 XML 文档的官方 W3C 标准。对于任何 Java 特定的模型，它是很好的对照。为了值得与 DOM 标准分开，Java 特定模型应该提供比 Java DOM 实现更优越的性能和／或易用性的优势。

DOM 定义充分利用了 XML 文档不同组件的接口和继承性。这为开发者带来了将公共接口用于几个不同类型组件的优势，但是同时增加了 API 的复杂性。因为 DOM 是与语言无关的，所以接口不需要利用公共 Java 组件，例如，Collections 类。

本文涉及两个 DOM 实现：Crimson 和 Xerces Java。Crimson 是基于 Sun Project X 解析器的 Apache 项目。它合并一个包含 DTD 支持的完整验证解析器。可以通过 SAX2 接口访问该解析器，并且 DOM 实现可以与其它 SAX2 解析器一起工作。Crimson 是在 Apache 许可证下发布的开放源码。用于性能比较的版本是 Crimson 1.1.1（jar 文件大小是 0.2MB），它包含有用于从文本文件的 DOM 构建的 SAX2 解析器。

另一个测试的 DOM 实现，即 Xerces Java 是另一个 Apache 项目。初始时，Xerces 基于 IBM Java 解析器（通常称为 XML4J）。（当前还处于早期 beta 测试版的重新开发的 Xerces Java 2 将最终继承它。当前版本有时称为 Xerces Java 1。）如同使用 Crimson 一样，可以通过 SAX2 接口和 DOM 来访问 Xerces 解析器。然而，Xerces 不提供将 Xerces DOM 与不同的 SAX2 解析器一起使用的任何方法。Xerces Java 包含对 DTD 和 XML Schema 的验证支持（仅带有对 Schema 支持的最小限制）。

Xerces Java 还支持 DOM 的延迟节点扩展方式（请参考本文中的 延迟 Xerces或 Xerces def.）， 其中文档组件初始时是以压缩格式表示的，仅当使用时才将它扩展成完整的 DOM 表示。这种方式的用意是允许更快的解析并降低内存的使用，尤其对于那些可能仅使用部分输入文档的应用程序。与 Crimson 类似，Xerces 是在 Apache 许可证下发布的开放源码。用于性能比较的版本是 Xerces 1.4.2（jar 文件大小是 1.8MB）。

JDOM
JDOM 的目的是成为 Java 特定文档模型，它简化与 XML 的交互并且比使用 DOM 实现更快。由于是第一个 Java 特定模型，JDOM 一直得到大力推广和促进。正在考虑通过“Java 规范请求 JSR-102”将它最终用作“Java 标准扩展”。虽然实际将采用的格式仍在开发中，还是对两个 beta 测试版的 JDOM API 做了很大的更改，。从 2000 年初就已经开始了 JDOM 开发。

JDOM 与 DOM 主要有两方面不同。首先，JDOM 仅使用具体类而不使用接口。这在某些方面简化了 API，但是也限制了灵活性。第二，API 大量使用了 Collections 类，简化了那些已经熟悉这些类的 Java 开发者的使用。

JDOM 文档声明其目的是“使用 20%（或更少）的精力解决 80%（或更多）Java/XML 问题”（根据学习曲线假定为 20%）。JDOM 对于大多数 Java/XML 应用程序来说当然是有用的，并且大多数开发者发现 API 比 DOM 容易理解得多。JDOM 还包括对程序行为的相当广泛检查以防止用户做任何在 XML 中无意义的事。然而，它仍需要您充分理解 XML 以便做一些超出基本的工作（或者甚至理解某些情况下的错误）。这也许是比学习 DOM 或 JDOM 接口都更有意义的工作。

JDOM 自身不包含解析器。它通常使用 SAX2 解析器来解析和验证输入 XML 文档（尽管它还可以将以前构造的 DOM 表示作为输入）。它包含一些转换器以将 JDOM 表示输出成 SAX2 事件流、DOM 模型或 XML 文本文档。JDOM 是在 Apache 许可证变体下发布的开放源码。用于性能比较的版本是 JDOM Beta 0.7（jar 文件大小是 0.1MB）它带有用于从文本文件构建 JDOM 表示的 Crimson SAX2 解析器。

dom4j
虽然 dom4j 代表了完全独立的开发结果，但最初，它是 JDOM 的一种智能分支。它合并了许多超出基本 XML 文档表示的功能，包括集成的 XPath 支持、XML Schema 支持（当前为 alpha 格式）以及用于大文档或流化文档的基于事件的处理。它还提供了构建文档表示的选项，它通过 dom4j API 和标准 DOM 接口具有并行访问功能。从 2000 下半年开始，它就一直处于开发之中，保留了最近发行版之间的现有 API。

为支持所有这些功能，dom4j 使用接口和抽象基本类方法。dom4j 大量使用了 API 中的 Collections 类，但是在许多情况下，它还提供一些替代方法以允许更好的性能或更直接的编码方法。直接好处是，虽然 dom4j 付出了更复杂的 API 的代价，但是它提供了比 JDOM 大得多的灵活性。

在添加灵活性、XPath 集成和对大文档处理的目标时，dom4j 的目标与 JDOM 是一样的：针对 Java 开发者的易用性和直观操作。它还致力于成为比 JDOM 更完整的解决方案，实现在本质上处理所有 Java/XML 问题的目标。在完成该目标时，它比 JDOM 更少强调防止不正确的应用程序行为。

dom4j 使用相同方法作为 JDOM 输出，这依靠 SAX2 解析器输入处理，依靠转换器将输出处理成 SAX2 事件流、DOM 模型或 XML 文本文档。dom4j 是在 BSD 样式许可证下发布的开放源码，该许可证本质上等价于 Apache 样式许可证。用于性能比较的版本是 dom4j 0.9（jar 文件大小是 0.4MB），带有用于从文本文件构建表示的受绑定 AElfred SAX2 解析器（由于 SAX2 选项设置，测试文件之一无法由 dom4j 使用用于 JDOM 测试的同一 Crimson SAX2 解析器来处理）。

Electric XML
Electric XML（EXML）是支持分布式计算的商业项目的附属产物。它与目前为止讨论的其它模型的不同之处在于，它只能适当地支持 XML 文档的子集，它没有为验证提供任何支持并且有更严格的许可证。然而，EXML 的优势是大小很小并提供了对 XPath 子集的直接支持，因为在最近几篇文章中已经将它提升其它模型的替代模型，所以通过该比较使它成为一个引人注意的候选。

虽然 EXML 通过使用抽象的基本类方法取得了某些相同效果，但它在避免使用接口方面使用与 JDOM 类似的方法（主要区别是接口为扩展实现提供了更大的灵活性）。它与 JDOM 的不同之处还在于避免使用 Collections 类。该组合为其提供了非常简单的 API，在许多方面类似于带有附加 XPath 操作的 DOM API 简化版本。

仅当 空白与非空白文本内容邻近时，EXML 才在文档中保留空白，这就将 EXML 限制成 XML 文档的一个子集。标准 XML 需要在读取文档时保留该空白，除非对文档 DTD 可以确认有无空白无关紧要。对于事先已经知道空白无关紧要的许多 XML 应用程序来说，EXML 方法工作得很好，但是它防止对于期望保留空白的文档（例如，生成由浏览器显示或查看的文档的应用程序）使用 EXML。（有关作者对于该主题的谦虚建议，请参阅副栏 使用空白的目的。）

这种空白的删除会对性能比较产生误导效果 ― 许多类型的测试范围与文档中的组件个数成比例，并且由 EXML 删除的每个空白序列都是其它模型中的组件。EXML 包含在本文显示的结果中，但是解释性能差异时请记住这种影响。

EXML 使用集成的解析器依据文本文档构建文档表示。除了通过文本方式外，它不提供从 DOM（或 SAX2）转换或转换成 SAX2（或 DOM）事件流的任何方式。EXML 是由 Mind Electric 在禁止将它嵌入某些类型的应用程序或库的受限许可证下发布的开放源码。用于性能比较的版本是 Electric XML 2.2（jar 文件大小是 0.05MB）。

XML Pull Parser
XML Pull Parser (XPP）是最近开发的，它演示了 XML 解析的不同方法。与 EXML 一样，XPP 只能适当支持 XML 文档的子集并且不提供验证的任何支持。它同样具有尺寸小的优势。这种优势再与拉回解析器方法结合，使它成为该比较中的良好替换项。

XPP 几乎独占地使用接口，但是它仅使用所有类中的一小部分。和 EXML 一样，XPP 避免使用 API 中的 Collections 类。总的来说，它是本文中最简单的文档模型 API。

将 XPP 限制成 XML 文档子集的局限性是它不支持文档中的实体、注释或处理指示信息。XPP 创建仅包含元素、属性（包括“名称空间”）和内容文本的文档结构。这对于某些类型的应用程序来说是一种非常严格的限制。但是通常它对性能的影响比 EXML 空白处理对性能的影响小。在本文中我仅使用了一个与 XPP 不兼容的测试文件，并且在带有注释的图表中显示了 XPP 结果，该注释不包含该文件。

XPP 中的拉回解析器支持（本文中称为 XPP 拉回） 通过将解析实际上推迟到访问文档的一个组件时才进行，然后按照构造那个组件的需要对文档进行解析。该技术想实现允许非常快速的文档显示或分类应用，尤其在 需要转发或除去（而不是对文档进行完全解析和处理）文档时。该方法的使用是可选的，如果以非拉回型方式使用 XPP，它对整个文档进行解析并且同时地构建完整的表示。

与 EXML 一样，XPP 使用依据文本文档构建文档表示的集成语法解析器，并且除了通过文本方式外，它不提供从 DOM（或 SAX2）转换或转换成 SAX2（或 DOM）事件流的任何方式。XPP 是具有 Apache 样式许可证的开放源代码。用于性能比较的版本是 PullParser 2.0.1 Beta 8（jar 文件大小是 0.04MB）。

测试详细信息 所显示的计时结果是来自使用 Sun Microsystems Java version 1.3.1、Java HotSpot Client VM 1.3.1-b24 测试，这些软件是运行在带有 256MB RAM 的 Athlon 1GHz 系统上的 Redhat Linux 7.1 下。将这些测试的初始 JVM 和最大内存大小都设置成 128MB，我想将它表示为服务器类型执行环境。 在使用初始缺省 JVM 内存设置为 2MB 和最大内存为 64MB 运行的测试中，带有较大 jar 文件大小（DOM、JDOM 和 dom4j）的模型的结果非常差，尤其在运行测试的平均时间中。这可能是由于内存受限执行的 HotSpot JVM 的无效操作引起的。 文档模型中的两种（XPP 和 EXML）支持直接将文档输入成“字符串”或字符数组。该类型直接输入不能代表实际应用程序，因此我在这些测试中避免使用它。对于输入和输出，我使用 Java 流封装字节以消除 I/O 对性能的影响，而保留了用于 XML 文档输入和输出的应用程序在典型情况下使用的语言接口。

性能比较
本文中使用的性能比较基于对一组选中的 XML 文档进行的解析和使用，这些文档试图代表较大范围的应用程序：

• much_ado.xml，标记成 XML 的莎士比亚戏剧。没有属性并且是相当简单的结构（202K 字节）。
• periodic.xml, XML 中的元素的周期表。一些属性，也是相当简单的（117K 字节）。
• soap1.xml，取自规范的样本 SOAP 文档。大量名称空间和属性（0.4K 字节，每次测试需要重复 49 次）。
• soap2.xml，SOAP 文档格式中的值列表。大量名称空间和属性（134K 字节）。
• nt.xml，标记为 XML 的“新约”。没有属性并且非常简单的结构，大量文本内容（1047K 字节）。
• xml.xml，XML 规范，不带 DTD 引用，在内部定义所有实体。带有大量混合内容的文本样式标记，一些属性（160K 字节）。

关于测试平台的更多信息，请参阅副栏 测试详细信息并查看 参考资料以获取用于测试的源代码的链接。

除了非常小的 soap1.xml 文档之外，所有评测时间都是指文档的每次特定测试所经历的时间。在 soap1.xml 的情况下，评测的时间是 49 个连续的文档测试（总数为 20K 字节文本的足够副本数）。

测试框架在一个文档上运行一个特定的测试多次（这里显示运行了 10 次），依此跟踪该测试的最短时间和平均时间，然后继续同一文档上的下一个测试。完成对一个文档的全部测试序列后，它对下一个文档重复该过程。为防止文档模 型之间的交互，在执行每个测试框架时仅测试一个模型。

HotSpot 以及类似于动态优化 JVM 的计时基准程序是出了名的棘手的；测试序列中的小变化经常导致计时结果发生很大变化。我已经发现对于执行特定代码段的平均时间时，确实如此；最短时间比较 一致，正是我在这些结果中列出的值。可以参阅第一次测试（文档构建时间）的 平均和最短时间的比较。

文档构建时间
文档构建时间测试检 查解析文本文档和构造文档表示所需的时间。出于比较目的，已经在图表中包含了使用 Crimson 和 Xerces SAX2 解析的 SAX2 解析时间，因为大多数文档模型（除了 EXML 和 XPP 外的所有文档）使用 SAX2 解析事件流作为文档构建过程的输入。图 1 描述了测试结果。

图 1. 文档构建时间

对于大多数测试文档来说，XPP 拉回的构建时间太短以至于难以计算（因为在这种情况下，实际上没有对该文档进行解析），只显示为非常短的 soap1.xml。对于该文件，拉回解析器内存大小和相关的创建开销使 XPP 显得相对比较缓慢。这是因为测试程序为正在进行解析的文档的每个副本创建一个新的拉回解析器副本。在 soap1.xml 情况下，每次评测时间使用 49 个副本。分配与初始化这些解析器实例的开销大于重复解析文本并构建文档表示的大多数其它方法所需的时间。

XPP 的作者在一个电子邮件的讨论中指出，在实际应用程序中，可以合用拉回解析器实例以重新使用。如果这样做的话，soap1.xml 文件的开销将明显降到忽略不计程度。对于更大的文件，甚至不需要合用，拉回解析器创建开销也可以变得忽略不计。

在本测试中，XPP（带有完整解析），带有延迟节点创建的 Xerces 和 dom4j 都显示整体上的同等性能。延迟的 Xerces 对于较大的文档尤其出色，但是对于较小的文档的开销较高 ― 甚至比常规 Xerces DOM 高很多。在第一次使用文档的一部分时，延迟节点创建方法的开销也较高，这会降低快速解析的优势。

对于较小的 soap1.xml 文件，所有格式（SAX2 解析、常规 DOM 和延迟 DOM）的 Xerces 的显得开销较高。对于该文件 XPP（完全解析）尤其出色，对于 soap1.xml，EXML 甚至超过基于 SAX2 的模型。虽然 EXML 具有废弃单独的空白内容的优势，但是总体上，它是本测试中最差的。

文档遍历时间
文档遍历时间测试检 查遍历构造的文档表示所需的时间，按文档顺序遍历每个元素、属性和文本内容段。它试图表示文档模型接口的性能，这对于从进行过解析的文档中重复访问信息的 应用程序来说可能很重要。总体上，遍历时间比解析时间快得多。对于只对解析过的文档单次遍历的应用程序，解析时间将比遍历时间更重要。图 2 显示了结果。

图 2. 文档遍历时间

在本测试中，XPP 的性能大大超过了其余的测试对象。Xerces DOM 所花费的时间大约是 XPP 的两倍。虽然 EXML 具有废弃文档中单独的空白内容的优势，但是，EXML 花费的时间几乎是 XPP 的三倍。dom4j 在这张图中处于中间位置。

使用 XPP 拉回时，直到访问文档表示时才真正发生对文档文本的解析。这导致第一次遍历文档表示时的开销非常大（表中未显示）。如果以后访问整个文档表示，则当使用拉 回解析方法时，XPP 显示性能的净损失。对于拉回解析器来说，前两个测试所需的总时间比使用 XPP 的常规解析长（长 20% 到 100%，这取决于文档）。但是，当还未完全访问正在进行解析的文档时，拉回解析器方法仍然具有可观的性能优势。

带有延迟节点创建的 Xerces 显示了相似的行为，第一次访问文档表示时导致性能下降（图中未显示）。但是，在 Xerces 情况下，节点创建开销大约与解析期间常规 DOM 创建的性能差值相同。对于较大的文档来说，用 Xerces 延迟的前两次测试所需的总时间大致与使用带常规 DOM 构建的 Xerces 所用的时间相同。如果在非常大的文档（可能 10KB 或更大）上使用 Xerces，则延迟的节点创建似乎是一个好选择。

文档修改时间
这个测试检查系统地修改构造文档表示所需的时间，其结果在 图 3中 显示。它遍历表示，删除所有单独的空白内容并且用新添加的元素封装每个非空白内容字符串。它还向包含非空白内容的原始文档的每个元素中添加一个属性。该测 试试图表示经过一定范围文档修改后文档模型的性能。如遍历时间一样，修改时间比解析时间短很多。因此，对于仅单次遍历每个解析过的文档的应用程序来说，解 析时间将更重要。

图 3. 文档修改时间

这次测试中 EXML 处于领先地位，但是由于在解析期间它总是废弃单独的空白内容，它才比其它模型具有性能上的优势。这意味着在测试期间没有要从 EXML 表示中进行删除的内容。

在修改性能方面，XPP 仅次于 EXML，并且与 EXML 不同，XPP 测试包含删除。Xerces DOM 和 dom4j 接近地处于中间位置，JDOM 和 Crimson DOM 模型的性能仍是最差。

文档生成时间
这个测试检查将文档表示输出成文本 XML 文档所需的时间；结果显示在 图 4中。对于不专门使用 XML 文档的任何应用程序，该步骤似乎是整体性能的一个重要部分，特别是因为将文档输出为文本所需的时间总体接近于对文档输入进行解析所需的时间。为使这些时间具有直接的可比性，该测试使用原始文档，而没有使用由前面的测试所生成的已修改文档。

图 4. 文本生成时间

文本生成时间测试表明各模型之间的差别小于前面测试中各项的差别，Xerces DOM 性能最好，但领先不多，JDOM 性能最差。EXML 的性能优于 JDOM，但是这同样是由于 EXML 废弃空白内容。

许多模型提供了控制文本输出格式的选项，并且一些选项似乎影响文本生成时间。这个测试只使用每个模型的最基本的输出格式，因此结果只显示缺省性能而不显示最好的可能性能。

文档内存大小
这个测试检查用于文档表示的内存空间。这对于使用大文档或同时使用多个较小文档的开发者来说，意义尤为重要。图 5 显示这个测试的结果。

图 5. 文档内存大小

内存大小结果与计时测试不同，因为小的 soap1.xml 文件显示的值表示文件的单个副本而不表示在计时评测中使用的 49 个副本。在大多数模型中，用于简要文档的内存太小以至于无法在图的刻度上显示。

除了 XPP 拉回（直到访问它时才真正构建文档表示）之外，与一些计时测试中显示的差别相比，内存大小测试中模型之间的差别相对较小。延迟的 Xerces 具有最紧凑的表示（当第一次访问表示时将它扩展成基本 Xerces 大小），紧接着是 dom4j。虽然 EXML 废弃包含在其它模型中的空白内容，但是它仍具有最不紧凑的表示。

因为即使最紧凑的模型也要占用大约原始文档文本大小（以字节计）四倍的空间，所以对于大文档来说，所有模型似乎都需要太多的内存。通过提供使用部分 文档表示的方法，XPP 拉回和 dom4j 为非常大的文档提供了最好的支持。XPP 拉回通过仅构建实际被访问的表示部分完成该任务，而 dom4j 包含对基于事件处理的支持，使得一次只构建或处理文档的一部分。

Java 序列化
这些测试评测文 档表示的 Java 序列化的时间和输出大小。这主要涉及那些使用 Java RMI（“远程方法调用”）在 Java 程序之间传送表示的应用程序（包括 EJB (Enterprise JavaBean) 应用程序）起作用。在这些测试中，仅包含了那些支持 Java 序列化的模型。下列三张图显示了该测试的结果。

图 6. 序列化输出时间

图 7. 序列化输入时间

图 8. 序列化文档大小

dom4j 显示了输出（生成序列化的格式）和输入（从序列化的格式重新构建文档）的最好的序列化性能，而 Xerces DOM 显示了最差的性能。EXML 所花费的时间接近 dom4j，但是 EXML 还是具有在表示中使用较少数量对象的优势，因为它废弃空白内容。

如果将文档输出成文本然后进行解析以重新构建文档，而不是使用 Java 序列化，则所有性能 ― 时间和大小 ― 都会好得多。这里的问题是作为大量唯一的小对象的 XML 文档表示的结构。Java 序列化无法有效处理这种类型的结构，这导致时间和输出大小的开销都很高。

可以设计比文本表示小且比文本输入和输出快的文档序列化格式，但是只能通过绕过 Java 序列化来完成。（我有一个项目实现 XML 文档的这种定制的序列化，在我公司的 Web 站点上可以找到其开放源码，请参阅 参考资料。）

结束语
不同的 Java XML 文档模型各有所长，但是从性能观点来看，有些模型具有明显的优势。

在大多数方面，XPP 性能处于领先地位。尽管 XPP 是一种新模型，但是对于不需要验证、实体、处理指示信息或注释的中间件类型应用程序来说，它是非常好的选择。它尤其适用于作为浏览器小应用程序或在内存受限的环境下运行的应用程序。

虽然 dom4j 没有与 XPP 同等的速度，但是，它确实提供了具备更标准化的优越性能和功能更全的实现，包括对 SAX2、DOM 甚至 XPath 的内置支持。虽然 Xerces DOM（带有延迟的节点创建）对于小文件和 Java 序列化性能不佳，但是在大多数评测时仍然出色。对于常规 XML 处理，dom4j 和 Xerces DOM 都是很好的选择，对它们的选择取决于您认为是特定于 Java 的特性更重要还是跨语言的兼容性更重要。

JDOM 和 Crimson DOM 在性能测试时一直表现不佳。在小文档情况下还值得考虑使用 Crimson DOM，而 Xerces 表现很差。虽然 JDOM 的开发者已经说明他们期望在正式发行版前专注性能问题，但是从性能观点来看，它确实没有值得推荐之处。然而，如果不进行 API 的重新构建，JDOM 可能难以达到与其它模型匹配的性能。

使用空白的目的 XML 规范通常需要保留空白，但是许多 XML 应用程序使用仅为可读性而保留空白的格式。对于这些应用程序，EXML 废弃隔离空白的方法起了作用。 这些性能中使用的大多数文档属于“为可读性而保留的空白”类别。这些文档被格式化成便于人们查看的形式，一行最多一个元素。结果，无关的空白内容字符串数实际上超过了文档中的元素数量。这大大增加了每一步处理的不必要开销。 支持修剪输入上这种类型空白的选项将有助于提高带有可忽略的空白的应用程序的所有文档模型的性能（除了 EXML 之外）。只要修剪是一个选项，它就不会影响需要完全保留空白的应用程序。解析器级别的支持将更好，因为解析器必须逐一处理输入字符。总之，这种类型的选项 将非常有助于许多 XML 应用程序。

EXML 非常小（以 jar 文件大小为单位）并且在一些性能测试中表现良好。虽然 EXML 具有删除单独空白内容的优势，但是在性能方面不如 XPP。除非您需要 EXML 支持而 XPP 缺少的一种特性，否则在内存受限的环境下，XPP 可能是更好的选择。

虽然 dom4j 性能最好，但是，当前没有一种模型能为 Java 序列化提供良好性能。如果需要在程序之间传递文档，通常的最佳选择是将文档写成文本然后进行解析以重新构建表示。将来，定制序列化格式可能提供一个更好的选择。

后续内容...
我已经涵盖了一些文档模型的基本特性，并且显示了几种类型文档操作的性能评测。请记住，虽然，性能只是选择文档模型的一个因素。对于大多数开发者，可用性至少与性能一样重要，并且这些模型使用不同的 API 都可能有喜欢这个而不喜欢那个的理由。

在后续文章中将集中研究可用性，其中我将比较用于完成这些不同模型中相同操作的样本代码。请检查本比较的第二部分。当您等待时，可以通过下面的论坛中的链接提出您对本文的评论和问题与大家共享。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 参加关于本文的 论坛。
  
  
• 如果您需要背景知识，请尝试 developerWorks的教程 XML Java 编程、 理解 SAX和 理解 DOM。
  
  
• 从 下载页面下载用于本文的测试程序和文档模型库。
  
  
• 在测试程序的 主页上查看更新的测试和测试结果。
  
  
• 获取作者关于 XML Serial (XMLS) encoding工作的详细信息作为 Java 序列化的替代项。
  
  
• 研究或下载本文中讨论的 Java XML 文档模型：
  • Xerces Java
  • Crimson
  • JDOM
  • dom4j
  • Electric XML（EXML）
  • XML Pull Parser（XPP）
  
  
• IBM WebSphere Application Server 包含基于 Xerces Java 的 XML4J 解析器。可在 WAS Advanced edition 3.0 online documentation中找到关于产品 XML 支持的 how-to 信息。
  

Java 理论与实践: 用弱引用堵住内存泄漏

弱引用使得表达对象生命周期关系变得容易了

文档选项 未显示需要 JavaScript 的文档选项 将此页作为电子邮件发送 讨论

级别： 中级

Brian Goetz (brian@quiotix.com), 首席顾问, Quiotix

2005 年 12 月 19 日

虽 然用 Java™ 语言编写的程序在理论上是不会出现“内存泄漏”的，但是有时对象在不再作为程序的逻辑状态的一部分之后仍然不被垃圾收集。本月，负责保障应用程序健康的工 程师 Brian Goetz 探讨了无意识的对象保留的常见原因，并展示了如何用弱引用堵住泄漏。

要让垃圾收集（GC）回收程序不再使用的对象，对象的逻辑 生命周期（应用程序使用它的时间）和对该对象拥有的引用的实际 生命周期必须是相同的。在大多数时候，好的软件工程技术保证这是自动实现的，不用我们对对象生命周期问题花费过多心思。但是偶尔我们会创建一个引用，它在内存中包含对象的时间比我们预期的要长得多，这种情况称为无意识的对象保留（unintentional object retention）。

全局 Map 造成的内存泄漏

无意识对象保留最常见的原因是使用 Map 将元数据与临时对象（transient object）相关联。假定一个对象具有中等生命周期，比分配它的那个方法调用的生命周期长，但是比应用程序的生命周期短，如客户机的套接字连接。需要将一些元数据与这个套接字关联，如生成连接的用户的标识。在创建 Socket 时是不知道这些信息的，并且不能将数据添加到 Socket 对象上，因为不能控制 Socket 类或者它的子类。这时，典型的方法就是在一个全局 Map 中存储这些信息，如清单 1 中的 SocketManager 类所示：

public class SocketManager {
    private Map<Socket,User> m = new HashMap<Socket,User>();
    
    public void setUser(Socket s, User u) {
        m.put(s, u);
    }
    public User getUser(Socket s) {
        return m.get(s);
    }
    public void removeUser(Socket s) {
        m.remove(s);
    }
}
SocketManager socketManager;
...
socketManager.setUser(socket, user);

这种方法的问题是元数据的生命周期需要与套接字的生命周期挂钩，但是除非准确地知道什么时候程序不再需要这个套接字，并记住从 Map 中删除相应的映射，否则，Socket 和 User 对象将会永远留在 Map 中，远远超过响应了请求和关闭套接字的时间。这会阻止 Socket 和 User 对象被垃圾收集，即使应用程序不会再使用它们。这些对象留下来不受控制，很容易造成程序在长时间运行后内存爆满。除了最简单的情况，在几乎所有情况下找出什么时候 Socket 不再被程序使用是一件很烦人和容易出错的任务，需要人工对内存进行管理。

回页首

找出内存泄漏

程序有内存泄漏的第一个迹象通常是它抛出一个 OutOfMemoryError，或者因为频繁的垃圾收集而表现出糟糕的性能。幸运的是，垃圾收集可以提供能够用来诊断内存泄漏的大量信息。如果以 -verbose:gc 或者 -Xloggc 选项调用 JVM，那么每次 GC 运行时在控制台上或者日志文件中会打印出一个诊断信息，包括它所花费的时间、当前堆使用情况以及恢复了多少内存。记录 GC 使用情况并不具有干扰性，因此如果需要分析内存问题或者调优垃圾收集器，在生产环境中默认启用 GC 日志是值得的。

有工具可以利用 GC 日志输出并以图形方式将它显示出来，JTune 就是这样的一种工具（请参阅 参考资料）。观察 GC 之后堆大小的图，可以看到程序内存使用的趋势。对于大多数程序来说，可以将内存使用分为两部分：baseline 使用和 current load 使用。对于服务器应用程序，baseline 使用就是应用程序在没有任何负荷、但是已经准备好接受请求时的内存使用，current load 使用是在处理请求过程中使用的、但是在请求处理完成后会释放的内存。只要负荷大体上是恒定的，应用程序通常会很快达到一个稳定的内存使用水平。如果在应用 程序已经完成了其初始化并且负荷没有增加的情况下，内存使用持续增加，那么程序就可能在处理前面的请求时保留了生成的对象。

清单 2 展示了一个有内存泄漏的程序。MapLeaker 在线程池中处理任务，并在一个 Map 中记录每一项任务的状态。不幸的是，在任务完成后它不会删除那一项，因此状态项和任务对象（以及它们的内部状态）会不断地积累。

public class MapLeaker {
    public ExecutorService exec = Executors.newFixedThreadPool(5);
    public Map<Task, TaskStatus> taskStatus 
        = Collections.synchronizedMap(new HashMap<Task, TaskStatus>());
    private Random random = new Random();
    private enum TaskStatus { NOT_STARTED, STARTED, FINISHED };
    private class Task implements Runnable {
        private int[] numbers = new int[random.nextInt(200)];
        public void run() {
            int[] temp = new int[random.nextInt(10000)];
            taskStatus.put(this, TaskStatus.STARTED);
            doSomeWork();
            taskStatus.put(this, TaskStatus.FINISHED);
        }
    }
    public Task newTask() {
        Task t = new Task();
        taskStatus.put(t, TaskStatus.NOT_STARTED);
        exec.execute(t);
        return t;
    }
}

图 1 显示 MapLeaker GC 之后应用程序堆大小随着时间的变化图。上升趋势是存在内存泄漏的警示信号。（在真实的应用程序中，坡度不会这么大，但是在收集了足够长时间的 GC 数据后，上升趋势通常会表现得很明显。）

确信有了内存泄漏后，下一步就是找出哪种对象造成了这个问题。所有内存分析器都可以生成按照对象类进行分解的堆快照。有一些很好的商业堆分析工具，但是找出内存泄漏不一定要花钱买这些工具 —— 内置的 hprof 工具也可完成这项工作。要使用 hprof 并让它跟踪内存使用，需要以 -Xrunhprof:heap=sites 选项调用 JVM。

清单 3 显示分解了应用程序内存使用的 hprof 输出的相关部分。（hprof 工具在应用程序退出时，或者用 kill -3 或在 Windows 中按 Ctrl+Break 时生成使用分解。）注意两次快照相比，Map.Entry、Task 和 int[] 对象有了显著增加。

请参阅 清单 3。

清单 4 展示了 hprof 输出的另一部分，给出了 Map.Entry 对象的分配点的调用堆栈信息。这个输出告诉我们哪些调用链生成了 Map.Entry 对象，并带有一些程序分析，找出内存泄漏来源一般来说是相当容易的。

TRACE 300446:
	java.util.HashMap$Entry.<init>(<Unknown Source>:Unknown line)
	java.util.HashMap.addEntry(<Unknown Source>:Unknown line)
	java.util.HashMap.put(<Unknown Source>:Unknown line)
	java.util.Collections$SynchronizedMap.put(<Unknown Source>:Unknown line)
	com.quiotix.dummy.MapLeaker.newTask(MapLeaker.java:48)
	com.quiotix.dummy.MapLeaker.main(MapLeaker.java:64)

回页首

弱引用来救援了

SocketManager 的问题是 Socket-User 映射的生命周期应当与 Socket 的生命周期相匹配，但是语言没有提供任何容易的方法实施这项规则。这使得程序不得不使用人工内存管理的老技术。幸运的是，从 JDK 1.2 开始，垃圾收集器提供了一种声明这种对象生命周期依赖性的方法，这样垃圾收集器就可以帮助我们防止这种内存泄漏 —— 利用弱引用。

弱引用是对一个对象（称为 referent）的引用的持有者。使用弱引用后，可以维持对 referent 的引用，而不会阻止它被垃圾收集。当垃圾收集器跟踪堆的时候，如果对一个对象的引用只有弱引用，那么这个 referent 就会成为垃圾收集的候选对象，就像没有任何剩余的引用一样，而且所有剩余的弱引用都被清除。（只有弱引用的对象称为弱可及（weakly reachable）。）

WeakReference 的 referent 是在构造时设置的，在没有被清除之前，可以用 get() 获取它的值。如果弱引用被清除了（不管是 referent 已经被垃圾收集了，还是有人调用了 WeakReference.clear()），get() 会返回 null。相应地，在使用其结果之前，应当总是检查 get() 是否返回一个非 null 值，因为 referent 最终总是会被垃圾收集的。

用一个普通的（强）引用拷贝一个对象引用时，限制 referent 的生命周期至少与被拷贝的引用的生命周期一样长。如果不小心，那么它可能就与程序的生命周期一样 —— 如果将一个对象放入一个全局集合中的话。另一方面，在创建对一个对象的弱引用时，完全没有扩展 referent 的生命周期，只是在对象仍然存活的时候，保持另一种到达它的方法。

弱引用对于构造弱集合最有用，如那些在应用程序的其余部分使用对象期间存储关于这些对象的元数据的集合 —— 这就是 SocketManager 类所要做的工作。因为这是弱引用最常见的用法，WeakHashMap 也被添加到 JDK 1.2 的类库中，它对键（而不是对值）使用弱引用。如果在一个普通 HashMap 中用一个对象作为键，那么这个对象在映射从 Map 中删除之前不能被回收，WeakHashMap 使您可以用一个对象作为 Map 键，同时不会阻止这个对象被垃圾收集。清单 5 给出了 WeakHashMap 的 get() 方法的一种可能实现，它展示了弱引用的使用：

public class WeakHashMap<K,V> implements Map<K,V> {
    private static class Entry<K,V> extends WeakReference<K> 
      implements Map.Entry<K,V> {
        private V value;
        private final int hash;
        private Entry<K,V> next;
        ...
    }
    public V get(Object key) {
        int hash = getHash(key);
        Entry<K,V> e = getChain(hash);
        while (e != null) {
            K eKey= e.get();
            if (e.hash == hash && (key == eKey || key.equals(eKey)))
                return e.value;
            e = e.next;
        }
        return null;
    }

调用 WeakReference.get() 时，它返回一个对 referent 的强引用（如果它仍然存活的话），因此不需要担心映射在 while 循环体中消失，因为强引用会防止它被垃圾收集。WeakHashMap 的实现展示了弱引用的一种常见用法 —— 一些内部对象扩展 WeakReference。其原因在下面一节讨论引用队列时会得到解释。

在向 WeakHashMap 中添加映射时，请记住映射可能会在以后“脱离”，因为键被垃圾收集了。在这种情况下，get() 返回 null，这使得测试 get() 的返回值是否为 null 变得比平时更重要了。

用 WeakHashMap 堵住泄漏

在 SocketManager 中防止泄漏很容易，只要用 WeakHashMap 代替 HashMap 就行了，如清单 6 所示。（如果 SocketManager 需要线程安全，那么可以用 Collections.synchronizedMap() 包装 WeakHashMap）。当映射的生命周期必须与键的生命周期联系在一起时，可以使用这种方法。不过，应当小心不滥用这种技术，大多数时候还是应当使用普通的 HashMap 作为 Map 的实现。

public class SocketManager {
    private Map<Socket,User> m = new WeakHashMap<Socket,User>();
    
    public void setUser(Socket s, User u) {
        m.put(s, u);
    }
    public User getUser(Socket s) {
        return m.get(s);
    }
}

引用队列

WeakHashMap 用弱引用承载映射键，这使得应用程序不再使用键对象时它们可以被垃圾收集，get() 实现可以根据 WeakReference.get() 是否返回 null 来区分死的映射和活的映射。但是这只是防止 Map 的内存消耗在应用程序的生命周期中不断增加所需要做的工作的一半，还需要做一些工作以便在键对象被收集后从 Map 中删除死项。否则，Map 会充满对应于死键的项。虽然这对于应用程序是不可见的，但是它仍然会造成应用程序耗尽内存，因为即使键被收集了，Map.Entry 和值对象也不会被收集。

可以通过周期性地扫描 Map，对每一个弱引用调用 get()，并在 get() 返回 null 时删除那个映射而消除死映射。但是如果 Map 有许多活的项，那么这种方法的效率很低。如果有一种方法可以在弱引用的 referent 被垃圾收集时发出通知就好了，这就是引用队列 的作用。

引用队列是垃圾收集器向应用程序返回关于对象生命周期的信息的主要方法。弱引用有两个构造函数：一个只取 referent 作为参数，另一个还取引用队列作为参数。如果用关联的引用队列创建弱引用，在 referent 成为 GC 候选对象时，这个引用对象（不是 referent）就在引用清除后加入 到引用队列中。之后，应用程序从引用队列提取引用并了解到它的 referent 已被收集，因此可以进行相应的清理活动，如去掉已不在弱集合中的对象的项。（引用队列提供了与 BlockingQueue 同样的出列模式 —— polled、timed blocking 和 untimed blocking。）

WeakHashMap 有一个名为 expungeStaleEntries() 的私有方法，大多数 Map 操作中会调用它，它去掉引用队列中所有失效的引用，并删除关联的映射。清单 7 展示了 expungeStaleEntries() 的一种可能实现。用于存储键-值映射的 Entry 类型扩展了 WeakReference，因此当 expungeStaleEntries() 要求下一个失效的弱引用时，它得到一个 Entry。用引用队列代替定期扫描内容的方法来清理 Map 更有效，因为清理过程不会触及活的项，只有在有实际加入队列的引用时它才工作。

    private void expungeStaleEntries() {
	Entry<K,V> e;
        while ( (e = (Entry<K,V>) queue.poll()) != null) {
            int hash = e.hash;
            Entry<K,V> prev = getChain(hash);
            Entry<K,V> cur = prev;
            while (cur != null) {
                Entry<K,V> next = cur.next;
                if (cur == e) {
                    if (prev == e)
                        setChain(hash, next);
                    else
                        prev.next = next;
                    break;
                }
                prev = cur;
                cur = next;
            }
        }
    }

回页首

结束语

弱引用和弱集合是对堆进行管理的强大工具，使得应用程序可以使用更复杂的可及性方案，而不只是由普通（强）引用所提供的“要么全部要么没有”可及性。下个月，我们将分析与弱引用有关的软引用，将分析在使用弱引用和软引用时，垃圾收集器的行为。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文
  
  
• “关注性能: 调优垃圾收集”：Kirk Pepperdine 和 Jack Shirazi 展示了缓慢的内存泄漏最终对于垃圾收集器造成了无法承受的压力。
  
  
• “HPROF”：Sun 的这一篇文章描述了如何使用内置的 HPROF 分析工具。
  
  
• Reference objects and garbage collection：Sun 的这篇文章是在 Reference 对象刚加入类库不久写的，描述了垃圾收集器如何处理 Reference 对象。
  
  
• Java 理论与实践：Brian Goetz 所写的全部系列文章。
  
  
• Java 技术专区：数百篇关于 Java 编程各个方面的文章。
  
  

• JTune：免费 JTune 工具，可以使用 GC 日志并以图形方式显示堆大小、GC 持续时间和其他有用的内存管理数据。
  
  

• 参与论坛讨论。
  
  
• developerWorks blogs：参与 developerWorks 社区。

关于作者

		Brian Goetz 成为专业软件开发人员已经超过 18 年了。他是 Quiotix 的首席顾问，该公司是位于加利福尼亚 Los Altos 的软件开发和咨询公司。他参加了几个 JCP 专家组。Brian 的 Java Concurrency In Practice 一书将于 2005 年末由 Addison-Wesley 出版。请在业界流行的出版物上查阅 Brian 已发表的和即将发表的文章。

看了一些人的所谓大型项目的方法,我感觉都是没有说到点子上，有点难受。
我也说说自己的看法.我个人认为,很难衡量所谓项目是否大型,
即便很简单的应用在高负载和高增长情况下都是一个挑战.因此,按照我的想法,姑且说是高负载
高并发或者高增长情况下,需要考虑的问题.这些问题,很多是和程序开发无关,而是和整个系统的
架构密切相关的.

• 数据库

没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是Web2.0的应用，数据库的响应是首先要解决的。
一般来说MySQL是最常用的，可能最初是一个mysql主机，当数据增加到100万以上，
那么，MySQL的效能急剧下降。常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的
服务器上进行操作。我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，
但是同时只有1个是Active，我们可以在一定时候切换。之所以用2个M，是保证M不会又成为系统的SPOF。
Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。

以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了
SPOF。你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，
从业务层面上进行分区。最简单的，以用户数据为例。根据一定的切分方式，比如id，切分到不同的数据库集群去。
全局数据库用于meta数据的查询。缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到
全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。
每个cluster可以用m-m方式，或者m-m-slaves方式。
这是一个可以扩展的结构，随着负载的增加，你可以简单的增加新的mysql cluster进去。

需要注意的是：
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。
4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，或者干脆自己做，因为php4中mysql的
链接池经常出问题。

• 缓存

缓存是另一个大问题，我一般用memcached来做缓存集群，一般来说部署10台左右就差不多（10g内存池）。需要注意一点，千万不能用使用
swap，最好关闭linux的swap。

• 负载均衡/加速

可能上面说缓存的时候，有人第一想的是页面静态化，所谓的静态html，我认为这是常识，不属于要点了。页面的静态化随之带来的是静态服务的
负载均衡和加速。我认为Lighttped+Squid是最好的方式了。
LVS <------->lighttped====>squid(s) ====lighttpd

上面是我经常用的。注意，我没有用apache，除非特定的需求，否则我不部署apache，因为我一般用php-fastcgi配合lighttpd,
性能比apache+mod_php要强很多。

squid的使用可以解决文件的同步等等问题，但是需要注意，你要很好的监控缓存的命中率，尽可能的提高的90%以上。
squid和lighttped也有很多的话题要讨论，这里不赘述。

• 存储

存储也是一个大问题，一种是小文件的存储，比如图片这类。另一种是大文件的存储，比如搜索引擎的索引，一般单文件都超过2g以上。
小文件的存储最简单的方法是结合lighttpd来进行分布。或者干脆使用Redhat的GFS，优点是应用透明，缺点是费用较高。我是指
你购买盘阵的问题。我的项目中，存储量是2-10Tb，我采用了分布式存储。这里要解决文件的复制和冗余。
这样每个文件有不同的冗余，这方面可以参考google的gfs的论文。
大文件的存储，可以参考nutch的方案，现在已经独立为hadoop子项目。(你可以google it)

其他：
此外，passport等也是考虑的，不过都属于比较简单的了。

Java随机数类Random介绍

Java实用工具类库中的类java.util.Random提供了产生各种类型随机数的方法。它可以产生int、long、float、double以 及Goussian等类型的随机数。这也是它与java.lang.Math中的方法Random()最大的不同之处，后者只产生double型的随机 数。 类Random中的方法十分简单，它只有两个构造方法和六个普通方法。 构造方法： (1)public Random() (2)public Random(long seed) Java产生随机数需要有一个基值seed，在第一种方法中基值缺省，则将系统时间作为seed。 普通方法： (1)public synonronized void setSeed(long seed) 该方法是设定基值seed。 (2)public int nextInt() 该方法是产生一个整型随机数。 (3)public long nextLong() 该方法是产生一个long型随机数。 (4)public float nextFloat() 该方法是产生一个Float型随机数。 (5)public double nextDouble() 该方法是产生一个Double型随机数。 (6)public synchronized double nextGoussian() 该方法是产生一个double型的Goussian随机数。 例2 RandomApp.java。 //import java.lang.*; import java.util.Random; public class RandomApp{ public static void main(String args[]){ Random ran1=new Random(); Random ran2=new Random(12345); //创建了两个类Random的对象。 System.out.println("The 1st set of random numbers:"); System.out.println(" Integer:"+ran1.nextInt()); System.out.println(" Long:"+ran1.nextLong()); System.out.println(" Float:"+ran1.nextFloat()); System.out.println(" Double:"+ran1.nextDouble()); System.out.println(" Gaussian:"+ran1.nextGaussian());           //产生各种类型的随机数 System.out.print("The 2nd set of random numbers:"); for(int i=0;i<5;i++){ System.out.println(ran2.nextInt()+" "); if(i==2) System.out.println(); //产生同种类型的不同的随机数。 System.out.println(); } } }

Random random=new Random();
random.nextInt();

也可以有nextFloat等等,各种基本类型都有

JAVA产生指定范围的随机数》

《JAVA产生指定范围的随机数》
   产生机制：
产生Min-Max之间的数字
   实现原理：
      Math.round(Math.random()*(Max-Min)+Min)

Modify the following two values in the Windows registry:

This one modifies the range of ports that Windows uses to open connections. By default it only allows up to the port 5000. By modifying this value, Windows will be able to open up more ports before having to recycle back to the beginning. Every connection uses a port, so it starts at 1025 and goes up to this value. When it reaches the max value it goes back to 1025 and tries to open up that port again.

System Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Name: MaxUserPort
Type: REG_DWORD
Value: 5000-65534

This will "release" closed ports faster. By default Windows leaves a port in a TIME_WAIT state for 240 seconds. This can cause problems if the MaxPort value is set to where a new connection will use an "older" port that has not been removed from TIME_WAIT state yet. By decreasing this value, you allow the connections to be released faster.

System Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value Name: TcpTimedWaitDelay
Data Type: REG_DWORD
Value Data: 30-300

防范JAVA内存泄漏解决方案

            
Vector v = new Vector(10);
            for (int i = 1; i < 100; i++)
            ......{
            　Object o = new Object();
            　v.add(o);
            　o = null;
            }//此时，所有的Object对象都没有被释放，因为变量v引用这些对象。 
            

Java的内存泄漏

文档选项 未显示需要 JavaScript 的文档选项 将此页作为电子邮件发送

级别: 初级

欧阳辰,
周欣,

2002 年 10 月 21 日

Java 的一个重要优点就是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员认为Java不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC或JVM的问题。其实，这种想法是不正确的，因为Java也存在内存泄露，但它的表现与C++不同。

问题的提出

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中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为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;i<100; i++)
                    {
                    Object o=new Object();
                    v.add(o);
                    o=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两个工具，分别用于监测运行时的线程状态和代码覆盖面。

当设置好所有的参数了，我们就可以在OptimizeIt环境下运行被测程序，在程序运行过程中，Optimizeit可以监视内存的使用曲线(如下图)，包括JVM申请的堆(heap)的大小，和实际使用的内存大小。另外，在运行过程中，我们可以随时暂停程序的运行，甚至强行调用GC，让GC进行内存回收。通过内存使用曲线，我们可以整体了解程序使用内存的情况。这种监测对于长期运行的应用程序非常有必要，也很容易发现内存泄露。

在运行过程中，我们还可以从不同视角观查内存的使用情况，Optimizeit提供了四种方式：

• 堆视角。 这是一个全面的视角，我们可以了解堆中的所有的对象信息(数量和种类)，并进行统计、排序，过滤。了解相关对象的变化情况。
• 方法视角。通过方法视角，我们可以得知每一种类的对象，都分配在哪些方法中，以及它们的数量。
• 对象视角。给定一个对象，通过对象视角，我们可以显示它的所有出引用和入引用对象，我们可以了解这个对象的所有引用关系。
• 引用图。 给定一个根，通过引用图，我们可以显示从该顶点出发的所有出引用。

在运行过程中，我们可以随时观察内存的使用情况，通过这种方式，我们可以很快找到那些长期不被释放，并且不再使用的对象。我们通过检查这些对象的生存周期，确认其是否为内存泄露。在实践当中，寻找内存泄露是一件非常麻烦的事情，它需要程序员对整个程序的代码比较清楚，并且需要丰富的调试经验，但是这个过程对于很多关键的Java程序都是十分重要的。

综上所述，Java也存在内存泄露问题，其原因主要是一些对象虽然不再被使用，但它们仍然被引用。为了解决这些问题，我们可以通过软件工具来检查内存泄露，检查的主要原理就是暴露出所有堆中的对象，让程序员寻找那些无用但仍被引用的对象。

回页首

参考资料

文章:

Jim Patrick, Handling memory leaks in Java programs,

http://www.ibm.com/developerworks/library/j-leaks/index.html

Ed Lycklama, Does Java Technology Have Memory Leaks?

http://www.klgroup.com/javaone

Sun,The Java HotSpot Virtual Machine, Technical White Paper

软件：

Sitraka Software's Jprobe http://www.sitraka.com

Boland Software's Optimizeit http://optimizeit

IBM alphaWorks' Jinsight http://www.alphaworks.ibm.com/tech/jinsight

回页首

作者简介

		欧阳辰，北京大学计算机硕士毕业，98年起开始研究基于java的软件开发、测试，参与开发、测试过多个基于Java的应用程序和Web服务项目。

		周欣，北京大学计算机系在读博士生，主要研究方向：程序理解、逆向工程及软件度量，联系方式 zhouxin@sei.pku.edu.cn