17370845950

多线程读写共享变量出错是因为JVM允许线程缓存变量到工作内存，导致可见性问题和竞态条件；count++非原子、volatile不解决原子性、synchronized与ReentrantLock机制不同；AtomicInteger依赖CAS硬件指令实现无锁线程安全；过度同步会严重降低吞吐量。

多线程读写共享变量为什么会出错

因为 JVM 允许线程把变量缓存在自己的工作内存（如 CPU 寄存器、L1/L2 缓存）里，不及时刷回主内存。一个线程改了 count，另一个线程可能一直读到旧值——这不是 bug，是 Java 内存模型（JMM）的默认行为。

典型表现：启动 10 个线程各执行 1000 次 count++，最终 count 却小于 10000。

• count++ 不是原子操作：它包含「读取 → 修改 → 写入」三步，中间可能被其他线程打断
• 即使加了 volatile，也只能保证可见性，不能解决竞态条件（race condition）
• 没有同步时，JIT 编译器还可能重排序指令，进一步加剧不可预测性

synchronized 和 ReentrantLock 的核心区别在哪

两者都能保证原子性和可见性，但机制和灵活性不同：

• synchronized 是 JVM 层面的内置锁，自动加锁/释放（即使抛异常），但只能非公平、不可中断、不支持超时
• ReentrantLock 是 API 层的显式锁，需手动调用 lock() 和 unlock()（建议放在 try-finally 中），但支持公平锁、可中断、带超时的 tryLock()
• 性能上，JDK 6+ 后两者差距极小；选择依据主要是控制粒度和功能需求，不是“哪个更快”

public void safeIncrement() {
    lock.lock();
    try {
        count++;
    } finally {
        lock.unlock(); // 必须放 finally，否则死锁风险
    }
}

为什么 AtomicInteger 不需要 synchronized 就能线程安全

它依赖 CPU 提供的底层原子指令（如 x86 的 CAS — Compare-And-Swap），在硬件层面保证「比较并更新」是一条不可分割的指令。

• AtomicInteger.incrementAndGet() 本质是循环尝试 CAS，失败就重试，无锁但线程安全
• 适合简单计数、状态标志等场景；不适合复合逻辑（比如「先读再判断再改」这类非原子业务）
• 注意：getAndIncrement() 返回的是旧值，incrementAndGet() 返回新值——容易混淆

AtomicInteger counter = new AtomicInteger(0);
int newValue = counter.incrementAndGet(); // 线程安全的 +1 并返回结果

过度同步或同步粒度太粗会带来什么问题

最直接后果是吞吐量骤降，甚至比单线程还慢——所有线程排队串行执行，失去了并发的意义。

• 把整个方法用 synchronized 包裹，但其实只有 2 行涉及共享数据，其余都是本地计算
• 多个无关的共享变量共用一把锁（比如用 this 锁同时保护 userCache 和 logQueue）
• 在同步块里调用外部服务（如 HTTP 请求、DB 查询），导致锁持有时间不可控

真正该做的，是识别临界区，只锁必要代码段，并优先考虑无锁结构（如 ConcurrentHashMap）、线程局部变量（ThreadLocal）或不可变对象。