final字段的可见性依赖构造完成后的安全发布而非自动同步；必须在构造器内赋值以触发jvm内存屏障，防止重排序，确保其他线程读取时看到正确值；this逸出将破坏该保障。
final字段的可见性不是“自动同步”，而是构造完成后的发布保障
Java内存模型（JMM）中，final字段的可见性不靠锁或volatile，而是一套基于构造过程的语义契约：只要对象被“正确构造”，其他线程读到该对象引用时，就一定能看见final字段在构造器里赋的值——哪怕没加任何同步。
这背后的关键是“正确构造”：构造函数不能让this引用逸出（比如在构造中启动新线程、注册监听器、传给静态容器等）。一旦逸出，JMM不保证可见性，哪怕字段是final。
- 常见错误现象：
new FinalExample()后另一个线程调用obj.getX()偶尔返回0（默认值），说明构造过程中this已暴露 - 典型逸出场景：在构造器中调用
new Thread(() -> System.out.println(this)).start()，或把this存进static List - 验证方式：用
jstack或断点观察对象是否在<init></init>未返回前就被其他线程持有
为什么必须在构造函数里赋值？编译器和JVM双重卡死
你不能在init方法、@PostConstruct或任意后续逻辑中给final字段赋值，否则编译直接报错：variable xxx might not have been initialized或cannot assign a value to final variable。
这不是风格约定，而是JVM为实现初始化安全所依赖的硬性前提：只有构造器内写入的final字段，才能触发JVM在构造函数末尾插入StoreStore内存屏障，阻止重排序，确保写操作对所有线程“原子发布”。
- 多个构造函数时，每个分支都必须覆盖所有
final字段，否则编译失败；推荐用this(...)链式调用统一初始化 - 使用Lombok的
@RequiredArgsConstructor时，注意它只处理final和@NonNull字段，漏掉一个就会编译不过 - 反模式：
private final int x; { x = 42; }（实例初始化块）可行，但可读性差，且易与构造器逻辑割裂
final引用类型：只保地址不变，不保对象内部状态可见
final修饰引用类型（如final List<string> names</string>）时，JMM只保证“names这个变量指向的地址”对其他线程可见，绝不保证names所指ArrayList内部元素的修改能被其他线程看到。
换句话说：你能安全读到那个List对象，但往里面add元素后，别的线程可能看不到新增项——除非该List本身是线程安全的（如Collections.unmodifiableList包装，或用CopyOnWriteArrayList）。
- 容易踩的坑：以为
final Map config = new HashMap()就线程安全了，结果多线程并发put导致ConcurrentModificationException或数据丢失 - 正确做法：若需不可变集合，用
Map.of()、ImmutableList.copyOf()（Guava）或UnmodifiableCollection包装 - 性能提示：
final引用+不可变内容（如String、Integer）天然适合高并发读，无锁开销；但可变对象仍需同步
对比volatile和synchronized：final的不可替代性在哪
volatile保证每次读写都直达主内存，synchronized靠锁序保证可见性和原子性，而final只做一件事：在对象构造完成那一刻，“钉住”字段值，并让它对所有线程立即可见。它不提供运行时修改能力，也不解决复合操作问题。
所以当你设计一个配置类、DTO或实体，核心字段（如id、createdAt）一旦设定就不该变，final是最轻量、最可靠的选择——没有锁竞争，没有内存屏障开销，也没有volatile带来的重复读成本。
- 不要用
volatile代替final来初始化：它无法防止构造期间的重排序，也不能替代初始化安全性 - 不要用
synchronized保护final字段：语法上允许但逻辑冗余，JVM已为你做好了 - 真正复杂的并发状态（如计数器、状态机），
final不够用，该上AtomicInteger或ReentrantLock就得上
最常被忽略的一点：final字段的JMM保障，只在“对象被安全发布”时生效。而“安全发布”的前提是——你得确保没人能在构造器跑完前拿到这个对象。这点不靠代码规范，靠设计意识。
