　　考虑写性能优化系列，主要是因为之前看到了太多性能其烂无比的 Java 代码（有些代码看得俺口瞪目呆）。很多 Java 程序员在写程序时，由于不太了解 JVM 及语言本身的一些运作机制，从而导致了代码的性能出现【严重】问题（性能差一个数量级以上，我才称为“严重”）。
　　虽然网上也有针对 Java 性能的介绍，但是很多内容都仅仅告诉读者“该这么做”，而没有讲“为什么该这么做”。典型的例子就是关于 String 和 StringBuffer（StringBuilder），光介绍如何用，却没有说为什么这样用。这种现象导致了很多 Java 程序员只知其然，不知其所以然。所以本系列帖子会尽量介绍一些“所以然”的东东（也就是学习技术三部曲的WHAT HOW 和 WHY），希望对 Java 程序员有所帮助。

一：基本类型 vs 引用类型

　　在 Java 性能优化系列中，内存管理是一个要优先考虑的关键因素。而说到内存分配，就必然会涉及到基本类型和引用类型。所以我们今天就先来介绍一下这两种类型在性能方面各自有什么奥妙（关于引用类型的其它奥妙，请看“这里”）。

★名词定义

　　先明确一下什么是“基本类型”，什么是“引用类型”。
　　简单地说，所谓基本类型就是 Java 语言中如下的8种内置类型：

boolean
char
byte
short
int
long
float
double

　　而引用类型就是那些可以通过 new 来创建对象的类型（基本上都是派生自 Object）。

★两种类型的存储方式

　　这两种类型的差异，首先体现在存储方式上。

◇引用类型的创建

　　当你在函数中创建一个引用类型的对象时，比如下面这句：

StringBuffer str = new StringBuffer();

　　该 StringBuffer 【对象】的内容是存储在堆（Heap）上的，需要申请堆内存。而变量 str 只不过是针对该 StringBuffer 对象的一个引用（或者叫地址）。变量 str 的【值】（也就是 StringBuffer 对象的地址）是存储在【栈】上的。

◇基本类型的创建

　　当你在【函数中}创建一个基本类型的变量时，比如下面这句：

int n = 123;

　　这个变量 n 的【值】也是存储在栈（Stack）上的，但是这个语句不需要再从堆中申请内存了。

　　为了更加形象，便于大伙儿理解，简单画了一个示意图如下：
技术分享图片

★堆和栈的性能差异

　　可能有同学会小声问：堆和栈有啥区别捏？
　　要说堆和栈的差别，那可就大了去了。如果你对这两个概念还是不太明白或者经常混淆，建议先找本操作系统的书拜读一下。
　　由于本系列是介绍性能，所以来讨论一下堆和栈在性能方面的差别（这个差异是很大滴）。堆相对进程来说是全局的，能够被所有线程访问；而栈是线程局部的，只能本线程访问。打个比方，栈就好比个人小金库，堆就好比国库。你从个人小金库拿钱去花，不需要办什么手续，拿了就花，但是钱数有限；而国库里面的钱虽然很多，但是每次申请花钱要打报告、盖图章、办 N 多手续，耗时又费力。
　　同样道理，由于堆是所有线程共有的，从堆里面申请内存要进行相关的加锁操作，因此申请堆内存的复杂度和时间开销比栈要大很多；从栈里面申请内存，虽然又简单又快，但是栈的大小有限，分配不了太多内存。

★当初为啥这样设计？

　　可能有同学又问了，干嘛把两种类型分开存储，干嘛不放到一起捏？这个问题问得好！下面我们就来揣测一下，当初 Java 为啥设计成这样。
　　当年 Java 它爹（James Gosling）设计语言的时候，对于这个问题有点进退两难。如果把各种东东都放置到栈中，显然不现实，一来栈是线程私有的（不便于共享），二来栈的大小是有限的，三来栈的结构也间接限制了它的用途。那为啥不把各种东东都放置到堆里面捏？都放堆里面，倒是能绕过上述问题，但是刚才也提到了，申请堆内存要办很多手续，太繁琐。如果仅仅在函数中写一个简单的“int n = 0;”，也要到堆里面去分配内存，那性能就大大滴差了（要知道 Java 是1995年生出来的，那年头俺买了台 PC 配【4兆内存】就属豪华配置了）。
　　左思右想之后，Java 它爹只好做了一个折中：把类型分为“基本类型”和“引用类型”，两者使用不同的创建方式。这种差异从 Java 语法上也可以看出来：引用类型总是用 new 创建对象（提醒一下：某些单键对象/单例对象，表面上没用 new，但是在 getInstance() 内部也还是用 new 创建的）；而基本类型则【不需要】用 new 来创建。

