Java原子操作中一个隐蔽的并发问题与解决方案-优快云博客

Java原子操作中一个隐蔽的并发问题与解决方案

前言

作为一名普通的Java开发者，日常开发中经常会遇到各种并发问题。虽然我们经常使用java.util.concurrent.atomic包中的原子类来处理多线程环境下的数据一致性问题，但有时候看似简单的代码也会埋下一些不易察觉的陷阱。这篇文章将记录我在项目中遇到的一个关于AtomicInteger的并发问题，以及如何一步步排查和解决这个问题的过程。

问题现象

在项目中有一个计数器功能，用于统计用户的访问次数，每次用户访问时会调用一个方法增加计数。起初，这个逻辑看起来很简单，代码如下：

public class Counter {
    private AtomicInteger count = new AtomicInteger(0);

    public void increment() {
        count.incrementAndGet();
    }

    public int getCount() {
        return count.get();
    }
}

在单线程环境下测试没有问题，但在高并发场景下，发现部分请求的计数出现了不一致的情况，比如实际访问次数比预期少。这明显不是预期的行为，于是开始深入排查。

问题分析

首先，我怀疑是不是多线程环境下AtomicInteger的incrementAndGet()方法存在问题。但根据Java文档，AtomicInteger是线程安全的，应该能够保证原子性操作。因此，问题可能出在其他地方。

接着，我查看了调用increment()方法的地方，发现有些地方并没有使用同步机制，而是直接调用了该方法。例如，在一个异步任务中调用了counter.increment()，而没有加锁。不过，既然AtomicInteger是线程安全的，那不应该有问题。

为了进一步验证，我写了一个简单的压力测试程序，模拟多个线程同时调用increment()方法，并记录最终结果。测试结果显示，某些情况下计数确实比预期少。

这时候，我开始怀疑是否是JVM的内存模型或编译优化导致的问题，或者是否存在其他隐藏的竞态条件。

排查步骤

第一步：检查代码逻辑

首先，我重新检查了Counter类的实现，确认incrementAndGet()是线程安全的，而且没有其他修改count值的地方。这部分代码看起来没问题。

第二步：添加日志输出

为了更直观地观察问题，我给increment()方法添加了日志输出，打印每次调用时的当前值和新值，例如：

public void increment() {
    int current = count.get();
    int next = current + 1;
    boolean success = count.compareAndSet(current, next);
    if (!success) {
        System.out.println("CAS failed: current=" + current + ", next=" + next);
    }
}

通过这种方式，我发现在某些情况下，compareAndSet()返回了false，说明CAS失败了。这表明在并发环境中，多个线程同时尝试更新同一个值，导致部分更新被覆盖。

第三步：分析CAS失败原因

CAS（Compare and Set）失败通常意味着在读取值之后、写入之前，另一个线程已经修改了该值。虽然AtomicInteger的incrementAndGet()内部使用了CAS操作，但它的实现并不是直接调用compareAndSet()，而是通过循环不断重试直到成功。因此，理论上不会出现“丢失更新”的情况。

但是，在我的测试中，还是出现了部分计数丢失。这让我开始怀疑是否有其他因素干扰了CAS操作。

第四步：检查JVM版本和配置

我检查了运行环境的JVM版本，发现使用的是Java 8u202。虽然这个版本是稳定的，但我也尝试升级到Java 11，看看是否能解决问题。然而，问题依然存在。

第五步：引入性能监控工具

为了更深入地了解问题，我使用了JVisualVM进行性能分析，观察线程状态和锁竞争情况。结果发现，虽然没有显式的锁，但某些线程在等待CAS操作完成，这表明并发压力较大，导致CAS失败率较高。

第六步：重构代码逻辑

考虑到AtomicInteger本身是线程安全的，我决定尝试替换为AtomicLong，并观察是否还有类似问题。结果发现，问题依旧存在。

第七步：使用`AtomicReference`代替

为了进一步排查，我尝试将计数器改为使用AtomicReference来包装一个整数对象，例如：

public class Counter {
    private AtomicReference<Integer> count = new AtomicReference<>(0);

    public void increment() {
        while (true) {
            Integer current = count.get();
            Integer next = current + 1;
            if (count.compareAndSet(current, next)) {
                break;
            }
        }
    }

    public int getCount() {
        return count.get();
    }
}

这种实现方式与AtomicInteger的底层逻辑相似，但结果依然相同，说明问题并非出在AtomicInteger本身。