线程安全指多线程读写共享数据时结果始终符合预期；count++非原子，因拆为load-add-save三步，易发生竞态；volatile不解决中间插队；synchronized可快速止血；高并发宜用reentrantlock或atomicinteger。
线程安全不是“有没有锁”，而是“多线程同时读写共享数据时，结果是否始终符合预期”。只要一次运行出错（比如 count++ 本该加 10000 次却只加了 8327），就是不安全——哪怕它大多数时候看起来“没问题”。
为什么 count++ 不是原子操作？
它在 CPU 层面实际拆成三步：load（从内存读值到寄存器）、add（寄存器+1）、save（写回内存）。两个线程可能同时 load 到同一个旧值，各自 +1 后都 save，最终只加了一次。
- 现象：两个线程各执行 5000 次
count++，打印结果常为7xxx或9xxx，而非10000 - 根本原因：指令执行顺序被线程调度打乱，且 JVM 不保证这三步不可中断
- 注意：
volatile能让save立即对其他线程可见，但解决不了load→add→save中间被插队的问题
用 synchronized 最快止血
适合快速修复、逻辑简单、并发压力不大的场景。本质是给临界区加一把 JVM 内置的“互斥锁”，同一时刻只放行一个线程。
public class Counter {
private int count = 0;
// 方式1：同步方法（锁的是 this 对象）
public synchronized void increment() {
count++;
}
// 方式2：同步代码块（推荐，锁粒度更可控）
private final Object lock = new Object();
public void incrementFine() {
synchronized (lock) {
count++;
}
}
}
- 别用
public synchronized static void锁类对象，除非真要全局串行 - 避免在同步块里调用外部方法（如
System.out.println()），防止锁被意外持有过久 - 同步方法和同步代码块性能差异不大，但后者能明确锁对象，便于排查死锁
高并发或需要控制力时选 ReentrantLock 或 AtomicInteger
ReentrantLock 提供超时、可中断、公平性等能力；AtomicInteger 基于 CPU 的 CAS 指令，无锁、轻量，但仅适用于单变量简单操作。
立即学习“Java免费学习笔记（深入）”；
// ReentrantLock 示例
private final ReentrantLock lock = new ReentrantLock();
public void incrementWithLock() {
lock.lock();
try {
count++;
} finally {
lock.unlock(); // 必须在 finally 中释放
}
}
// AtomicInteger 示例
private final AtomicInteger atomicCount = new AtomicInteger(0);
public void incrementAtomic() {
atomicCount.incrementAndGet(); // 原子性保障，无需锁
}
-
ReentrantLock忘记unlock()会导致永久阻塞——务必套try/finally -
AtomicInteger的incrementAndGet()是原子的，但if (atomicCount.get() 这种“读-改-写”仍需额外同步 - 不要为了“高级感”强行用
ReentrantLock替换synchronized，JVM 对后者做了大量优化
真正容易被忽略的，是那些“看起来没共享”的状态：比如用 SimpleDateFormat 解析时间、静态工具类里缓存了 StringBuilder、甚至 ThreadLocal 忘记 remove() 导致内存泄漏——它们都在悄悄制造线程安全问题。