★这样设计的弊端

　　顺便跑题一下，斗胆评价 Java 它爹这种设计的弊端（希望 Java Fans 不要跟我急）。我个人认为：这个折中的决策，带来了许多深远的影响，随手举出几个例子：
1、由于基本类型不是派生自 Object，因此不能算是纯种的对象。这导致了 Java 的“【纯】面向对象”招牌打了折扣（当年 Sun 老是吹嘘 Java 是“纯”OO 的语言，其实 Java 的 OO 是不够纯粹滴）。
2、由于基本类型不是派生自 Object，出于某些场合（比如容器类）的考虑，不得不为每个基本类型加上对应的包装类（比如 Integer、Byte 等），使得语言变得有点冗余。

★结论

　　从上述的介绍，我们应该明白，使用 new 创建对象的开销是【不小】的。在程序中能避免就应该尽量避免。另外，使用 new 创建对象，不光是创建时开销大，将来垃圾回收时，销毁对象也是有开销的（关于 GC 的开销，咱们会在后面的帖子细谈）。

二：字符串过滤实战

★一个简单的需求

　　首先描述一下需求：
给定一个 String 对象，过滤掉除了数字（字符‘0‘到‘9‘）以外的其它字符。要求时间开销尽可能小。过滤函数的原型如下：

String filter(String str);

　　针对上述需求，俺写了5个不同的过滤函数。为了叙述方便，函数名分别定为 filter1 到 filter5。其中 filter1 性能最差、filter5 性能最好。在看后续的内容之前，你先暗自思考一下，如果由你来实现该函数，大概会写成什么样？最好把你想好的函数写下来，便于跟俺给出的例子作对比。

★代码——循序渐进的5种实现方式

◇测试代码

　　为了方便测试性能，先准备好一坨测试代码，具体如下：

class Test
{
    public static void main(String[] args)
    {
        if(args.length != 1)
        {
            return;
        }

        String str = "";
        long nBegin = System.currentTimeMillis();
        for(int i=0; i<1024*1024; i++)
        {
            str = filterN(args[0]);  // 此处调用某个具体的过滤函数
        }
        long nEnd = System.currentTimeMillis();

        System.out.println(nEnd-nBegin);
        System.out.println(str);
    }
};

　　在没有想好你的实现方式之前，先别偷看后续内容哦！另外，先注明一下，俺的 Java 环境是 JDK 1.5.0-09，使用的测试字符串是随机生成的，长度32个 char，只含字母和数字。由于 JDK 版本和机器性能不尽相同，你在自己机器上测试的结果可能跟俺下面给出的数值不太一样。

◇版本1

　　先来揭晓性能最差的filter1，代码如下：

private static String filter1(String strOld)
{
    String strNew = new String();
    for(int i=0; i<strOld.length(); i++)
    {
        if(‘0‘<=strOld.charAt(i) && strOld.charAt(i)<=‘9‘)
        {
            strNew += strOld.charAt(i);
        }
    }
    return strNew;
}

　　如果你的代码不幸和 filter1 雷同，那你的 Java 功底可就是相当糟糕了，连字符串拼接需要用 StringBuffer 来优化都没搞明白。
　　为了和后续对比，先记下 filter1 的处理时间，大约在 8.81-8.90秒之间。

◇版本2

　　再来看看 filter2，代码如下：

private static String filter2(String strOld)
{
    StringBuffer strNew = new StringBuffer();
    for(int i=0; i<strOld.length(); i++)
    {
        if(‘0‘<=strOld.charAt(i) && strOld.charAt(i)<=‘9‘)
        {
            strNew.append(strOld.charAt(i));
        }
    }
    return strNew.toString();
}

