在Java里什么是线程安全_Java安全访问概念说明_技术教程

线程安全指多线程读写共享数据时结果始终符合预期；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 指令，无锁、轻量，但仅适用于单变量简单操作。

// 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 对后者做了大量优化