在java并发编程中，非线程安全的代码并非总会立即表现出错误，有时甚至会“偶然”产生正确的结果，这可能导致开发者对潜在的竞态条件产生误解。本文通过一个经典的非线程安全计数器示例，探讨了为何在特定环境下，即使缺乏同步机制，程序也可能返回预期值，并强调了理解并发编程中“无保证”与“必然失败”之间区别的重要性，以及如何正确构建线程安全的应用。
在多线程环境中，当多个线程同时访问和修改同一个共享的可变状态时，如果没有适当的同步机制，就可能导致数据不一致或不可预测的结果，这种现象被称为竞态条件（Race Condition）。线程安全是指当多个线程访问某个类时，不管运行时环境采用何种调度方式或者这些线程将如何交错，这个类都能表现出正确的行为。
一个常见的例子是简单的整数自增操作 counter += 1。尽管在高级语言中看起来是一个单一的操作，但在底层它通常包含三个步骤：
如果两个线程同时执行 counter += 1，并且它们的执行时序发生交错，例如：
最终 counter 的值将是1，而不是预期的2。这就是典型的丢失更新问题，是竞态条件的一种表现。
立即学习“Java免费学习笔记（深入）”；
为了演示上述竞态条件，我们通常会编写一个非线程安全的计数器类，并使用多线程对其进行操作。以下是一个典型的示例代码：
Counter.java
public class Counter {
private int counter = 0;
public void incrementCounter() {
counter += 1; // 非原子操作
}
public int getCounter() {
return counter;
}
}Main.java
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 {
// 创建一个固定大小为10的线程池
ExecutorService executorService = Executors.newFixedThreadPool(10);
// 用于协调线程启动和结束的CountDownLatch
CountDownLatch startSignal = new CountDownLatch(10);
CountDownLatch doneSignal = new CountDownLatch(10);
// 非线程安全的计数器实例
Counter counter = new Counter();
// 提交10个任务到线程池
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() 方法一次。由于 incrementCounter() 方法没有进行任何同步，我们预期在并发执行时，最终的 counter 值可能小于10（例如，由于丢失更新）。然而，在实际运行中，许多开发者可能会惊讶地发现，程序最终总是输出 Finished: 10，即得到了“正确”的结果。
这种“意外正确”的行为，往往会给初学者带来困惑，甚至产生“非线程安全代码在某些情况下也能正常工作”的错误认知，从而埋下潜在的系统隐患。
非线程安全代码之所以有时能产生正确的结果，并非因为它本身是线程安全的，而是因为竞态条件的出现具有不确定性。以下是导致这种“意外正确”的几个关键因素：
非线程安全并非“必然失败”： 缺乏正确的同步机制，意味着程序不保证其行为的正确性，但不代表它在所有情况下都必然失败。竞态条件是否显现，取决于线程的调度、执行时序以及底层硬件和JVM的具体实现。在某些特定的运行条件下，线程的交错方式可能恰好避免了冲突，使得结果看起来是正确的。
执行环境的偶然性：
JIT编译器优化（谨慎说明）： Java的即时编译器（JIT）会对代码进行优化，以提高执行效率。这些优化包括指令重排、消除死代码等。JIT编译器在遵守Java内存模型（JMM）规则的前提下进行优化。对于非同步的代码，JMM提供的保证非常宽松，这意味着JIT编译器有更大的自由度来重排或优化指令。虽然JIT编译器不会“修复”非线程安全代码使其变得线程安全，但在某些特定情况下，其优化策略可能会使得竞态条件不易被观察到。例如，如果 counter += 1 的操作非常简单且局部性强，JIT可能将其优化为更紧凑的机器码，从而减少了线程切换时发生冲突的可能性。
为了确保计数器在多线程环境下的正确性，我们必须引入适当的同步机制。以下是两种常见的实现方式：
synchronized 关键字可以用于方法或代码块，确保在任何给定时间只有一个线程可以执行被同步的代码。
public class SynchronizedCounter {
private int counter = 0;
// 使用 synchronized 关键字修饰方法，确保同一时间只有一个线程能访问此方法
public synchronized void incrementCounter() {
counter += 1;
}
public synchronized int getCounter() {
return counter;
}
}在 Main 类中将 Counter 替换为 SynchronizedCounter 即可。这种方法简单直观，但 synchronized 锁的粒度较大，可能会在某些高并发场景下影响性能。
Java并发包（java.util.concurrent）提供了 Atomic 系列类，如 AtomicInteger、AtomicLong、AtomicReference 等，它们通过底层的CAS（Compare-And-Swap）操作实现了无锁的原子性操作，通常比 synchronized 具有更好的性能和更细粒度的控制。
import java.util.concurrent.atomic.AtomicInteger;
public class AtomicCounter {
private AtomicInteger counter = new AtomicInteger(0);
// 使用 AtomicInteger 的原子性方法进行增量
public void incrementCounter() {
counter.incrementAndGet(); // 原子性地将当前值加一
}
public int getCounter() {
return counter.get(); // 原子性地获取当前值
}
}在 Main 类中将 Counter 替换为 AtomicCounter 即可。AtomicInteger 是实现线程安全计数器的推荐方式，因为它在保证原子性的同时，避免了显式锁带来的开销和潜在死锁问题。
本文通过一个经典的非线程安全计数器示例，揭示了并发编程中一个常见的误区：非线程安全的代码并非必然失败，有时在特定环境下可能表现出“意外的正确性”。然而，这种“正确”是偶然的、不可靠的，它掩盖了潜在的竞态条件，为系统埋下了隐患。理解竞态条件发生的偶然性，以及JVM、操作系统和硬件对并发行为的影响，对于编写健壮、可靠的并发程序至关重要。始终坚持对共享可变状态进行显式同步，并优先使用Java并发包提供的工具，是确保线程安全和程序正确性的黄金法则。在并发编程的世界里，“没有错误不代表没有问题”，深入理解其原理并遵循最佳实践，才是构建高质量并发应用的关键。
以上就是Java非线程安全计数器为何有时表现“正确”？深入理解并发编程的隐蔽陷阱的详细内容，更多请关注php中文网其它相关文章！
编程怎么学习？编程怎么入门？编程在哪学？编程怎么学才快？不用担心，这里为大家提供了编程速学教程(入门课程)，有需要的小伙伴保存下载就能学习啦！
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
199
收藏
