Java中的i++操作为什么不是线程安全的？

薛定谔的盐.

于 2024-08-28 16:45:01 发布

阅读量863

点赞数 10

文章标签： java juc 线程安全多线程高并发

本文链接：https://blog.csdn.net/m0_64307465/article/details/141642850

版权

解决方案一：使用 synchronized 关键字

解决方案二：使用 AtomicInteger

解决方案三：使用 ReentrantLock

需求模拟与扩展

在Java中，i++ 是一个常见的操作符，用于将整数变量i的值增加1。虽然这个操作符看起来非常简单，但在多线程环境下，它却是线程不安全的。本文将详细探讨i++操作的线程安全问题，并提供相应的解决方案。

1. 理解`i++`操作

i++ 是一个复合操作，分为以下三个步骤：

读取当前值：从内存中读取变量i的当前值。
执行加法操作：对读取到的值执行加1操作。
写回结果：将计算后的结果写回变量i。

在单线程环境中，这三个步骤是顺序执行的，因此不会出现问题。然而，在多线程环境下，多个线程可能会同时访问并修改同一个变量i，从而导致竞态条件。

2. 竞态条件的示例

假设有两个线程（Thread A 和 Thread B），同时对变量i执行i++操作。以下是可能发生的情况：

i的初始值为5。
Thread A 读取i的值，得到5。
Thread B 也读取i的值，得到5。
Thread A 对i的值执行加1操作，结果为6，并将其写回变量i。
Thread B 也对它读取到的i的值执行加1操作，结果为6，并将其写回变量i。

最终，虽然进行了两次i++操作，i的值却仅增加了1次，最终结果仍为6。这种现象就是由于线程不安全导致的竞态条件。

3. 如何解决`i++`的线程安全问题？

需求场景：计数器的并发访问与统计

背景：

假设你正在开发一个高并发的Web应用程序，该应用程序需要统计某个API接口的访问次数。这些访问次数将被存储在一个全局的计数器中，并且每次访问时计数器的值都会增加1。由于该API可能会被大量用户同时访问，因此需要考虑计数器的线程安全问题。

需求：

统计API访问次数：每次用户访问该API时，计数器增加1。
获取当前访问次数：能够安全地读取当前的访问次数。
支持高并发：系统需要支持大量的并发请求，并且保证统计的准确性。

代码示例与问题分析：

编写一个简单的计数器类，并模拟多个线程访问该计数器。

public class Counter {
    private int count = 0;

    // 增加计数器的值
    public void increment() {
        count++; 
    }

    // 获取当前计数器的值
    public int getCount() {
        return count; 
    } 
}

编写CounterTest测试类：模拟100个线程同时访问这个计数器

public class CounterTest {
    public static void main(String[] args) throws InterruptedException {
        Counter counter = new Counter();

        // 创建100线程，每个线程调用1000次increment方法
        Thread[] threads = new Thread[100];
        for (int i = 0; i < 100; i++) {
            threads[i] = new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    counter.increment();
                }
            });
            threads[i].start();
        }

        // 等待所有线程执行完毕
        for (int i = 0; i < 100; i++) {
            threads[i].join();
        }
        // 输出最终的计数器值
        System.out.println("Final count: " + counter.getCount());
    }
}

预期结果：

理论上，我们创建了100个线程，每个线程对计数器进行了1000次的increment操作，因此最终的计数器值应该为 100 * 1000 = 100000。

实际结果：

运行代码后，你可能会发现计数器的值远小于1,000,00。这是因为i++不是线程安全的，导致多个线程可能在同一时刻读取和写入count变量，出现竞态条件。

解决方案一：使用 `synchronized` 关键字

可以通过在 increment() 方法上添加 synchronized 关键字来解决这个问题：

修改Counter类的代码：
public class Counter {
    private int count = 0;

    public synchronized void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}
这样，每次只有一个线程能够执行 increment() 方法，从而避免了竞态条件。

再次运行CounterTest类发现结果达到预期

解决方案二：使用 `AtomicInteger`

另一种方式是使用 AtomicInteger 类，该类提供了原子性的加法操作。

修改Counter类的代码：
import 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() 操作是线程安全的，并且不需要使用锁，因此在高并发情况下性能更优。

juc并发编程指的就是这个包

再次运行CounterTest类发现结果达到预期

解决方案三：使用 `ReentrantLock`

如果需要更灵活的锁控制，可以使用 ReentrantLock。

修改Counter类的代码：
import java.util.concurrent.locks.ReentrantLock;

public class Counter {
    private int count = 0;
    private final ReentrantLock lock = new ReentrantLock();

    public void increment() {
        lock.lock();
        try {
            count++;
        } finally {
            lock.unlock();
        }
    }

    public int getCount() {
        return count;
    }
}
ReentrantLock 允许显式地控制锁的获取和释放，可以用在需要复杂同步的场景中。

再次运行CounterTest类发现结果达到预期

需求模拟与扩展

synchronized 适合简单的同步需求，但可能会影响性能。
AtomicInteger 是高并发情况下的最佳选择，简洁且性能高。
ReentrantLock 适合需要复杂同步机制的场景，可以提供比 synchronized 更细粒度的控制。

这些方法各有优缺点，具体选择取决于你的需求。通过上述解决方案，能够有效避免并发情况下计数器的错误计算，保证系统的线程安全性和稳定性。