Java多线程共享数据无标准解，需依读写关系与一致性要求选volatile（仅单写多读简单状态）、AtomicXXX（无锁原子操作）、synchronized/ReentrantLock（复杂临界区）或避免共享（ThreadLocal、不可变对象）。
Java 多线程共享数据本身没有“标准解”，关键看你要共享什么、谁读谁写、是否要求实时一致——选错方式轻则结果错乱，重则死锁或 ConcurrentModificationException。
用 volatile 修饰简单状态标志位
适用于：只有一个线程写、多个线程只读的布尔开关或计数器（如 running、shutdownRequested）。
它不保证复合操作原子性，比如 counter++ 即使加了 volatile 依然线程不安全。
-
volatile禁止指令重排序，能确保可见性，但不提供互斥 - 不能用于
long或double的非原子写（虽然 HotSpot 实际已保证，但规范不保证） - 别试图用它替代
synchronized或AtomicInteger来做累加
用 AtomicInteger / AtomicReference 做无锁计数或引用更新
适用于：需要原子增减、CAS 更新、且不想加锁的场景，比如请求计数、状态机跳转、无锁栈/队列节点指针。
立即学习“Java免费学习笔记（深入）”；
底层依赖 CPU 的 CAS 指令，失败时会自旋重试，高竞争下可能浪费 CPU。
-
getAndIncrement()是原子的，但get() + 1不是 -
compareAndSet(expected, updated)返回boolean，必须检查返回值判断是否成功 -
AtomicReference可以安全替换整个对象引用，但对象内部字段仍需自行同步
用 synchronized 或 ReentrantLock 保护临界区
适用于：多线程读写同一块内存（如 HashMap、自定义缓存、银行账户余额），且逻辑较复杂无法拆成原子操作。
这是最通用也最容易出错的方式——锁范围过大拖慢性能，过小又漏掉共享点。
- 优先用
synchronized方法或代码块，比显式ReentrantLock更简洁、不易忘unlock() - 锁对象必须是所有线程共用的同一个实例，别用
this在单例中没问题，但在每次 new 出来的对象里就失效了 - 避免嵌套锁或跨方法持锁，尤其不要在锁内调用外部可重入的、可能再申请锁的方法
避免共享：用 ThreadLocal 或不可变对象
真正安全的共享，其实是“不共享”。很多场景你以为必须共享，其实只是没分清状态归属。
ThreadLocal 不是为线程间传值设计的，它是线程隔离的副本；而 final 字段 + 不可变类（如 String、LocalDateTime）天然线程安全。
-
ThreadLocal比全局共享一个SimpleDateFormat安全得多 -
ThreadLocal用完记得remove()，尤其在线程池中，否则可能引发内存泄漏 - 构造不可变对象时，所有字段必须
final，且不暴露可变内部状态（如不返回ArrayList的原始引用）
真正难的不是选哪个工具，而是画清数据边界：这个变量到底被哪些线程访问？读多还是写多？是否允许短暂不一致？很多人一上来就加锁，结果发现只是忘了把 ArrayList 换成 CopyOnWriteArrayList，或者根本不需要共享。
