本文探讨了Java中非线程安全代码在特定条件下可能意外地产生正确结果的现象。通过分析一个多线程计数器示例，文章解释了这种“偶然正确性”背后的原因，包括JVM、JIT编译器和硬件的优化与调度不确定性，以及Java内存模型的影响。强调了非线程安全代码缺乏行为保证的本质，并提供了使用`AtomicInteger`等机制构建真正线程安全计数器的专业解决方案，旨在纠正对并发编程的常见误解。
在Java并发编程中，线程安全是一个核心概念。当多个线程同时访问和修改共享数据时，如果不采取适当的同步措施，就可能发生竞态条件（Race Condition），导致数据不一致或程序行为异常。然而，一个常见的误解是，非线程安全的代码必然会立即表现出错误。事实上，在某些特定情况下，非线程安全的代码可能会意外地产生正确的结果，这往往给开发者带来困惑，并掩盖了潜在的并发问题。
考虑一个简单的Java计数器类，它包含一个私有整数变量和一个递增该变量的方法：
public class Counter {
private int counter = 0;
public void incrementCounter() {
counter += 1; // 这是一个复合操作：读取、修改、写入
}
public int getCounter() {
return counter;
}
}这个Counter类是典型的非线程安全示例。incrementCounter()方法看起来是原子操作，但实际上它包含了三个独立的步骤：
立即学习“Java免费学习笔记（深入）”；
当多个线程同时调用incrementCounter()时，这些步骤的执行顺序可能会被打乱，导致某些递增操作丢失。例如，线程A读取counter为0，线程B也读取counter为0。线程A将其递增到1并写入，线程B也将其递增到1并写入。最终counter的值为1，而不是预期的2。
为了模拟这种竞态条件，我们通常会使用ExecutorService和CountDownLatch来协调多个线程的启动和结束：
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class Main {
public static void main(String[] args) throws InterruptedException {
ExecutorService executorService = Executors.newFixedThreadPool(10);
CountDownLatch startSignal = new CountDownLatch(10);
CountDownLatch doneSignal = new CountDownLatch(10);
Counter counter = new Counter(); // 非线程安全计数器实例
for (int i = 0; i < 10; i++) {
executorService.submit(() -> {
try {
startSignal.countDown(); // 准备就绪
startSignal.await(); // 等待所有线程准备就绪
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
throw new RuntimeException(e);
}
counter.incrementCounter(); // 执行非线程安全递增
doneSignal.countDown(); // 完成任务
});
}
doneSignal.await(); // 等待所有任务完成
System.out.println("Finished: " + counter.getCounter());
executorService.shutdownNow(); // 关闭线程池
}
}这段代码创建了10个线程，每个线程都对同一个counter实例执行一次incrementCounter()。理论上，最终counter的值应该是10。然而，由于竞态条件，我们通常预期会看到一个小于10的值。但令人困惑的是，在某些运行环境下，上述代码可能每次都输出“Finished: 10”，这使得开发者误以为其代码是线程安全的。
为什么一个非线程安全的计数器有时会返回正确的值？这并非因为代码本身变得线程安全，而是因为非线程安全代码的本质是缺乏行为保证，而不是保证会失败。其背后的原因涉及多方面的复杂因素：
JVM、JIT编译器与硬件的优化及调度不确定性：
Java内存模型（JMM）的影响： Java内存模型定义了线程如何以及何时可以看到其他线程写入的值，以及指令的执行顺序。对于非volatile或非synchronized的共享变量，JMM不保证一个线程对该变量的修改能立即被其他线程看到。同样，它也不保证指令的执行顺序。因此，即使代码在一次运行中“碰巧”正确，也可能在另一次运行中，由于内存可见性问题或指令重排，导致结果出错。这种不确定性是其非线程安全的核心体现。
竞态条件窗口的狭窄性： 在上述计数器示例中，counter += 1的复合操作虽然包含多个步骤，但其执行时间相对较短。当线程数量不多（例如10个）且每个线程只执行一次递增时，发生冲突的“窗口”非常小。这意味着，大多数时候，一个线程可能在另一个线程尝试访问counter之前，就已经完成了整个读-改-写周期。只有在非常精确的时机下，才能触发竞态条件，导致数据丢失。
这种“偶然正确性”是并发编程中最危险的陷阱之一。它可能导致：
为了彻底消除这种不确定性，我们必须采用明确的同步机制来保证共享数据在多线程环境下的正确性。
使用synchronized关键字： 通过将incrementCounter方法声明为synchronized，可以确保同一时间只有一个线程能够执行该方法，从而避免竞态条件。
public class SynchronizedCounter {
private int counter = 0;
public synchronized void incrementCounter() {
counter += 1;
}
public synchronized int getCounter() {
return counter;
}
}使用java.util.concurrent.atomic包中的原子类： 对于简单的数值操作，Java提供了AtomicInteger、AtomicLong等原子类，它们内部使用了CAS（Compare-And-Swap）操作，可以在不使用锁的情况下保证操作的原子性，且通常比synchronized具有更好的性能。
import java.util.concurrent.atomic.AtomicInteger;
public class AtomicCounter {
private AtomicInteger counter = new AtomicInteger(0);
public void incrementCounter() {
counter.incrementAndGet(); // 原子递增操作
}
public int getCounter() {
return counter.get();
}
}使用AtomicCounter修改后的Main类如下：
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class MainAtomic {
public static void main(String[] args) throws InterruptedException {
ExecutorService executorService = Executors.newFixedThreadPool(10);
CountDownLatch startSignal = new CountDownLatch(10);
CountDownLatch doneSignal = new CountDownLatch(10);
AtomicCounter counter = new AtomicCounter(); // 使用线程安全计数器
for (int i = 0; i < 10; i++) {
executorService.submit(() -> {
try {
startSignal.countDown();
startSignal.await();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException(e);
}
counter.incrementCounter(); // 执行原子递增
doneSignal.countDown();
});
}
doneSignal.await();
System.out.println("Finished: " + counter.getCounter()); // 始终输出 10
executorService.shutdownNow();
}
}运行MainAtomic，无论在何种环境下，都将稳定地输出“Finished: 10”。
非线程安全代码有时能产生正确结果的现象，是并发编程中一个重要的学习点。它提醒我们：线程安全的核心在于提供行为保证，而不是仅仅观察到正确的结果。 程序的正确性不应依赖于JVM、JIT编译器或操作系统调度器的偶然行为。作为专业的开发者，我们必须始终遵循并发编程的最佳实践，使用synchronized、volatile、java.util.concurrent.atomic包中的原子类、锁（Lock接口）或并发集合等工具，明确地处理共享数据的访问，从而构建健壮、可预测且可靠的多线程应用。任何时候，当涉及到共享的可变状态时，都应该假定它可能在没有同步的情况下出错，并主动采取措施来防止这种情况的发生。
以上就是深入理解Java并发编程：非线程安全代码为何有时“看似”正确的详细内容，更多请关注php中文网其它相关文章！
编程怎么学习？编程怎么入门？编程在哪学？编程怎么学才快？不用担心，这里为大家提供了编程速学教程(入门课程)，有需要的小伙伴保存下载就能学习啦！
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
318
收藏
