17370845950

Java并发数据一致性需依场景选同步机制：synchronized控临界区，volatile保可见性非原子性，Concurrent包提高效线程安全组件，CAS适用低冲突场景但有ABA等问题。

Java中保证并发下的数据一致性，核心在于控制多个线程对共享资源的访问顺序与可见性。不是简单加锁就能解决，关键要看场景：是读多写少？是否涉及复合操作？有没有跨多个变量的逻辑一致性？选对同步机制比盲目用synchronized更重要。

用synchronized保护临界区

synchronized是最基础也最常用的同步手段，它能确保同一时刻只有一个线程执行被修饰的代码块或方法。注意它锁定的是对象（实例方法锁this，静态方法锁Class对象），不是代码本身。

• 优先使用同步代码块而非同步整个方法，减少锁粒度，提升并发度
• 避免在同步块内调用外部可变对象的方法，防止锁外泄和死锁
• 不要用String、Integer等常量池对象作为锁，它们可能被其他代码意外共享

volatile解决可见性，不解决原子性

volatile关键字保证变量的修改对所有线程立即可见，并禁止指令重排序，但它不能保证复合操作的原子性。比如i++（读-改-写三步）即使i是volatile，依然可能出错。

• 适合用在状态标志位上，如isRunning = true/false
• 适用于“一写多读”且写操作不依赖当前值的场景
• 不能替代synchronized处理count++、map.put()这类非原子操作

用java.util.concurrent工具类简化并发控制

JDK提供的并发包封装了大量经过验证的线程安全组件，比手写同步更可靠、更高效。

• 计数类用AtomicInteger代替int，支持compareAndSet、incrementAndGet等原子操作
• 集合类优先选ConcurrentHashMap、CopyOnWriteArrayList，它们内部做了细粒度锁或不可变设计
• 复杂业务逻辑可用ReentrantLock配合Condition实现灵活等待/通知，支持可中断、超时、公平性等特性

无锁编程与CAS的适用边界

基于CAS（Compare-And-Swap）的原子类和AQS框架是Java并发的底层支柱。但CAS不是银弹——存在ABA问题、循环时间长导致CPU占用高、只能保证单变量原子性等问题。

• AtomicStampedReference可用于规避ABA问题（给变量加版本戳）
• CAS适合冲突较少的场景；高竞争下考虑分段计数（如LongAdder）或降级为锁
• 不要试图用多个AtomicReference拼出“逻辑原子性”，应封装为一个CAS-safe的自定义类或改用锁

不复杂但容易忽略的是：一致性不只是线程安全，还包括事务边界、缓存一致性、分布式场景下的最终一致等延伸问题。本地并发控制只是第一步。