Java线程安全是什么？安全访问详解

Java线程安全的本质并非简单地“加锁”，而是确保多线程并发读写共享数据时结果始终符合预期——哪怕99%的时间看似正常，只要一次出现count++少加、时间解析错乱或内存泄漏等异常，就已暴露不安全；文章深入剖析了count++非原子性的底层原因（load-add-save三步可被中断），指出volatile无法解决竞态，synchronized适合快速修复但需注意锁粒度与风险，而高并发场景下ReentrantLock和AtomicInteger各具优势；更关键的是提醒开发者：真正的隐患往往藏在那些“看似无共享”的地方——如SimpleDateFormat、静态StringBuilder缓存、ThreadLocal未清理等，稍不留神就会引发难以复现的并发Bug。

线程安全不是“有没有锁”，而是“多线程同时读写共享数据时，结果是否始终符合预期”。只要一次运行出错（比如 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 对后者做了大量优化

真正容易被忽略的，是那些“看起来没共享”的状态：比如用 SimpleDateFormat 解析时间、静态工具类里缓存了 StringBuilder、甚至 ThreadLocal 忘记 remove() 导致内存泄漏——它们都在悄悄制造线程安全问题。

好了，本文到此结束，带大家了解了《Java线程安全是什么？安全访问详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！