final、finally、finalize有什么区别？

引言

在Java编程语言中，final、finally和finalize是三个具有不同用途和语义的关键字或方法。它们在编程和面试中经常被提及，因此理解它们之间的区别是非常重要的。

题目

final、finally、 finalize有什么区别？

典型回答

• final：
  修饰类：当一个类被声明为 final 类时，意味着它不能被其他类继承，这样可以保护类的完整性和设计意图，防止外部对类的不恰当扩展。
  修饰方法：final 方法在类中声明后，子类无法覆盖或重写这个方法，确保方法的行为在派生类中始终保持不变。
  修饰变量：无论是成员变量还是局部变量，声明为 final 后，其值在初始化之后就不允许被修改。对于引用类型，final 保证了引用地址不可变，但引用的对象状态仍然可以改变。
• finally：
  在Java异常处理机制中，finally块内的代码一定会被执行，无论try块内是否有异常被捕获或是程序执行流程如何跳转。这一特性常用于资源清理场景，确保诸如数据库连接、文件流等资源在程序结束后能得到及时正确的释放，避免资源泄露。
• finalize：
  finalize 是 Object 类所提供的一个方法，其初衷是给开发者提供一个在对象即将被垃圾收集器回收之前进行最后一次清理的机会。然而，由于其执行时机不确定、可能导致性能瓶颈以及容易引起编程错误等问题，现今已不推荐使用finalize方法来管理资源，从JDK 9开始，Object类的finalize()方法被标记为deprecated。推荐的做法是利用try-with-resources语句、Cleaner类等现代Java资源管理工具来确保资源的正确释放。

加分项

final实践及注意问题

面试官除了希望了解应聘者对Java基础知识的掌握程度外，更期待听到他们对这些基础知识的个人见解和在实际项目中的应用经验。通过分享对性能优化、并发编程、对象生命周期以及垃圾收集基本过程等方面的理解，应聘者能够展现出自己的深入思考和实际操作能力，从而更全面地展示自己作为Java程序员的实力。
编程实践中充分利用final关键字来清晰表达代码的含义和逻辑目标，这一举措已在众多应用场景中展现出其优越性。
例如，通过将方法或类声明为final，开发者能够明确传达给其他团队成员及后续维护者，此类行为或功能是不可篡改的，从而确保了代码的稳定性和一致性。
深入研究Java的核心类库，我们会发现在java.lang包下，许多至关重要的类都被明智地声明为了final类。同样的现象在第三方类库的基础组件中也不鲜见，这样做有效地防止了API用户对核心功能的任意改动，从而在一定程度上加固了平台的安全性和可靠性。
此外，对于方法参数、局部变量乃至成员变量，适时使用final修饰符同样具有重要意义。这样做不仅可以明显减少因意外赋值引发的程序错误，某些编程规范甚至提倡将所有可能的情况都声明为final，以此强化代码的严谨性。
特别是在并发编程情境下，final变量具备了某种程度的不可变（immutable）特性，它能够很好地保护只读数据免受意外修改。由于final变量一旦初始化后不可再赋新值，所以在多线程环境下，程序员可以不必为final变量的同步操心，这无疑减轻了同步控制的负担，同时也规避了进行不必要的防御性复制操作，进而提升了代码的简洁性和效率。

finally实践及注意问题

finally块在Java编程实践中主要用于确保一段代码无论在何种情况下都能得到执行，特别是当代码块包含资源清理逻辑时，例如关闭数据库连接、网络套接字或者释放锁等操作。以下是finally实践中的几个重要注意事项：

