Java线程安全必须显式控制，不能靠避免；共享非final字段、单例/Bean状态、非线程安全集合、非原子读改写操作均需同步；volatile仅保可见性与有序性，不保原子性；优先用java.util.concurrent工具类；ThreadLocal通过副本绕过共享，但需防内存泄漏。
Java 中线程安全问题不能靠“避免”来解决，只能靠“显式控制”——不加同步、不加约束、不考虑共享状态，就一定会出错。
什么时候必须处理共享变量的并发访问
只要多个线程同时读写同一个 Object 实例字段（尤其是非 final 的可变字段），且未做同步，就存在线程安全风险。典型场景包括：
- 单例类中持有可变状态（如缓存
Map、计数器int count） - Servlet 或 Spring Bean（prototype 除外）中保存请求间共用的字段
- 使用
ArrayList、HashMap等非线程安全集合存放跨线程共享数据 - 对
long或double字段执行非原子的读-改-写操作（如i++）
volatile 能解决哪些问题，不能解决哪些
volatile 只保证可见性和禁止指令重排序，不保证原子性。它适用于：
- 纯状态标志位：如
volatile boolean shutdownRequested - 单次写入、多次读取的配置项（写后不再改）
- 作为
double-checked locking中的实例引用（配合final字段）
但它不能用于：
立即学习“Java免费学习笔记（深入）”；
-
counter++这类复合操作（读+加+写三步，非原子） - 依赖前值的逻辑判断：
if (flag && !processed)中两个volatile字段无法构成原子条件 - 对象内部状态变更（
volatile List list只保证 list 引用可见，不保证 list 内容线程安全）
用 synchronized 还是 java.util.concurrent 工具类
优先选 java.util.concurrent 提供的线程安全组件，它们在多数场景下性能更好、语义更清晰：
- 计数器 → 用
AtomicInteger，而非synchronized(this) { count++; } - 共享列表 → 用
CopyOnWriteArrayList（读多写少）或ConcurrentHashMap（高并发读写） - 需要锁逻辑 → 优先用
ReentrantLock（支持超时、中断、公平性），而不是synchronized块（不可中断、无超时） - 简单互斥 →
synchronized方法/块仍最轻量，尤其在锁竞争低、临界区极短时
注意：ConcurrentHashMap 的 size() 和 isEmpty() 返回的是近似值；遍历时若需强一致性，应先 clone() 或用 keySet().toArray() 快照。
ThreadLocal 是线程安全的“捷径”吗
ThreadLocal 不解决共享问题，而是绕过共享——为每个线程提供独立副本。适用场景有限：
- 绑定线程生命周期的上下文（如用户身份、事务 ID、数据库连接）
- 避免频繁创建临时对象（如
SimpleDateFormat）
但要注意：
- Web 容器中线程常被复用（如 Tomcat 线程池），
ThreadLocal必须在请求结束时remove()，否则可能内存泄漏 - 父子线程不自动继承值，需用
InheritableThreadLocal（且仅限创建时） - 它不适用于需要线程间协作或聚合统计的场景
真正难的不是选哪个工具，而是识别“哪些状态真的被多个线程共享”。很多并发 bug 源于误判——以为某个字段只在当前请求内使用，实际却被异步任务、定时器或回调跨线程访问了。
