《Java 核心技术面试》课程笔记（三）

谈谈 final、finally、 finalize 有什么不同？

典型回答

• final 可以用来修饰类、方法、变量，分别有不同的意义，final 修饰的 class 代表不可以继承扩展，final 的变量是不可以修改的，而 final 的方法也是不可以重写的（override）。
• finally 则是 Java 保证重点代码一定要被执行的一种机制。我们可以使用 try-finally 或者 try-catch-finally 来进行类似关闭 JDBC 连接、保证 unlock 锁等动作。
• finalize 是基础类 java.lang.Object 的一个方法，它的设计目的是保证对象在被垃圾收集前完成特定资源的回收。finalize 机制现在已经不推荐使用，并且在 JDK 9 开始被标记为 deprecated。

考点分析

• 这是一个非常经典的 Java 基础问题，面试官可以考察性能、并发、对象生命周期或垃圾收集基本过程等方面。
• 推荐使用 final 关键字来明确表示我们代码的语义、逻辑意图，这已经被证明在很多场景下
  是非常好的实践，某种程度上，这是保证平台安全的必要手段。
  • 我们可以将方法或者类声明为 final，这样就可以明确告知别人，这些行为是不许修改的。
  • 使用 final 修饰参数或者变量，也可以清楚地避免意外赋值导致的编程错误。
  • final 变量产生了某种程度的不可变（immutable）的效果，所以，可以用于保护只读数据，尤其是在并发编程中，因为明确地不能再赋值 final 变量，有利于减少额外的同步开销，也可以省去一些防御性拷贝的必要。
• final 也许会有性能的好处。
  • 利用 final 可能有助于 JVM 将方法进行内联，可以改善编译器进行条件编译的能力等等。坦白说，很多类似的结论都是基于假设得出的，比如现代高性能 JVM（如 HotSpot）判断内联未必依赖 final 的提示，要相信 JVM 还是非常智能的。
  • 类似的，final 字段对性能的影响，大部分情况下，并没有考虑的必要。
• 对于 finally，明确知道怎么使用就足够了。需要关闭的连接等资源，更推荐使用 Java 7 中添加的 try-with-resources 语句，因为通常 Java 平台能够更好地处理异常情况，编码量也要少很多。
• 对于 finalize，我们要明确它是不推荐使用的，业界实践一再证明它不是个好的办法，在 Java 9 中，甚至明确将 Object.finalize() 标记为 deprecated！
  • 如果没有特别的原因，不要实现 finalize 方法，也不要指望利用它来进行资源回收。
  • 简单说，你无法保证 finalize 什么时候执行，执行的是否符合预期。
  • 使用不当会影响性能，导致程序死锁、挂起等。

知识扩展

• final 并不等同于 immutable。
  • 如果我们真的希望对象本身是不可变的，那么需要相应的类支持不可变的行为。
  • Immutable 在很多场景是非常棒的选择，某种意义上说，Java 语言目前并没有原生的不可变支持，如果要实现 immutable 的类，我们需要做到：
    • 将 class 自身声明为 final，这样别人就不能扩展来绕过限制了。
    • 将所有成员变量定义为 private 和 final，并且不要实现 setter 方法。
    • 通常构造对象时，成员变量使用深度拷贝来初始化，而不是直接赋值，这是一种防御措施，因为你无法确定输入对象不被其他人修改。
    • 如果确实需要实现 getter 方法，或者其他可能会返回内部状态的方法，使用 copy-on-write 原则，创建私有的 copy。
• 资源用完即显式释放，或者利用资源池来尽量重用。
  • Java 平台目前在逐步使用 java.lang.ref.Cleaner 来替换掉原有的 finalize 实现。
  • Cleaner 的实现利用了幻象引用（PhantomReference），这是一种常见的所谓 post-mortem 清理机制。
  • 利用幻象引用和引用队列，我们可以保证对象被彻底销毁前做一些类似资源回收的工作，比如关闭文件描述符（操作系统有限的资源），它比 finalize 更加轻量、更加可靠。
  • 吸取了 finalize 里的教训，每个 Cleaner 的操作都是独立的，它有自己的运行线程，所以可以避免意外死锁等问题。
  • 幻象引用也可以进行类似链条式依赖关系的动作，比如，进行总量控制的场景，保证只有连接被关闭，相应资源被回收，连接池才能创建新的连接。