多线程读写共享变量出错是因为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），在硬件层面保证「比较并更新」是一条不可分割的指令。
立即学习“Java免费学习笔记（深入）”；
-
AtomicInteger.incrementAndGet()本质是循环尝试 CAS，失败就重试，无锁但线程安全 - 适合简单计数、状态标志等场景；不适合复合逻辑（比如「先读再判断再改」这类非原子业务）
- 注意：
getAndIncrement()返回的是旧值，incrementAndGet()返回新值——容易混淆
AtomicInteger counter = new AtomicInteger(0); int newValue = counter.incrementAndGet(); // 线程安全的 +1 并返回结果
过度同步或同步粒度太粗会带来什么问题
最直接后果是吞吐量骤降，甚至比单线程还慢——所有线程排队串行执行，失去了并发的意义。
- 把整个方法用
synchronized包裹，但其实只有 2 行涉及共享数据，其余都是本地计算 - 多个无关的共享变量共用一把锁（比如用
this锁同时保护userCache和logQueue） - 在同步块里调用外部服务（如 HTTP 请求、DB 查询），导致锁持有时间不可控
真正该做的，是识别临界区，只锁必要代码段，并优先考虑无锁结构（如 ConcurrentHashMap）、线程局部变量（ThreadLocal）或不可变对象。
