Java 性能优化[4]：关于 finalize 函数
Java 性能优化[4]：关于 finalize 函数
上次的帖子 聊了垃圾回收器的调优，当时啰嗦了比较长的篇幅，就没再继续提 finalize 的事儿（其实这玩意儿和 GC 是沾点儿边的）。今天咱就把 finalize 函数相关的性能话题拿来说一下。
俺经常啰嗦：“了解本质机制的重要性”。所以今天也得先谈谈 finalize 函数的调用机制。在聊之前，先声明一下：Java虚拟机规范（见“ 这里 ”），并没有硬性规定垃圾回收该不该搞，以及该如何搞。所以俺这里提到的 finalize 函数的调用机制，或许适用于大多数 JVM，但【不保证】适用于所有的 JVM。
finalize 啥时候才会被调用捏？一般来说，要等到JVM开始进行垃圾回收的时候，它才【 有可能 】被调用。而 JVM 进行垃圾回收的时间点是【非常】不确定的，依赖于各种运行时的环境因素。具体细节可以参见“ 本系列前一帖 ”。正是由于 finalize 函数调用时间点的不确定，导致了后面提到的某些缺点。
说完何时调用，咱接着来聊一下被谁调用？
常见的 JVM 会通过 GC 的垃圾回收线程来进行 finalize 函数的调用。由于垃圾回收线程比较重要（人家好歹也是 JVM 的一个组成部分嘛），为了防止 finalize 函数抛出的异常影响到垃圾回收线程的运作，垃圾回收线程会在调用每一个 finalize 函数时进行 try/catch，如果捕获到异常，就直接丢弃，然后接着处理下一个失效对象的 finalize 函数。
学过 C++ 的同学应该都知道“析构函数”（不懂 C++ 的同学直接跳过此小节）。C++ 析构函数是在对象离开作用域的当口，【立即】被调用的。
很多从 C++ 转 Java 的同学会想当然地把 Java 的 finalize 函数牵强附会成 C++ 的析构函数（两者确实有某些相似之处）。然而，现实往往不是这么美好滴。由于 Java 的 finalize 函数和 C++ 的析构函数之间有许多非常【关键性】的差异，那些把 finalize 拿来当析构函数用的同学，是注定要碰壁滴（具体请看本文后面“finalize 函数的缺点”）。
很多同学寄希望于通过 finalize() 来完成类对象中某些资源的释放（比如关闭数据库连接之类）。
有这种企图的同学，请注意看本文后面的“finalize 函数的缺点”！
下面介绍的注意事项，有些可能和性能优化关系不大，俺也一并列出来。
前面已经介绍了调用机制。同学们应该认清【 finalize 的调用时机是很不确定的 】这样一个事实。所以，假如你把某些稀缺资源放到 finalize() 中释放，可能会导致该稀缺资源等上很久很久很久以后才被释放。这可是资源的浪费啊！
另外，某些类对象所携带的资源（比如某些 JDBC 的类）可能本身就很耗费内存，这些资源的延迟释放会造成很大的性能问题。
很多同学误以为 finalize() 总是会被调用，【其实不然】。在某些情况下，finalize() 压根儿不被调用。比如在 JVM 退出的当口，内存中那些对象的 finalize 函数可能就不会被调用了。
俺估摸着：还有同学在打 “runFinalizersOnExit” 的主意，来确保所有的 finalize 在 JVM 退出前被调用。但是，很可惜也很遗憾，该方法从 JDK 1.2 开始，就已经被废弃了。即使该方法不被废弃，也是有很大的线程安全隐患滴！企图打这个主意的同学，趁早死了这条心吧！
从上述可以看出，一旦你依赖 finalize() 来帮你释放资源，那可是很不妙啊（【有资源泄漏的危险】）！关于资源泄漏的严重性，俺在“ 这里 ”曾经提到过。很多时候，资源泄露导致的性能问题更加严重，万万不可小看。
诈尸的情况比较少见，不过俺还是稍微提一下。
本来，只有当某个对象已经失效（没有引用），垃圾回收器才会调用该对象的 finalize 函数。但是，万一碰上某个变态的程序员，在 finalize() 函数内部再把对象自身的引用（也就是 this）重新保存在某处，也就相当于把自己复活了（因为这个对象重新有了引用，不再处于失效状态）。这种做法是不是够变态啊 :-)
为了防止发生这种诡异的事情，垃圾回收器只能在每次调用完 finalize() 之后再次去检查该对象是否还处于失效状态。这无形中又增加了 JVM 的开销。
随便提一下。由于 JDK 的文档中规定了（具体参见“ 这里 ”），JVM 对于每一个类对象实例最多只会调用一次 finalize()。所以，对于那些诈尸的实例，当它们真正死亡时，finalize() 反而不会被调用了。这看起来是不是很奇怪？
刚才在介绍 finalize() 调用机制时提到，一旦有异常抛出到 finalize 函数外面，会被垃圾回收线程捕获并丢弃。也就是说，异常被忽略掉了（异常被忽略的危害，“ 这里 ”有提到）。为了防止这种事儿，凡是 finalize() 中有可能抛出异常的代码，你都得写上 try catch 语句，自己进行捕获。
由于调用 finalize() 的是垃圾回收线程，和你自己代码的线程不是同一个线程；甚至不同对象的 finalize() 可能会被不同的垃圾回收线程调用（比如使用“并行收集器”的时候）。所以，当你在 finalize() 里面访问某些数据的时候，还得时刻留心线程安全的问题。
前面废了这么多话，最后稍微总结一下。俺窃以为：finalize 实在是 Java 的鸡肋。或许它对于【极少数】程序员有用，但对于大多数人（包括俺自个儿），这玩意儿压根儿没啥好处。大伙儿还是尽量不用为妙。
回到本系列的目录
★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() 来帮你释放资源，那可是很不妙啊（【有资源泄漏的危险】）！关于资源泄漏的严重性，俺在“ 这里 ”曾经提到过。很多时候，资源泄露导致的性能问题更加严重，万万不可小看。
◇对象可能在 finalize 函数调用时复活——有诈尸的风险
诈尸的情况比较少见，不过俺还是稍微提一下。
本来，只有当某个对象已经失效（没有引用），垃圾回收器才会调用该对象的 finalize 函数。但是，万一碰上某个变态的程序员，在 finalize() 函数内部再把对象自身的引用（也就是 this）重新保存在某处，也就相当于把自己复活了（因为这个对象重新有了引用，不再处于失效状态）。这种做法是不是够变态啊 :-)
为了防止发生这种诡异的事情，垃圾回收器只能在每次调用完 finalize() 之后再次去检查该对象是否还处于失效状态。这无形中又增加了 JVM 的开销。
随便提一下。由于 JDK 的文档中规定了（具体参见“ 这里 ”），JVM 对于每一个类对象实例最多只会调用一次 finalize()。所以，对于那些诈尸的实例，当它们真正死亡时，finalize() 反而不会被调用了。这看起来是不是很奇怪？
◇要记得自己做异常捕获
刚才在介绍 finalize() 调用机制时提到，一旦有异常抛出到 finalize 函数外面，会被垃圾回收线程捕获并丢弃。也就是说，异常被忽略掉了（异常被忽略的危害，“ 这里 ”有提到）。为了防止这种事儿，凡是 finalize() 中有可能抛出异常的代码，你都得写上 try catch 语句，自己进行捕获。
◇要小心线程安全
由于调用 finalize() 的是垃圾回收线程，和你自己代码的线程不是同一个线程；甚至不同对象的 finalize() 可能会被不同的垃圾回收线程调用（比如使用“并行收集器”的时候）。所以，当你在 finalize() 里面访问某些数据的时候，还得时刻留心线程安全的问题。
★结论
前面废了这么多话，最后稍微总结一下。俺窃以为：finalize 实在是 Java 的鸡肋。或许它对于【极少数】程序员有用，但对于大多数人（包括俺自个儿），这玩意儿压根儿没啥好处。大伙儿还是尽量不用为妙。
回到本系列的目录
版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2009/06/java-performance-tuning-4-finalize.html
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2009/06/java-performance-tuning-4-finalize.html
文章版权归原作者所有。
