Java多线程数据安全解决方案

i++不是原子操作，因其被拆分为读取、计算、写回三步，多线程下易发生竞态导致结果错误；volatile仅保可见性不保原子性；synchronized、AtomicInteger、ThreadLocal等是常用线程安全方案。

多线程读写共享变量时，i++ 为什么不是原子操作？

因为 i++ 实际拆成三步：读取 i 的值 → 计算 i + 1 → 写回新值。多个线程可能同时读到相同旧值，各自加 1 后写回，导致最终只加了一次。

常见现象是：10 个线程各执行 1000 次 i++，结果远小于 10000；或者日志中出现重复 ID、计数跳变、ConcurrentModificationException 等。

• 不要依赖“看起来没出错”来判断线程安全——竞态条件（race condition）具有随机性和不可复现性
• volatile 能保证可见性，但不能解决复合操作的原子性问题（如 i++、list.add()）
• 局部变量天然线程安全；对象实例字段/静态字段才是风险点

用 synchronized 锁住临界区是最直接的控制方式

它通过 JVM 的 monitor 机制确保同一时刻只有一个线程能进入被保护的代码块或方法，适合逻辑清晰、争用不激烈的场景。

public class Counter {
    private int count = 0;
    public synchronized void increment() {
        count++; // 这里是原子的
    }
    public synchronized int getCount() {
        return count;
    }
}

• 锁对象必须一致：方法级 synchronized 锁的是当前实例（this），静态方法锁的是类对象（Counter.class）
• 避免锁整个方法体——只包裹真正需要同步的语句，否则会严重拖慢吞吐量
• 不要用 String 或常量池对象（如 "lock"）作锁，容易被外部误用导致锁失效或死锁

java.util.concurrent 包里的工具类更适合高并发场景

当需要频繁读写、或对性能敏感时，ReentrantLock、AtomicInteger、ConcurrentHashMap 等比 synchronized 更灵活高效。

• AtomicInteger 用 CAS（Compare-And-Swap）实现无锁原子更新，适用于简单计数：counter.incrementAndGet()
• ReentrantLock 支持可中断、超时、公平锁等特性，但需手动 lock()/unlock()，忘记 unlock() 会导致死锁
• ConcurrentHashMap 不是“线程安全的 HashMap”，而是分段锁 + CAS 的高性能实现，get() 完全无锁，put() 只锁对应桶
• 避免把 ArrayList 或 HashMap 包裹在 synchronized 块里使用——它们本身不提供迭代器一致性保障，仍可能抛 ConcurrentModificationException

ThreadLocal 是隔离数据而非共享数据的思路

它为每个线程提供独立副本，彻底规避竞争。典型用途是保存用户上下文、数据库连接、格式化器（如 SimpleDateFormat）等非线程安全对象。

private static final ThreadLocal DATE_FORMAT =
    ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

• 每次调用 get() 都返回当前线程专属实例，无需同步
• 务必在业务结束时调用 remove()，尤其在线程池场景下，否则会造成内存泄漏（ThreadLocalMap 中的 key 是弱引用，value 不是）
• 不能用于传递参数或跨线程通信——子线程不会自动继承父线程的 ThreadLocal 值，需显式使用 InheritableThreadLocal

真正难处理的从来不是单个变量的增减，而是跨多个对象、多步骤事务的一致性。比如“扣库存 + 记日志 + 发消息”这三步，即使每步都加了锁，整体仍可能因异常或顺序问题出错。这时候得靠分布式锁、消息队列幂等、本地事务表这些更高层机制，而不是盯着 synchronized 补丁。