1. 异常处理: finally块常与try-catch一起使用，无论try块中是否抛出了异常，finally块中的代码都将被执行。这意味着无论异常是否被捕获或传播，finally总能完成资源的正确关闭或释放。
2. 资源关闭的最佳实践：自从Java 7引入了try-with-resources语句后，对于实现了AutoCloseable接口的资源，如JDBC连接或文件流，更推荐使用try-with-resources来代替传统的try-finally结构，因为它能自动管理资源的关闭，减少了手动编写finally块的必要性，且代码更简洁。
3. 避免副作用：在finally块中，应当避免对控制流产生意想不到的副作用，例如改变程序的执行路径或提前退出程序（如使用System.exit()）。这是因为finally块的执行并不依赖于try或catch块中的逻辑，而是无条件执行的。
4. 异常抑制：在finally块中抛出异常时，如果不处理这个异常，原来try或catch块中的异常将被这个新的异常所取代，原有异常信息可能会丢失。为了避免这种情况，通常不在finally中抛出新的异常，除非是有意要忽略之前的异常并报告更重要的错误。
5. 代码执行顺序：finally块会在try和catch块执行完毕后立即执行，不受return、throw等语句的影响。但是在finally块执行完毕后，原先try或catch块中发生的异常（如果有的话）将继续向外传播。

总之，在使用finally时，应始终牢记其目的是确保资源的安全释放，同时尽可能减少对程序控制流和异常处理逻辑的干扰，以保持代码的清晰性和可读性。

finalize实践及注意问题

在Java编程中，finalize方法曾经被视为一种资源回收机制，允许对象在被垃圾收集器回收前执行最后一次清理操作。然而，由于finalize方法存在诸多问题和不确定性，业界已经广泛认同其不是一个理想的资源管理策略，并在Java 9版本中将Object.finalize()方法明确标注为过时(deprecated)。
finalize方法不推荐使用的原因主要包括：

1. 执行时间不确定：Java虚拟机（JVM）并不保证finalize方法何时会被调用，甚至可能永远不会被调用。这意味着依赖finalize方法来清理重要资源极其不可靠。
2. 性能影响严重：实现finalize方法的对象在垃圾收集过程中，会被当作特殊的对象处理，增加了GC的复杂度和延迟，可能导致性能大幅降低。
3. 容易引发死锁和挂起：由于finalize方法的执行时机与垃圾回收紧密相连，它可能在不恰当的时候被触发，从而引发死锁或者其他并发问题。
4. 不利于调试和错误处理：finalize方法中抛出的异常会被JVM默默吞掉，且无法保证其清理逻辑的执行效果，这对排查问题和确保资源释放极为不利。

相比之下，推荐使用更安全和高效的资源管理方式，如try-with-resources语句，它可以确保在资源使用完毕后立即关闭，大大减少了资源泄漏的风险。另外，对于复杂的资源清理任务，可以利用Java提供的Cleaner类，它通过PhantomReference实现了更为可控和安全的清理机制，相比finalize更可靠和易于管理。

知识扩展

final 不是 immutable？

当你声明一个变量为 final 类型时，如 final List<String> strList，它仅仅意味着你不能重新给 strList 变量赋予新的引用。换句话说，你不能将 strList 指向一个不同的 List 对象。然而，这并不意味着 strList 所指向的对象（即 List 本身）的行为受到 final 关键字的约束，因此你仍然可以往这个 List 中添加、删除元素等进行修改操作。
举例来说，尽管你创建了一个 final List：

final List<String> strList = new ArrayList<>();

你可以继续调用 add 方法往这个 List 添加元素，因为这只是修改 List 内部状态，而不是改变 strList 引用指向的地址。
若要创建一个不可变的 List，需要依赖于支持不可变行为的类或集合，如 Java 9 引入的 List.of() 方法，它返回的 List 是不可变的，因此试图对其执行添加元素的操作会抛出 UnsupportedOperationException 异常。这意味着，使用 List.of("hello", "world") 创建的 List 无法通过 add 方法添加新的元素。
为了实现一个不可变（immutable）的Java类，你需要遵循以下设计原则和步骤：

  1. 声明类为final：首先，将类声明为final，防止其他类对其进行扩展，确保类的不变性属性不能被子类破坏。
  2. 使用private final成员变量：所有的成员变量应当声明为private和final，这意味着它们一旦在构造函数中初始化后就不能再被修改。
  3. 禁用setter方法：不可变类不应该提供任何修改其状态的setter方法，确保对象创建后其内部状态永远不会再改变。
  4. 深度拷贝初始化：在构造对象时，如果成员变量是引用类型，尤其是可变对象的引用，应采取深度拷贝的方式来初始化这些成员变量，以确保即使是可变对象的内容也不会影响到不可变类实例的状态。
  5. 实现安全的getter方法：如果类需要公开其内部状态，可以通过getter方法来获取，但对于引用类型的成员变量，应谨慎处理，避免直接返回引用。在可能的情况下，可以返回成员变量的副本（浅拷贝或深拷贝），或者对于集合类等，可以返回不可变视图（如Collections.unmodifiableList()）。
  6. 考虑Copy-On-Write机制：在某些情况下，如果类需要支持修改操作，而又想保持不可变性质，可以采用Copy-On-Write（COW）策略。每当需要修改内部状态时，先创建现有对象的一个私有副本，然后在副本上进行修改操作，并返回新的不可变对象，而不是直接修改原始对象。

