optional本身线程安全，因其不可变；但与volatile配合不当、共享可变对象或在parallelstream中非安全收集会导致线程安全问题。
Optional 本身是线程安全的，但它的使用场景往往引入线程安全风险——关键不在类本身，而在你怎么用它。
Optional 实例天然线程安全
Optional 是不可变（immutable）的 final 类，内部 value 字段只读，没有可修改状态。多个线程同时读取同一个 Optional 实例（比如调用 isPresent()、orElse()、map()）完全不会出问题，无需同步。
这意味着：
- 你把一个 Optional
常量或配置对象在多线程间共享读取，没问题 - 每次调用 ofNullable(user) 生成的新 Optional 都是独立实例，彼此隔离
- 链式操作如 .map().filter().orElse() 全是无副作用的纯函数式调用，线程安全
真正踩坑的地方：和 volatile / 引用更新配合不当
常见于配置热加载、缓存刷新等异步变更场景。比如：
你声明了一个字段：private volatile Optional
监听器收到新配置后执行：currentConfig = Optional.ofNullable(newConfig);
这看似安全，但要注意：
- volatile 保证引用更新的可见性，但不保证 newConfig 对象自身构造完成（比如 Config 内部字段未完全初始化）
- 如果 newConfig 是从远程拉取并部分解析的半成品，直接 ofNullable 就包装，业务层 map 访问时仍可能 NPE
- 正确做法是：确保 newConfig 完全构建成功（如校验必填字段）、再原子替换 volatile 引用
绝对禁止的线程不安全用法
这些不是 Optional 的锅，而是误用导致的并发隐患：
-
把 Optional 当共享可变容器：比如用 static Optional
buffer，然后多线程调用 .get().append(...) —— get() 返回的对象本身可能被并发修改，Optional 并不保护它 - 在 parallelStream 中返回 Optional 并 collect 到共享集合：例如 numbers.parallelStream().map(x -> Optional.of(x * 2)).forEach(list::add)，list 非线程安全，会出 ConcurrentModificationException
-
用 Optional 包装可变对象并在多线程中反复 set：比如 private Optional
- > items; + items = Optional.of(new ArrayList())；后续多个线程往这个 list 里 add —— Optional 不提供任何同步，list 本身才是风险点
热加载场景下的安全模式
这是 Optional 最易被问及线程安全的典型上下文，推荐组合方案：
- 用 volatile 修饰 Optional 引用（如 private volatile Optional
configRef） - 监听器内完成 newConfig 的完整构建与验证，再用 ofNullable 一次性封装
- 业务读取统一走 configRef.map(Config::getTimeout).orElse(3000)，不暴露原始 Config 实例
- 避免在 map 链中调用有状态方法（如 new Date()、Random.nextInt()），防止隐式共享
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