　　其实刚才在评价 filter1 的时候，已经泄露了 filter2 的天机。filter2 通过使用 StringBuffer 来优化连接字符串的性能。为什么 StringBuffer 连接字符串的性能比 String 好，这个已经是老生常谈，俺在这儿就不细说啦。尚不清楚的同学自己上 Google 一查便知。估计应该有挺多同学会写出类似 filter2 的代码。
　　有些同学可能会问：为啥不用 StringBuilder？
　　确实，在 JDK 1.5 新增加了 StringBuilder 这个类，其性能会比 StringBuffer 更好。不过捏，考虑到有可能要拿到其它版本的 JDK 上作对比测试，而且 StringBuilder 和 StringBuffer 之间的差异【不是】本文讨论的重点，所以后面的例子都使用 StringBuffer 来实现。
　　filter2 的处理时间大约为 2.14-2.18秒，提升了大约4倍。

◇版本3

　　接着看看 filter3，代码如下：

private static String filter3(String strOld)
{
    StringBuffer strNew = new StringBuffer();
    int nLen = strOld.length();
    for(int i=0; i<nLen; i++)
    {
        char ch = strOld.charAt(i);
        if(‘0‘<=ch && ch<=‘9‘)
        {
            strNew.append(ch);
        }
    }
    return strNew.toString();
}

　　乍一看，filter3 和 filter2 的代码差不多嘛！再仔细瞧一瞧，原来先把 strOld.charAt(i) 赋值给 char 变量，节省了重复调用 charAt() 方法的开销；另外把 strOld.length() 先保存为 nLen，也节省了重复调用 length() 的开销。能想到这一步的同学，估计是比较细心的。
　　经过此一优化，处理时间节省为 1.48-1.52秒，提升了约30%。由于 charAt() 和 length() 的内部实现都挺简单的，所以提升的性能不太明显。
　　另外补充一下，经网友反馈，在 JDK 1.6 上，filter3 和 filter2 的性能基本相同。俺估计：可能是因为 JDK 1.6 在编译时已经进行了相关的优化。

◇版本4

　　然后看看 filter4，代码如下：

private static String filter4(String strOld)
{
    int nLen = strOld.length();
    StringBuffer strNew = new StringBuffer(nLen);
    for(int i=0; i<nLen; i++)
    {
        char ch = strOld.charAt(i);
        if(‘0‘<=ch && ch<=‘9‘)
        {
            strNew.append(ch);
        }
    }
    return strNew.toString();
}

