不可变对象模式通过消除可变状态从源头避免竞态条件，使锁变得不必要；其核心是对象创建后所有字段（含引用）不可修改、final保障可见性、任何“更新”均返回新实例，从而实现天然线程安全。
不可变对象模式不是“绕开锁”，而是让锁变得没必要——因为没有可变状态，就没有竞态条件的土壤。它不靠同步机制压制并发冲突，而是从源头上消灭冲突发生的前提。
核心逻辑：为什么不可变就能免锁？
多线程安全问题本质是多个线程对同一块可变内存的读写冲突。而不可变对象满足三个关键事实：
- 对象创建后，所有字段（含引用）对外不可修改；
- final 字段保证初始化完成时值已写入主内存，JVM 内存模型天然保障可见性；
- 没有 setter、没有内部状态变更方法，任何“更新”都必须返回一个新实例。
这意味着：多个线程可以同时读取同一个不可变对象，无需同步；哪怕各自持有不同版本（如 v1、v2、v3），也不会互相干扰——它们只是不同的只读快照。
真正落地的不可变，不止加 final 那么简单
仅把字段标为 private final 还不够。常见破绽包括：
- 字段是
ArrayList或Date等可变类型，且 getter 直接返回原始引用； - 构造函数中
this提前泄露（如注册监听器、启动线程、传给静态容器）； - 类未声明为 final，子类可能覆写方法或暴露可变行为；
- 未对引用类型做防御性拷贝（如构造时 new Date(rawDate.getTime())，getter 也返回 new Date(…)）。
例如：public final List 是危险的；应改为 return List.copyOf(roles)（Java 10+）或 new ArrayList(roles)。
如何用不可变对象支撑高频读 + 低频写场景
典型如配置中心、路由表、用户权限快照等——读远多于写，且写操作需整体生效、强一致性。
- 用 volatile 引用指向当前不可变实例（如
private static volatile Config CURRENT）； - 写操作（如热更新）构造全新不可变对象，再原子替换引用：
CURRENT = new Config(newData)； - 所有读线程看到的要么是旧快照，要么是新快照，绝不会看到“半更新”状态；
- 配合
CopyOnWriteArrayList或ImmutableList（Guava）可进一步简化集合类不可变封装。
适用边界与务实提醒
不可变对象不是银弹。它适合以下情况：
- 状态变更频率低（避免 GC 压力过大）；
- 单次变更涉及多个关联字段（天然保证原子性）；
- 需作为 Map 的 key 或参与缓存哈希计算；
- 团队能接受“更新=新建+替换”的思维转换。
若对象生命周期极短、变更频繁（如每毫秒更新的传感器数据），或内存受限，应权衡创建成本。此时可结合对象池或混合策略（如外层不可变 + 内部状态由专用线程管理）。