通过以上设计，可以确保类的实例在其整个生命周期内状态都不会发生变化，从而实现不可变性。这种不可变对象在多线程环境中尤为安全，因为它们不需要同步就能保证线程安全，并且可以轻易地作为缓存项使用，因为它们的哈希码可以在创建时计算并一直保持不变。

finalize 一无是处？

finalize方法之所以被认为是一种糟糕的实践，是因为它与垃圾收集(GC)过程紧密结合，带来了若干重大问题：

  1. 性能下降：当一个类实现了非空的`finalize`方法，该对象的垃圾收集速度会显著降低，根据基准测试，其回收速度可能会减慢几十倍之多。这意味着在高负载或内存紧张的系统中，垃圾回收会变得更加缓慢和低效。
  2. 不可预测性：`finalize`方法在对象被垃圾收集前调用，但具体的调用时间由JVM决定，具有很大的不确定性。即使通过`System.runFinalization()`方法强制执行，也不能确保所有待回收对象的`finalize`方法立刻执行完毕。
  3. 回收延迟：带有`finalize`方法的对象在垃圾收集时被当作“特殊公民”，JVM需要对它们进行额外处理，这会导致这类对象可能经历多次垃圾收集周期才得以真正回收，从而可能导致内存占用过高，增加OOM（Out Of Memory）的风险。
  4. 资源管理风险：由于垃圾收集时间的不可预测性，依赖`finalize`方法来释放关键资源是极其危险的。在高并发环境或对资源敏感的应用中，未及时释放资源会迅速耗尽系统资源，严重影响系统稳定性。

因此，专家推荐尽量避免使用finalize方法来处理资源释放，而应该采用更直接、明确的资源管理策略，如显式调用资源的close或dispose方法，或者使用Java 7引进的try-with-resources语句来确保资源的及时回收。对于高频使用的资源，更是推荐采用资源池技术以实现资源的有效重用。

finalize 替代方案？

Java平台为了克服finalize方法在资源回收方面的不足，逐渐倾向于使用java.lang.ref.Cleaner类作为替代方案。Cleaner类利用了Java中的高级内存管理机制——幻象引用（PhantomReference），这是一种特殊的弱引用，它能够在对象不可达且即将被垃圾收集器回收的“post-mortem”阶段进行清理操作。
相比于finalize，Cleaner机制具有如下优点：

  1. 更轻量级：Cleaner的实现相对于finalize而言更加轻量，不会像finalize那样显著增加垃圾回收的复杂性和延迟，从而提高了整体的性能表现。
  2. 更可靠：finalize的执行时机不确定，有时可能并不会按预期执行，而Cleaner则通过引用队列机制确保在对象被垃圾回收器清除之前执行清理操作，因此更具有可靠性。
  3. 避免死锁：Cleaner针对每个待清理的任务都有独立的运行线程，这有助于避免因finalize方法执行期间可能引发的死锁问题，提高了并发环境下的安全性。

通过Cleaner，开发者可以确保在对象被垃圾收集器最终回收之前，操作系统级别的资源（如文件描述符等）得到妥善释放，从而降低了资源泄露的风险，并提高了程序的整体健壮性和稳定性。在后续的教程或专栏中，将进一步详细介绍Java中各种引用类型，包括幻象引用及其在资源回收中的具体应用。

其它