　　filter4 和 filter3 差别也很小，唯一差别就在于调用了 StringBuffer 带参数的构造函数。通过 StringBuffer 的构造函数设置初始的容量大小，可以有效避免 append() 追加字符时重新分配内存，从而提高性能。
　　filter4 的处理时间大约在 1.33-1.39秒，约提高10%左右。可惜提升的幅度有点小 :-(

◇版本5

　　最后来看看“终极版本”——性能最好的 filter5。

private static String filter5(String strOld)
{
    int nLen = strOld.length();
    char[] chArray = new char[nLen];
    int nPos = 0;
    for(int i=0; i<nLen; i++)
    {
        char ch = strOld.charAt(i);
        if(‘0‘<=ch && ch<=‘9‘)
        {
            chArray[nPos] = ch;
            nPos++;
        }
    }
    return new String(chArray, 0, nPos);
}

　　猛一看，你可能会想：这个 filter5 和前几个版本的差别也忒大了吧！filter5 既没有用 String 也没有用 StringBuffer，而是拿字符数组进行中间处理。
　　filter5 的处理时间，只用了0.72-0.78秒，相对于 filter4 提升了将近50%。为啥捏？是不是因为直接操作字符数组，节省了 append(char) 的调用？通过查看 append(char) 的源代码，内部的实现很简单，应该不至于提升这么多。
　　那是什么原因捏？
　　首先，虽然 filter5 有一个字符数组的创建开销，但是相对于 filter4 来说，StringBuffer 的构造函数内部也会有字符数组的创建开销。两相抵消。所以 filter5 比 filter4 还多节省了 StringBuffer 对象本身的创建开销。（在俺的 JDK 1.5 环境中，这个因素比较明显）
　　其次，由于 StringBuffer 是线程安全的（它的方法都是 synchronized），因此调用它的方法有一定的同步开销，而字符数组则没有，这又是一个性能提升的地方。（经热心读者反馈，此因素在 JDK 1.6 中比较明显）
　　基于上述两个因素，所以 filter5 比 filter4 又有较大幅度的提升。

★对于5个版本的总结

　　上述5个版本，filter1 和 filter5 的性能相差约12倍（已经超过一个数量级）。除了 filter3 相对于 filter2 是通过消除函数重复调用来提升性能，其它的几个版本都是通过节省内存分配，降低了时间开销。可见内存分配对于性能的影响有多大啊！如果你是看了上一个帖子才写出 filter4 或者 filter5，那说明你已经领会了个中奥妙，俺那个帖子也就没白写了。

★一点补充说明，关于时间和空间的平衡

　　另外，需要补充说明一下。版本4和版本5使用了空间换时间的手法来提升性能。假如被过滤的字符串【很大】，并且数字字符的比例【很低】，这种方式就不太合算了。
　　举个例子：被处理的字符串中，绝大部分都只含有不到10%的数字字符，只有少数字符串包含较多的数字字符。这时候该怎么办捏？
　　对于 filter4 来说，可以把 new StringBuffer(nLen); 修改为 new StringBuffer(nLen/10); 来节约空间开销。但是 filter5 就没法这么玩了。
　　所以，具体该用“版本4”还是“版本5”，要看具体情况了。只有在你【非常】看重时间开销，且数字字符比例很高（至少大于50%）的情况下，用 filter5 才合算。否则的话，建议用 filter4。

三：垃圾回收（GC）

★JVM 的内存空间

　　在 Java 虚拟机规范中（具体章节请看“这里”），提及了如下几种类型的内存空间：

◇栈内存（Stack）：每个线程私有的。
◇堆内存（Heap）：所有线程公用的。
◇方法区（Method Area）：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。
◇原生方法栈（Native Method Stack）：主要用于 JNI 中的原生代码，平时很少涉及。

　　关于栈内存（Stack）和堆内存（Heap），已经在上面中扫盲过了，大伙儿应该有点印象。由于今天咱们要讨论的“垃圾回收”话题，主要是和堆内存（Heap）有关。其它的几个玩意儿不是今天讨论的重点。等以后有空了，或许可以单独聊一下。

★垃圾回收机制简介

　　其实 Java 虚拟机规范中并未规定垃圾回收的相关细节。垃圾回收具体该怎么搞，完全取决于各个 JVM 的设计者。所以，不同的 JVM 之间，GC 的行为可能会有一定的差异。下面咱拿 SUN 官方的 JVM 来简单介绍一下 GC 的机制。

◇啥时候进行垃圾回收？

　　一般情况下，当 JVM 发现堆内存比较紧张、不太够用时，它就会着手进行垃圾回收工作。但是大伙儿要认清这样一个残酷的事实：JVM 进行 GC 的时间点是无法准确预知的。因为 GC 启动的时刻会受到各种运行环境因素的影响，随机性太大。
　　虽说咱们无法准确预知，但如果你想知道每次垃圾回收执行的情况，还是蛮方便的。可以通过 JVM 的命令行参数“-XX:+PrintGC”把相关信息打印出来。
　　另外，调用 System.gc() 只是建议 JVM 进行 GC。至于 JVM 到底会不会真的去做，只有天晓得。所以，通常不建议自己手动调用 System.gc()，还是让 JVM 自行决定比较好。另外，使用 JVM 命令行参数“-XX:+DisableExplicitGC”可以让 System.gc() 不起作用。

◇谁来负责垃圾回收？

　　一般情况下，JVM 会有一个或多个专门的垃圾回收线程，由它们负责清理回收垃圾内存。

◇如何发现垃圾对象？

　　垃圾回收线程会从“根集（Root Set）”开始进行对象引用的遍历。所谓的“根集”，就是正在运行的线程中，可以访问的【引用变量】的集合（比如所有线程当前函数的参数和局部变量、当前类的成员变量等等）。垃圾回收线程先找出被根集直接引用的所有对象（不妨叫集合1），然后再找出被集合1直接引用的所有对象（不妨叫集合2），然后再找出被集合2直接引用的所有对象......如此循环往复，直到把能遍历到的对象都遍历完。
　　凡是从“根集”通过上述遍历可以到达的对象，都称为可达对象或有效对象；反之，则是不可达对象或失效对象（也就是垃圾）。

◇如何清理/回收垃圾？

　　通过上述阶段，就把垃圾对象都找出来。然后垃圾回收线程会进行相应的清理和回收工作，包括：把垃圾内存重新变为可用内存、进行内存的整理以消除内存碎片、等等。这个过程会涉及到若干算法，有兴趣的同学可以参见“这里”。限于篇幅，咱就不深入聊了。

◇分代

　　早期的 JVM 是不采用分代技术的，所有被 GC 管理的对象都存放在同一个堆里面。这么做的缺点比较明显：每次进行GC都要遍历所有对象，开销很大。其实大部分的对象生命周期都很短（短命对象），只有少数对象比较长寿；在这些短命对象中，又只有少数对象占用的内存空间大；其它大量的短命对象都属于小对象（很符合二八原理）。
　　有鉴于此，从 JDK 1.2 之后，JVM 开始使用分代的垃圾回收（Generational Garbage Collection）。JVM 把 GC 相关的内存分为“年老代”（Tenured）和“年轻代”（Nursery）、“持久代”（Permanent，对应于 JVM 规范的“方法区”）。【大部分】对象在刚创建时，都位于“年轻代”。如果某对象经历了几轮 GC 还活着（大龄对象），就把它移到“年老代”。另外，如果某个对象在创建时比较大，可能就直接被丢到年老代。经过这种策略，使得年轻代总是保存那些短命的小对象。在空间尺寸上，“年轻代”相对较小，而“年老代”相对较大。
　　因为有了分代技术，JVM 的 GC 也相应分为两种——主要收集（Major Collection）和次要收集（Minor Collection）。“主要收集”同时清理年老代和年轻代，因此开销很大，不常进行；“次要收集”仅仅清理年轻代，开销很小，经常进行。

★GC对性能会有啥影响？

　　刚才介绍了GC的大致原理，那GC对性能会造成哪些影响捏？主要有如下几个方面：

◇造成当前运行线程的停顿

　　早期的 GC 比较弱智。在它工作期间，所有其它的线程都被暂停（以免影响垃圾回收工作）。等到 GC 干完活，其它线程再继续运行。所以，早期 JDK 的 GC 一旦开始工作，整个程序就会陷入假死状态，失去各种响应。
　　经过这些年的技术改进（包括采用分代技术），从 JDK 1.4 开始，GC 已经比较精明了。在它干活期间，只是偶尔暂停一下其它线程的运行（从长时间假死变为暂时性休克）。

◇遍历对象引用的开销

　　试想如果JVM中的对象很多，那遍历完所有可达对象肯定是比较费劲的工作，这个开销可不小。

◇清理和回收垃圾的开销

　　遍历完对象引用之后，对垃圾的清理和回收也有较大的开销。这部分开销可能包括复制内存块、更新对象引用等等。

★几种收集器

◇两个性能指标

　　因为今天聊的是性能的话题，必然会提到衡量 GC 性能的两个重要指标：吞吐量（Throughput）和停顿时间（Pause Time）。吞吐量这个词不是很直观，解释一下：就是 JVM【不用于】GC 的时间占总时间的比率。“吞吐量”是越大越好，“停顿时间”是越小越好。
　　不同的应用程序对这两个指标的关注点不一样（后面具体会说），也就是所谓的“众口难调”。很多 JVM 厂商为了迎合“众口”，不得不提供多种几种垃圾收集器供使用者选择。不同的收集器，采用的收集策略是不一样的，下面具体介绍。

◇串行收集器（Serial Collector）

　　使用命令行选项“-XX:+UseSerialGC”指定。
　　这种收集器是最传统的收集器。它使用单线程进行垃圾回收，对于“单 CPU 机器”比较合适。另外，小型应用或者对上述两个指标没有特殊要求的，可以使用串行收集器。

◇并行收集器（Parallel Throughput Collector）

　　顾名思义，这种收集器使用多个线程进行垃圾回收以达到高吞吐量。垃圾回收线程的数量通过命令行选项“-XX:ParallelGCThreads=n”指定。可以设置该数值以便充分利用“多CPU 或多核”。
　　当使用命令行选项“-XX:+UseParallelGC”时：它会针对年轻代使用多个垃圾回收线程，对年老代依然使用单个线程的串行方式。此选项最早在JDK 1.5引入。
　　当使用命令行选项“-XX:+UseParallelOldGC”时：它针对年轻代和年老代都使用多个垃圾回收线程的方式。不过此选项从 JDK 1.6 才开始引入。

◇并发收集器（Concurrent Low Pause Collector）

　　使用命令行选项“-XX:+UseConcMarkSweepGC”指定。
　　这种收集器优先保证程序的响应。它会尽量让垃圾回收线程和应用自身的线程同时运行，从而降低停顿时间。此选项从JDK 1.4.1开始支持。

◇增量收集器（Incremental Collector）

　　自从 JDK 1.4.2 以来，SUN 官方就停止维护该收集器了。所以俺就节省点口水，不多说了。

★如何降低GC的影响？

◇尽量减少堆内存的使用

　　由于 GC 是针对存储在堆内存的对象进行的。咱们如果在程序中减少引用对象的分配（也就相应降低堆内存分配），那对于提高 GC 的性能是很有帮助滴。上次“字符串过滤实战”的帖子给出了一个例子，示范了如何通过降低堆内存的分配次数来提升性能。

◇设置合适的堆内存大小

　　JVM 的堆内存是有讲究的，不能太大也不能太小。如果堆内存太小，JVM 老是感觉内存不够用，可能会导致频繁进行垃圾回收，影响了性能；如果堆内存太大，以至于操作系统的大部分物理内存都被 JVM 自个儿霸占了，那可能会影响其它应用程序甚至操作系统本身的性能。
　　另外，年轻代的大小（或者说“年轻代”与“年老代”的比值）对于 GC 的性能也有明显影响。如果年轻代太小，可能导致次要收集很频繁；如果年轻代太大，导致次要收集的停顿很明显。
　　JVM 提供了若干和堆内存大小相关的命令行选项，具体如下：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
-Xms　　设置初始堆内存
-Xmx　　设置最大堆内存
-Xmn　　设置年轻代的大小
-XX:NewRatio=n　　设置年轻代与年老代的比例为“n”
-XX:NewSize=n　　设置年轻代大小为“n”
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
　　一般情况下，JVM 的默认参数值已经够用。所以没事儿别轻易动用上述选项。如果你非调整不可，一定要做深入的性能对比测试，保证调整后的性能确实优于默认参数值。

◇吞吐量和停顿的取舍

　　前面提到了不同应用的众口难调。常见的口味有两种：(1)看重吞吐量，对停顿时间无所谓；(2)侧重于停顿时间。
　　对于某些在后台的、单纯运算密集型的应用，属于第一种。比如某些科学计算的应用。这时候建议使用并行收集器。
　　对于涉及用户 UI 交互的、实时性要求比较高、程序需要快速响应的，属于第二种。比如某些桌面游戏、某些电信交换系统。这时候建议使用并发收集器。

★相关的参考资料

◇GC调优资料

　　SUN 官方提供了若干关于 JVM 垃圾回收调优的说明文档：
JDK 1.4.2 请看“这里”；
JDK 1.5请看“这里”；
JDK 1.6请看“这里”。

◇JVM命令行选项说明

　　这是 SUN 公司内的某个有心人整理的各种命令行参数大全，在“这里”。包括有每个参数所适用的 JDK 版本。

◇虚拟机规范

　　“这里”是 SUN 官方提供的 JVM 规范。

四：关于 finalize 函数

★finalize 函数的调用机制　　俺经常啰嗦：“了解本质机制的重要性”。所以今天也得先谈谈 finalize 函数的调用机制。在聊之前，先声明一下：Java虚拟机规范（见“这里”），并没有硬性规定垃圾回收该不该搞，以及该如何搞。所以俺这里提到的 finalize 函数的调用机制，或许适用于大多数 JVM，但【不保证】适用于所有的 JVM。

◇何时被调用？

　　finalize 啥时候才会被调用捏？一般来说，要等到JVM开始进行垃圾回收的时候，它才【有可能】被调用。而 JVM 进行垃圾回收的时间点是【非常】不确定的，依赖于各种运行时的环境因素。具体细节可以参见“本系列前一帖”。正是由于 finalize 函数调用时间点的不确定，导致了后面提到的某些缺点。

◇谁来调用？

　　说完何时调用，咱接着来聊一下被谁调用？
　　常见的 JVM 会通过 GC 的垃圾回收线程来进行 finalize 函数的调用。由于垃圾回收线程比较重要（人家好歹也是 JVM 的一个组成部分嘛），为了防止 finalize 函数抛出的异常影响到垃圾回收线程的运作，垃圾回收线程会在调用每一个 finalize 函数时进行 try/catch，如果捕获到异常，就直接丢弃，然后接着处理下一个失效对象的 finalize 函数。

★对 finalize 函数的误解和误用

◇把 finalize 理解为“析构函数”

　　学过 C++ 的同学应该都知道“析构函数”（不懂 C++ 的同学直接跳过此小节）。C++ 析构函数是在对象离开作用域的当口，【立即】被调用的。
　　很多从 C++ 转 Java 的同学会想当然地把 Java 的 finalize 函数牵强附会成 C++ 的析构函数（两者确实有某些相似之处）。然而，现实往往不是这么美好滴。由于 Java 的 finalize 函数和 C++ 的析构函数之间有许多非常【关键性】的差异，那些把 finalize 拿来当析构函数用的同学，是注定要碰壁滴（具体请看本文后面“finalize 函数的缺点”）。

◇依靠 finalize 来释放资源

　　很多同学寄希望于通过 finalize() 来完成类对象中某些资源的释放（比如关闭数据库连接之类）。
　　有这种企图的同学，请注意看本文后面的“finalize 函数的缺点”！

★使用 finalize 函数的注意事项

　　下面介绍的注意事项，有些可能和性能优化关系不大，俺也一并列出来。

◇调用时间不确定——有资源浪费的风险

　　前面已经介绍了调用机制。同学们应该认清【finalize 的调用时机是很不确定的】这样一个事实。所以，假如你把某些稀缺资源放到 finalize() 中释放，可能会导致该稀缺资源等上很久很久很久以后才被释放。这可是资源的浪费啊！
　　另外，某些类对象所携带的资源（比如某些 JDBC 的类）可能本身就很耗费内存，这些资源的延迟释放会造成很大的性能问题。

◇可能不被调用——有资源泄漏的风险

　　很多同学误以为 finalize() 总是会被调用，【其实不然】。在某些情况下，finalize() 压根儿不被调用。比如在 JVM 退出的当口，内存中那些对象的 finalize 函数可能就不会被调用了。
　　俺估摸着：还有同学在打 “runFinalizersOnExit” 的主意，来确保所有的 finalize 在 JVM 退出前被调用。但是，很可惜也很遗憾，该方法从 JDK 1.2 开始，就已经被废弃了。即使该方法不被废弃，也是有很大的线程安全隐患滴！企图打这个主意的同学，趁早死了这条心吧！
　　从上述可以看出，一旦你依赖 finalize() 来帮你释放资源，那可是很不妙啊（【有资源泄漏的危险】）！关于资源泄漏的严重性，俺在“Java 新手的通病[3]：缺少良好的编程习惯
”曾经提到过。很多时候，资源泄露导致的性能问题更加严重，万万不可小看。

◇对象可能在 finalize 函数调用时复活——有诈尸的风险

　　诈尸的情况比较少见，不过俺还是稍微提一下。
　　本来，只有当某个对象已经失效（没有引用），垃圾回收器才会调用该对象的 finalize 函数。但是，万一碰上某个变态的程序员，在 finalize() 函数内部再把对象自身的引用（也就是 this）重新保存在某处，也就相当于把自己复活了（因为这个对象重新有了引用，不再处于失效状态）。这种做法是不是够变态啊 :-)
　　为了防止发生这种诡异的事情，垃圾回收器只能在每次调用完 finalize() 之后再次去检查该对象是否还处于失效状态。这无形中又增加了 JVM 的开销。
　　随便提一下。由于 JDK 的文档中规定了（具体参见“这里”），JVM 对于每一个类对象实例最多只会调用一次 finalize()。所以，对于那些诈尸的实例，当它们真正死亡时，finalize() 反而不会被调用了。这看起来是不是很奇怪？

◇要记得自己做异常捕获

　　刚才在介绍 finalize() 调用机制时提到，一旦有异常抛出到 finalize 函数外面，会被垃圾回收线程捕获并丢弃。也就是说，异常被忽略掉了（异常被忽略的危害，“这里”有提到）。为了防止这种事儿，凡是 finalize() 中有可能抛出异常的代码，你都得写上 try catch 语句，自己进行捕获。

◇要小心线程安全

　　由于调用 finalize() 的是垃圾回收线程，和你自己代码的线程不是同一个线程；甚至不同对象的 finalize() 可能会被不同的垃圾回收线程调用（比如使用“并行收集器”的时候）。所以，当你在 finalize() 里面访问某些数据的时候，还得时刻留心线程安全的问题。

★结论

　　前面废了这么多话，最后稍微总结一下。俺窃以为：finalize 实在是 Java 的鸡肋。或许它对于【极少数】程序员有用，但对于大多数人（包括俺自个儿），这玩意儿压根儿没啥好处。大伙儿还是尽量不用为妙。

Java 性能优化（编程随想的博客）