atomicreference 可安全中转异常：工作线程 catch 后 set(e)，主线程 await 完成后 get() 检查并处理；其 volatile 语义保障可见性与原子性，比普通变量更可靠、比 synchronized 更轻量，适合一次写一次读的跨线程异常传递场景。
AtomicReference 本身不直接处理异常，但它能帮助你在异常发生时安全地传递、捕获和响应异常，从而维持共享状态的一致性。关键不在于“防止异常”，而在于让异常不丢失、不被吞掉、不破坏线程协作逻辑。
AtomicReference 作为异常的“中转站”
它不是用来“捕获并吃掉”异常的容器，而是把工作线程中抛出的异常，以线程安全的方式暂存起来，供主线程后续检查和处理。这避免了因异常未被捕获导致的状态悬空或流程中断。
- 工作线程在 try-catch 中执行业务逻辑，一旦出错，调用 atomicRef.set(e) 存入异常对象
- 主线程在等待任务完成之后，调用 atomicRef.get() 检查是否有异常；若有，可重新 throw 或做定制化处理
- 因为 AtomicReference 是 volatile + CAS 实现的，所以 set/get 具有可见性和原子性，主线程一定能看到最新写入的异常
为什么不用普通变量或 synchronized？
普通变量（比如 Throwable ref）没有内存可见性保证：工作线程设置了异常，主线程可能永远读不到；synchronized 虽然能保证，但引入了锁开销和阻塞风险，而异常传递本应是低频、轻量的操作。
- AtomicReference 的 set() 是 volatile 写，get() 是 volatile 读，天然满足 happens-before 关系
- 无需加锁，无上下文切换开销，适合“一次写、一次读”的异常中转场景
- 相比 ThreadLocal，它面向的是跨线程协作，而非线程隔离
配合 CompletableFuture 或 CountDownLatch 使用更自然
单纯靠 AtomicReference 存异常还不够，你需要一种机制让主线程知道“工作线程已结束”，否则 get() 可能过早返回 null。常见做法是组合使用同步辅助类。
- 用 CountDownLatch.await() 等待子线程完成，再检查 AtomicReference 中的异常
- 用 CompletableFuture.supplyAsync().handle()，内部已封装异常传播逻辑，AtomicReference 可退居二线作兜底或日志增强
- 若需区分“正常完成”与“异常完成”，建议搭配 boolean 标志位（如 AtomicBoolean done）或统一用 CompletableFuture
注意异常对象本身的线程安全性
Throwable 是不可变对象（其字段基本 final），所以存进 AtomicReference 是安全的；但如果你自定义了带可变状态的异常子类，就要确保其字段也是 final 或线程安全的，否则可能引发新的状态不一致问题。
- 不要在异常对象里缓存非 final 的上下文数据（如 Map、List），除非它们本身是线程安全的
- 推荐在 set 异常前，先构造好完整信息（如填充 stack trace、附加诊断字段），避免多线程并发修改异常实例
- 如果异常需要携带业务上下文（如请求 ID、用户 ID），建议封装成新异常或用扩展字段（通过继承+final 字段）
