AtomicReference可包装任意业务对象，但对象必须不可变或字段访问需同步；它仅保证引用更新原子性，不保障内部状态线程安全。
AtomicReference 能否直接包装任意业务对象
可以，但必须确保被包装对象是不可变的，或者所有字段访问都通过原子操作同步——AtomicReference 本身只保证“引用更新”这一操作的原子性，不保证对象内部状态的线程安全。
常见错误现象：NullPointerException 或字段值“看似更新成功却未生效”，往往是因为业务对象里有可变字段（如 int count），多个线程同时调用 obj.count++，而 AtomicReference.set() 并不介入这个过程。
- 使用场景：适合状态机类对象（如订单状态
OrderStatus）、配置快照（如AppConfig）、或整个替换逻辑明确的轻量 DTO - 若业务对象含可变字段，应改用
AtomicInteger、AtomicLongFieldUpdater等细粒度原子类型，或加锁 - 构造时建议用
new AtomicReference(new MyBizObj())，避免传入 null 引发后续compareAndSet失败却不报错
compareAndSet 的正确用法与典型误用
compareAndSet 是核心，但它不是“更新字段”，而是“用新引用替换旧引用”——前提是当前引用值等于预期旧值。它对业务对象的内容不做任何检查。
常见错误现象：两次 set() 后再 compareAndSet(old, new) 失败，因为 old 引用已失效；或误以为传入对象内容相同就能匹配，实际比的是引用地址。
- 必须用同一个对象实例作
expected参数，不能每次 new 一个内容相同的对象 - 推荐配合循环（CAS loop）使用：
MyBizObj current, next; do { current = ref.get(); next = current.withUpdatedField("xxx"); // 返回新实例 } while (!ref.compareAndSet(current, next)); - 如果业务对象没实现不可变模式（即没有
withXxx()方法返回新实例），compareAndSet几乎无法安全使用
为什么推荐用 record 或 final 字段构建业务对象
Java 14+ 的 record 天然适合被 AtomicReference 包装，因为它强制不可变、自动生成 equals/hashCode（虽 CAS 不依赖它，但调试和测试更可靠），且语义清晰。
常见错误现象：用普通 class 包含非 final 字段，开发者误以为 “只要用 AtomicReference 包一层就线程安全”，结果字段被并发修改导致数据不一致。
- 字段必须全
final，包括嵌套对象（如final List<String> tags还不够，得用ImmutableList或List.copyOf()） - 构造函数中禁止泄露
this（如注册监听器、启动线程），否则可能在对象未初始化完时就被其他线程拿到引用 - 若需兼容老版本 Java，可用 Lombok 的
@Value+ 手动设final，但需确认生成代码不含可变逻辑
性能与 GC 开销的真实影响
每次 set() 或 compareAndSet() 成功，都会创建新对象实例，旧实例进入待回收队列——高频更新时 GC 压力明显，尤其对象较大或生命周期短。
常见错误现象：吞吐量上不去，JVM 频繁 Young GC，但 CPU 不高；堆 dump 显示大量同类型业务对象实例。
- 避免在每毫秒级请求中更新
AtomicReference<BigReportData>，考虑降频、合并更新、或改用环形缓冲区 + 单写线程 - 若只是读多写少（如配置刷新），GC 影响极小，可放心用
- 注意
get()无开销，但频繁get().getField()仍要承担对象字段访问成本，别误以为“原子引用=零成本”
