final不是实现不可变的银弹，它仅保证引用不被重赋值，不阻止对象内部状态改变；需配合不可变类型、防御性拷贝、final类/方法及完整封装才能真正实现不可变。
Java 里的 final 关键字不是为“实现不可变”而生的银弹，它只是不可变设计中一个**必要但不充分**的工具——没它，不可变几乎不可能；有它，也不代表对象真的不可变。
为什么加了 final 字段，对象还是能被修改？
常见误解是：只要字段声明为 final，对象就不可变。错在忽略了引用类型和可变状态的分离。
比如：
class BadImmutable {
final List<String> items;
BadImmutable() {
this.items = new ArrayList<>();
this.items.add("oops"); // ✅ 合法：final 只锁住引用，不锁住对象内部
}
}
final 保证的是 items 这个变量不能再指向另一个 List 实例，但不阻止你调用 items.add() 或 items.clear() —— 因为底层 ArrayList 本身是可变的。
立即学习“Java免费学习笔记（深入）”；
- 真正需要的是：字段本身是
final+ 所引用的对象也必须是不可变类型（如String、Integer）或防御性拷贝（defensive copy） - 对集合类，常用
Collections.unmodifiableList()包装，或直接用java.util.ImmutableCollections（Java 10+ 的List.of()） - 构造器里若接收外部传入的可变对象，必须做深拷贝或不可变封装，否则“不可变”形同虚设
final 方法和类如何防止继承导致的契约破坏？
不可变性依赖行为契约的稳定。如果子类重写方法改变了字段逻辑或暴露了内部可变状态，不可变就崩了。
例如：
final class Point {
final int x, y;
Point(int x, int y) { this.x = x; this.y = y; }
// 没有 setter，且类不能被继承 → 外部无法绕过构造器注入可变逻辑
}
- 声明
final class阻止继承，避免子类添加可变字段或重写关键方法 - 声明
final方法（尤其getter）可防子类返回伪造值或缓存失效，但更关键的是配合私有字段 + 无 setter 的封装模式 - 注意：
final类不能被 mock（除非用Mockito inline），测试时需权衡——不可变优先级高于测试便利性时，接受这点限制
final 局部变量和参数在 lambda 和并发中的实际作用
Java 8+ 要求 lambda 中引用的局部变量必须是“实际上的 final”（effectively final），这不是语法糖，而是为了线程安全和内存模型一致性。
比如：
void process() {
final String id = "123"; // ✅ 可用于 lambda
Runnable r = () -> System.out.println(id); // 安全：JVM 确保该值不会被其他线程改写
String name = "alice";
Runnable r2 = () -> System.out.println(name); // ✅ 也合法（effectively final）
name = "bob"; // ❌ 编译错误：一旦赋值后就不能再改，否则 lambda 引用会失效
}
- 这个限制本质是让 JVM 能安全地把变量值“捕获”进 lambda 对象，避免闭包持有对栈帧的引用（栈帧可能已销毁）
- 在并发场景中，
final字段还触发了 JSR-133 内存模型的“final 字段语义”：构造器结束时，所有final字段的值对其他线程可见，无需额外同步 - 但注意：仅限
final字段本身；若字段是数组或对象，其元素/内部状态仍可能被并发修改
最常被忽略的一点：不可变 ≠ 把所有字段标 final 就完事。它是一整套协作机制——构造器封死入口、字段 final 锁定引用、类型选不可变或做防御拷贝、类声明 final 阻断继承、文档明确承诺不可变语义。少一环，就可能在某个边界场景被悄悄打破。
