JAVA热门面试题（八）-优快云博客

本文链接：https://blog.youkuaiyun.com/jun778895/article/details/140516535

final、finalize和finally是Java编程中容易混淆但具有不同用途和意义的三个关键字/方法。下面是它们之间的不同之处：

1. final

用途：final用于声明属性（变量）、方法和类，分别表示属性不可改变（常量）、方法不可被覆盖（重写）、类不可被继承。
详细说明：
- 当一个变量被声明为final时，它必须被初始化，并且这个值在之后不能被改变。
- 一个被声明为final的方法不能被任何子类重写。
- 一个被声明为final的类不能被继承，即不能有子类。

示例：

final int MAX_VALUE = 100; // final变量
public final void display() { // final方法
    // 方法实现
}
public final class MyClass { // final类
    // 类实现
}

2. finalize

用途：finalize是java.lang.Object类的一个方法，用于在垃圾收集器决定回收某对象之前调用该方法，供垃圾收集时的其他资源回收，例如关闭文件等。
详细说明：
- finalize方法的设计初衷是在对象被垃圾收集之前执行一些清理操作。
- 但是，在JDK 9中，finalize方法已被标记为弃用（deprecated），因为它的执行时机是不确定的，且可能导致性能问题。
- 子类可以覆盖（重写）finalize方法，但通常不推荐这样做，因为依赖finalize方法进行资源清理是不安全的。

示例（尽管不推荐使用，但展示其结构）：

@Override
protected void finalize() throws Throwable {
    super.finalize();
    // 清理代码
}

3. finally

用途：finally是异常处理语句结构的一部分，表示无论是否发生异常，finally块中的代码都会被执行。
详细说明：
- finally块通常用于执行必要的清理工作，如关闭文件流、释放资源等。
- 无论try块中的代码是否抛出异常，finally块都会执行，除非JVM在执行try或catch块时退出（如通过System.exit()）。
- 如果在try或catch块中有return语句，finally块仍然会执行，但return语句会在finally块执行完毕后才执行。

示例：

try {
    // 尝试执行的代码
} catch (Exception e) {
    // 异常处理代码
} finally {
    // 无论是否发生异常都会执行的代码
}

总结

关键字/方法	用途	详细说明	示例
final	声明不可变性	声明属性、方法或类为不可改变、不可覆盖或不可继承	`final int MAX_VALUE = 100;`
finalize	垃圾收集前的清理	在对象被垃圾收集前执行清理工作，但已被弃用	`@Override protected void finalize() throws Throwable {...}`
finally	异常处理中的清理	无论是否发生异常，都执行的代码块	`try {...} catch (...) {...} finally {...}`

Java中的编译期常量是什么？

Java中的编译期常量（compile-time constant）指的是在程序编译时可以确定其值的常量。这些常量在编译时被计算并替换为其具体的值，因此它们在运行时不会再次计算。编译期常量通常使用final关键字和基本数据类型（如int、char、double等）或String类型声明，并且可以是静态（static）的。例如：

public class Example {
    public static final int MY_CONSTANT = 42; // 编译期常量
}

在上面的示例中，MY_CONSTANT是一个编译期常量，因为它在编译时期已知并且不会在运行时改变其值。编译器会将编译期常量的值内联到代码中，因此在运行时，这些值已经被直接替换为实际值，而不是通过引用获取。

使用编译期常量有什么风险？

尽管编译期常量在Java中有很多优点，如提高性能、增强代码可读性和避免运行时错误等，但它们的使用也存在一些风险，主要包括：

硬编码问题：
- 如果编译期常量的值在多个地方使用，并且以后需要更改，那么你需要在所有使用该常量的地方手动更新它们，这可能会导致维护问题。特别是当常量值在大型项目中频繁使用时，这种手动更新可能会变得非常繁琐和容易出错。
降低代码可读性：
- 不适当地使用编译期常量可能会降低代码的可读性。例如，如果一个常量的含义不明确，那么代码的读者可能不容易理解它的作用。此外，如果在多个地方定义相同的编译期常量，那么每个常量的值都会在类文件中被硬编码，可能会导致冗余代码和不必要的复杂性。
版本兼容性问题：
- 如果一个编译期常量被其他代码引用，并且你更改了它的值，那么依赖它的代码可能需要重新编译以适应新的值。这可能导致版本兼容性问题，尤其是在大型项目中，不同模块或组件之间可能存在相互依赖关系。
不适用于所有情况：
- 并非所有值都适合用作编译期常量。只有在编译时就可以确定其值的表达式才能用作编译期常量。如果一个值需要在运行时根据外部条件变化，那么使用编译期常量可能不是最佳选择。