final、finally与finalize区别详解

文章小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《final、finally 和 finalize 都与“最终”有关，但用法和含义有所不同：1. final词性：形容词（adjective）或名词（noun） 含义：表示“最后的”、“最终的”，强调状态或结果。 例句：This is the final decision.（这是最终决定。）The final match will be next week.（决赛将在下周进行。）2. finally词性：副词（adverb） 含义：表示“终于”、“最终”，强调经过一段时间后发生的事情。 例句：He finally arrived after the long trip.（他长途旅行后终于到了。）We finally found the solution.（我们终于找到了解决办法。）3. finalize词性：动词（verb） 含义：表示“使最终确定”、“完成最后步骤”。 例句：We need to finalize the contract before signing.（在签署前我们需要最终确定合同。）The project was finalized last week.（这个项目上周完成了。）总结对比：| 单词 | 词性 》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

final用于定义不可变的变量、方法或类，保障不变性与安全性；finally确保异常处理中资源清理代码的执行；finalize是已被废弃的对象回收前清理方法，因不确定性与性能问题不推荐使用。

final、finally 和 finalize 这三个词，在Java（以及一些其他编程语言）的语境下，虽然长得像“三兄弟”，但它们各自扮演的角色和背后的设计哲学却截然不同。简单来说，final 关乎不变性与限制，finally 确保代码的必然执行，而 finalize 则是一个过时且不推荐使用的资源清理机制。

解决方案

这三个关键字或方法，尽管在拼写上仅一字之差，但在Java编程中却有着截然不同的用途和生命周期。理解它们的区别，是写出健壮、高效Java代码的基础。

final 关键字：final 是一个修饰符，它用来声明一个实体是“最终的”，意味着它不能被改变、重写或继承。它的作用范围非常广：

• 修饰变量： 当一个局部变量、实例变量或静态变量被 final 修饰时，它就成了一个常量，一旦被赋值，其值（对于基本类型）或引用（对于对象类型）就不能再改变。这意味着你不能给它重新赋值。对于对象引用，final 只是保证引用本身不变，对象内部的状态依然可以改变（除非对象本身是不可变的）。
• 修饰方法： 被 final 修饰的方法不能被子类重写（Override）。这通常用于确保某个方法的行为在继承体系中保持一致，或者为了实现某些设计模式（比如模板方法模式）。
• 修饰类： 被 final 修饰的类不能被继承。这意味着它不能有子类。Java标准库中许多核心类，如 String、Integer 等都是 final 类，这通常是为了安全、效率或设计上的完整性考虑。

finally 块：finally 是 try-catch-finally 语句结构中的一个代码块。它的核心作用是保证其中的代码无论如何都会被执行，无论 try 块中是否发生异常，或者 try 块是否正常结束。

• 目的： 主要用于资源清理工作，比如关闭文件流、数据库连接、网络连接等。这样可以避免资源泄漏，即使在程序执行过程中遇到意想不到的错误。
• 执行时机： finally 块会在 try 块和 catch 块执行之后，但在 try 语句（或 catch 语句）返回之前执行。即使 try 块中有 return 语句，finally 块也会先执行。只有在JVM退出或遇到System.exit()等极端情况时，finally 块才可能不会执行。

finalize() 方法：finalize() 是 java.lang.Object 类中定义的一个方法。它的设计初衷是作为对象被垃圾回收器（Garbage Collector, GC）回收前执行的“遗言”。

• 目的： 理论上，可以在 finalize() 方法中执行一些资源清理操作，比如关闭文件句柄、释放非Java内存资源等。
• 执行时机： 它是由GC在检测到对象不再被引用时，但在真正销毁对象之前，异步调用的。
• 问题： 现代Java编程中，finalize() 方法被强烈不推荐使用。原因在于其执行时机不确定、性能开销大、可能导致资源泄漏、甚至可能复活对象等诸多问题。它就像一个不可靠的“后事处理员”，你永远不知道它什么时候来，甚至它可能根本不来。

为什么说 final 是Java中实现不变性（Immutability）的关键？

在我看来，final 关键字在构建不可变对象（Immutability）方面扮演着一个基石性的角色，它不仅仅是防止变量被重新赋值那么简单，更是一种强大的设计契约。当我们说一个对象是不可变的，通常意味着它的状态在创建之后就不能再改变了。这对于编写并发程序、提高代码可读性和安全性至关重要。

final 变量是实现不可变性的核心。如果你有一个类，它的所有实例字段都被声明为 final，并且这些字段本身也是不可变类型（例如 String、Integer 等），或者它们是可变类型但通过深拷贝（defensive copying）来确保外部无法修改内部状态，那么这个对象就具备了不可变性。比如：

public final class ImmutablePoint {
    private final int x;
    private final int y;

