final修饰变量、方法、类分别实现引用/值不可变、禁止重写、禁止继承；但final仅是不可变性的必要条件，非充分条件，需配合private、无修改方法、防御性拷贝等才能实现真正不可变。
final修饰变量：值不可变，但对象内容可能变
声明为 final 的变量只能赋值一次，编译期就锁定其引用（对引用类型）或值（对基本类型）。这不是“深不可变”，只是禁止重新赋值。
-
final List<string> list = new ArrayList();</string>合法 —— 可以调用list.add("a")，因为list引用没变，只是对象内部状态变了 -
final int x = 10;后再写x = 20;会报编译错误：cannot assign a value to final variable x - 局部
final变量常用于 lambda 表达式中捕获 —— Java 要求“effectively final”，即即使没写final，只要没被重新赋值，也能在 lambda 中使用
final修饰方法：禁止子类重写，但不影响重载
final 加在方法声明上，表示该方法不能被任何子类覆盖。这是运行时多态的边界控制手段，和 private 不同，final 方法仍可被继承、调用、重载。
- 常见误判：以为
final void print() {}会让子类无法定义同名方法 —— 错。子类可以写void print(String s) {}（重载），也可以写static void print() {}（隐藏），只是不能写@Override void print() {} - 性能影响极小：JVM 曾对
final方法做内联优化，但现在 JIT 已足够智能，是否加final对性能几乎无差别 - 典型场景：模板方法模式中，
templateMethod()常设为final，确保骨架不被破坏；工具类中的核心逻辑方法也常用final防止意外覆盖
final修饰类：彻底关闭继承，强制组合优于继承
类被声明为 final 后，任何类都无法 extends 它，连匿名子类都不行。这不只是语法限制，更是设计契约：该类的实现细节即公共 API，不应也不许被扩展。
-
String、Integer、LocalDateTime等 JDK 不可变类全部是final—— 因为它们的不可变性依赖于没有子类能绕过构造逻辑或篡改内部状态 - 反模式：给一个本该开放扩展的业务类加
final，后续想通过继承定制行为时只能重构或引入代理，成本陡增 - 注意兼容性：一旦发布
final类，后续版本中无法撤回 —— 即使加了@Deprecated，也不能改成非final，否则破坏二进制兼容
final与不可变性的关系：它只是必要条件，不是充分条件
很多人以为“用了 final 就安全了”，其实不然。真正实现不可变（immutable）需要一整套约束：
立即学习“Java免费学习笔记（深入）”；
- 类本身
final - 所有字段
private且final - 不提供修改字段的 setter 或其他可变方法
- 如果字段是可变对象（如
ArrayList），必须防御性拷贝（defensive copy）—— 构造时复制入参，getter 返回副本而非原引用
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; }
// ❌ 错误：若存在 setX()，哪怕字段 final，也破坏不可变性（编译不过，但说明设计意图）
}
最易忽略的一点：final 字段在构造器中未完成初始化（比如被 try-catch 绕过、或依赖未初始化的其他字段），会导致部分构造（partially constructed）对象逸出 —— 这在多线程下尤其危险。