    public ImmutablePoint(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() { return x; }
    public int getY() { return y; }

    // 没有setter方法
    // 也没有方法可以改变x或y的值
}

在这个 ImmutablePoint 例子中，x 和 y 被 final 修饰，一旦构造函数赋值后，它们的值就不能再变了。同时，类本身被 final 修饰，防止被继承，进一步巩固了其不可变性。

不可变性带来的好处是巨大的：

• 线程安全： 不可变对象天生就是线程安全的，因为它们的状态不会改变，多个线程可以同时访问而无需担心同步问题。这大大简化了并发编程。
• 可预测性： 一旦创建，对象的状态就固定了，这使得代码更容易理解和推理，减少了意外副作用的可能性。
• 缓存： 不可变对象可以安全地被缓存，因为你不需要担心它们会在缓存之外被修改。
• 哈希表键： 它们是作为 HashMap 或 HashSet 的键的理想选择，因为它们的哈希码在整个生命周期中保持不变。

所以，final 不仅仅是一个语法糖，它是一种编程思想的体现，它帮助我们构建更健壮、更易于维护的系统。

finally 块在异常处理中扮演着怎样的角色，它与 try-with-resources 有何关联？

finally 块在Java的异常处理机制中，扮演着“无论如何都要完成任务”的角色。它的主要职责是确保在 try 块（无论是否发生异常）或 catch 块执行后，某些关键的清理代码能够被执行。这对于资源管理至关重要，比如关闭文件、数据库连接、网络套接字等，以防止资源泄漏。

想象一下，如果你打开了一个文件，但在处理过程中抛出了异常，如果没有 finally 块来关闭文件，那么文件句柄就会一直被占用，最终可能导致系统资源耗尽。

一个典型的 finally 使用场景是这样的：

FileInputStream fis = null;
try {
    fis = new FileInputStream("file.txt");
    // 读取文件内容...
    // 假设这里可能抛出IOException
} catch (IOException e) {
    System.err.println("文件操作失败: " + e.getMessage());
} finally {
    if (fis != null) {
        try {
            fis.close(); // 确保文件流被关闭
        } catch (IOException e) {
            System.err.println("关闭文件流失败: " + e.getMessage());
        }
    }
}

这段代码虽然有效，但存在一些冗余，特别是关闭资源的逻辑需要嵌套 try-catch，使得代码显得有些笨重。

这时候，Java 7 引入的 try-with-resources 语句就如同救星一般出现了。它是一种语法糖，专门用来简化那些实现了 java.lang.AutoCloseable 接口的资源的自动管理。它的核心思想是：只要在 try 关键字后面的括号中声明并初始化资源，这些资源就会在 try 块执行完毕后（无论正常结束还是异常退出）被自动关闭，无需显式地编写 finally 块。

使用 try-with-resources，上面的例子可以被极大地简化和优化：

try (FileInputStream fis = new FileInputStream("file.txt")) {
    // 读取文件内容...
    // 假设这里可能抛出IOException
} catch (IOException e) {
    System.err.println("文件操作失败或关闭文件流失败: " + e.getMessage());
}

可以看到，try-with-resources 极大地提升了代码的简洁性和可读性，同时确保了资源的正确释放。它在底层其实就是编译器帮我们自动生成了一个 finally 块来关闭资源。所以，可以说 try-with-resources 是 finally 块在特定场景下的一种更优雅、更安全的替代方案，它避免了手动管理资源的繁琐和潜在错误。在现代Java编程中，只要资源实现了 AutoCloseable 接口，都应该优先考虑使用 try-with-resources。

Java的 finalize() 方法为什么被强烈不推荐使用，它有哪些潜在的问题？

finalize() 方法在Java的早期版本中，被设计为一种在对象被垃圾回收器（GC）销毁前执行清理操作的机制。听起来很美好，对吧？一个对象在“临终”前还能做点什么。但实践证明，这个方法带来的问题远多于其解决的问题，因此在现代Java编程中，它被强烈不推荐使用，甚至可以说，除非你对JVM和GC有极其深入的理解，并且有非常特殊的需求，否则永远不要碰它。

finalize() 方法的潜在问题主要体现在以下几个方面：

1. 执行时机不确定性： 这是最致命的问题。finalize() 方法的调用是由GC决定的，而GC的运行是异步的、非确定性的。你无法预测一个对象的 finalize() 方法何时会被调用，甚至不能保证它一定会被调用（比如程序在GC运行前就退出了）。这意味着你不能依赖它来释放关键资源，因为资源可能长时间得不到释放，导致泄漏。
2. 性能开销： 拥有 finalize() 方法的对象，在垃圾回收过程中需要额外的处理。GC在回收这些对象时，需要将它们放入一个特殊的队列，等待一个单独的线程去执行 finalize() 方法。这会增加GC的负担，降低回收效率，影响应用程序的整体性能。
3. 可能导致资源泄漏： 如果 finalize() 方法中出现异常，并且这个异常没有被捕获，那么这个异常会被忽略，但 finalize() 线程可能会终止，导致其他等待执行 finalize() 方法的对象永远得不到清理。
4. 对象复活（Resurrection）： 在 finalize() 方法中，你可以让一个对象重新被引用，从而阻止它被回收。这被称为“对象复活”，它使得对象的生命周期变得极其复杂和难以预测，是典型的反模式。
5. 不确定性导致的调试困难： 由于其执行时机和行为的不可预测性，一旦出现与 finalize() 相关的问题，调试将变得异常困难。你很难重现问题，也难以追踪问题根源。
6. 与现代资源管理机制的冲突： 现代Java已经有了更好的资源管理方式，比如前面提到的 try-with-resources 语句，以及更底层的 java.lang.ref.Cleaner（用于更复杂的非Java内存资源清理场景）。这些机制提供了确定性、高效且安全的资源释放方式，完全取代了 finalize() 的作用。

我的建议是：忘掉 finalize() 方法吧。 如果你需要清理资源，请使用 try-with-resources。如果资源不属于 AutoCloseable 范畴，那么请提供一个显式的 close() 方法，并在使用完毕后手动调用它。这才是确保资源被及时、正确释放的可靠途径。finalize() 就像一个被遗弃的旧工具，虽然还在那里，但已经无人问津，因为它带来的麻烦远超其价值。

到这里，我们也就讲完了《final、finally与finalize区别详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！