为什么在多线程环境下，程序的计算结果总是不确定

关注

原创最新推荐文章于 2025-09-02 21:43:30 发布 648 阅读 AI 写同款· GEO 优化 ›

小程序多线程实战 CPU 密集型任务（如加密、图像处理）优先使用Worker 线程。轻量级异步任务可选用任务切片方案。善用性能分析工具（如小程序开发者工具的 Trace 面板）定位阻塞点。阅读详情

在多线程环境下，即便使用了完全相同的输入，程序的计算结果也常常会变得不确定，其根本原因在于操作系统对线程的“调度”本身，具有内在的、微观层面的“不可预测性”，而这种不可预测的执行时序，一旦与“对共享资源的并发修改”相结合，就会引发致命的“竞态条件”。这一问题的产生，主要涉及五大核心因素：源于多线程执行时序的“不可预测性”、多个线程对“共享资源”的并发修改、非“原子性”操作在执行中途被打断、处理器缓存与主内存之间的“可见性”问题、以及缺少必要的“同步”机制来保障操作的互斥性。

其中，多个线程对“共享资源”的并发修改，是所有不确定性问题的“犯罪现场”。例如，当多个线程，在几乎同一时刻，都去对一个共享的“全局计数器”进行“加一”操作时，这个看似简单的动作，在底层，会被分解为“读取-修改-写回”三个步骤。由于线程调度的不确定性，多个线程，可能会同时“读取”到同一个旧值，然后各自，在其基础上，进行计算和写回，最终，导致多次“加一”操作的效果，被相互“覆盖”，只相当于进行了一次，从而产生了与预期完全不符的、不确定的计算结果。

一、问题的根源、从“单行道”到“多车道高速”

要理解这个问题的本质，我们必须首先，在脑中，建立一个关于“单线程”与“多线程”程序执行流程的、清晰的对比模型。

1. 单线程的“确定性”

一个传统的单线程程序，其执行路径，就像一条“单行道”。所有的指令，都必须严格地、按照代码的书写顺序，一个接一个地，排队执行。这意味着，只要我们给予这个程序完全相同的“输入”，那么，它内部所有指令的执行“顺序”，都将是完全相同、可重复的。因此，其最终的产出，也必然是唯一、确定的。

2. 多线程的“非确定性”

与之相对，一个多线程程序，则更像一个拥有多个车道的“高速公路”。每一个线程，都像一辆独立的“汽车”，拥有自己独立的执行路径。而操作系统的“线程调度器”，则扮演着“交通总指挥”的角色。这个“总指挥”的核心职责，是根据一套极其复杂的算法（考虑了线程的优先级、等待时间、资源占用等上千个因素），来动态地、实时地，决定在下一个“微秒”，哪个“核心处理器”上，应该运行哪一辆“汽车”（线程）。

这个“调度”的过程，从我们程序员的视角来看，是高度“不确定”和“不可预测”的。我们无法，也绝不应该，去假设线程A，一定会在线程B之前，执行某段代码。正是这种执行时序上的“非确定性”，为所有并发问题的产生，埋下了伏笔。

3. “共享资源”：冲突的“引爆点”

如果多条车道上的汽车，彼此之间，永不相交，那么，即便调度是随机的，也不会产生任何问题。然而，在多线程程序中，不同的线程，常常需要，去访问和修改同一个“共享资源”。这个“共享资源”，可以是一个内存中的全局变量、一个静态对象、硬盘上的一个文件、或是一个数据库连接。

当“不可预测的执行时序”与“对共享资源的并发修改”这两个条件，同时满足时，不确定的、灾难性的计算结果，就将不可避免地发生。

二、核心“犯罪现场”：竞态条件

竞态条件，是导致多线程计算结果不确定的、最核心、也最经典的“犯罪现场”。它描述的是，一个程序的最终输出，意外地，取决于多个线程之间，无法被预知的、微秒级的“执行顺序”。

1. 一个经典的银行账户案例

假设，我们有一个银行账户，其初始余额为1000元。现在，有两个线程，分别代表了“微信支付”和“支付宝支付”，在几乎同一时刻，都试图，为这个账户，存入100元。

我们预期的、正确的结果：1000 + 100 + 100 = 1200元。

一个看似“正确”的代码实现：Java// 这是一个共享的、非线程安全的账户对象 class BankAccount { private int balance = 1000; public void deposit(int amount) { // 这行代码，是问题的根源 balance = balance + amount; } public int getBalance() { return balance; } }

2. “非原子性”操作的真相

上述代码中的 balance = balance + amount; 这行看似“简单”的语句，在被编译为底层机器指令后，它并非一个单一的、不可分割的“原子”操作。它至少，包含了三个独立的、核心的步骤：

读：从主内存中，读取 balance 的当前值（例如，1000），到中央处理器的某个临时“寄存器”中。

改：在寄存器中，将这个值，与amount（100）相加，得到1100。

写：将寄存器中，这个计算出的新值1100，写回到主内存的balance变量中。

3. “致命的交错”

因为线程调度的“不可预测性”，上述这两个线程（微信和支付宝）的、各自的“读-改-写”三部曲，其执行步骤，就可能会，以一种“致命”的方式，相互“交错”在一起。

一种可能的、灾难性的执行时序：

时刻1：微信线程，执行“读”操作。它从主内存中，读取到balance的值是1000，并存入自己的寄存器。

时刻2：此时，发生了一次线程切换！ 操作系统，暂停了微信线程的执行，转而，去执行支付宝线程。

时刻3：支付宝线程，执行“读”操作。它从主内存中，读取到的balance的值，依然是1000。

时刻4：支付宝线程，执行“改”操作，在其自己的寄存器中，计算出1000 + 100 = 1100。

时刻5：支付宝线程，执行“写”操作，将1100，成功地，写回到了主内存的balance变量中。

时刻6：此时，又发生了一次线程切换！ 操作系统，重新唤醒了微信线程，让它，从上次被暂停的地方，继续执行。

时刻7：微信线程，执行“改”操作。关键在于，它所依据的，是它在“时刻1”，就已读取到自己寄存器中的、那个“过时”的旧值1000！ 它计算出1000 + 100 = 1100。

时刻8：微信线程，执行“写”操作，将1100，再次，写回到了主内存的balance变量中。

最终结果：两次存入100元的操作，最终的账户余额，却只有1100元。其中一次“加100”的操作，被完全地、“静默地”丢失了。

三、另一个“幽灵”：内存可见性问题

除了“竞态条件”，多线程环境下，还存在一个更底层、更“诡异”的问题——内存可见性。

问题的根源：为了提升性能，现代的多核中央处理器，其每一个“核心”，都拥有自己独立的、高速的“缓存”。一个线程，在修改一个共享变量时，它可能，只是先将这个修改，写入到了自己核心的“私有缓存”中，而并没有被立即地，同步回那个所有核心都共享的“主内存”之中。

后果：此时，另一个运行在“不同核心”上的线程，在读取这个共享变量时，它可能会从自己的、那个尚未更新的“私有缓存”或“主内存”中，读取到一个“过时”的、“脏”数据。

这就导致了，一个线程，对一个变量的修改，对于另一个线程而言，是“不可见”的，或者，是“延迟可见”的。这种“可见性”问题，同样，是导致计算结果不确定的一个重要原因。

四、解决方案一：上“锁”

要解决“竞态条件”，最经典、也最通用的方法，就是引入“锁”机制。

1. 互斥锁

一个“互斥锁”，可以被理解为，一个房间的、唯一的“钥匙”。

核心思想：我们将所有对“共享资源”（如银行账户的余额）进行“读-改-写”操作的、那段“关键代码”，都“锁”在一个房间里。

执行流程：

任何一个线程，在进入这个“房间”之前，都必须，先尝试，获取这把唯一的“钥匙”。

如果获取成功，它就进入房间，执行关键代码。在此期间，其他任何试图获取钥匙的线程，都将被“阻塞”，在门外排队等待。

当该线程，执行完毕，走出房间后，它必须，将钥匙“释放”，归还出来。

然后，在门外等待的线程中，会有一个，能够成功地，获取到钥匙，并进入房间。

通过这种“一次只允许一个线程进入”的“互斥”机制，我们强制性地，将原本可能“并行交错”的多个“读-改-写”操作序列，重新地，变为了“串行”的、一个接一个的、确定性的执行。

2. 重构银行账户案例

Java

class SynchronizedBankAccount {
    private int balance = 1000;
    private final Object lock = new Object(); // 创建一个锁对象

    public void deposit(int amount) {
        synchronized (lock) { // 在进入关键代码区前，获取锁
            // 在这个代码块内，所有操作，都是线程安全的
            balance = balance + amount;
        } // 在退出代码块时，自动释放锁
    }
    // ...
}

五、解决方案二：原子操作

虽然“锁”能够有效地解决问题，但它本身，也可能会带来“性能开销”和“死锁”等新的复杂性。对于一些简单的、如“计数器加一”这样的场景，现代编程语言和硬件，提供了另一种更轻量、更高效的解决方案——原子操作。

什么是“原子操作”？：“原子”，源于其希腊语词根，意为“不可再分的”。一个“原子操作”，就是指一个由硬件层面，所保证的、在执行过程中，绝对不会被任何其他线程所“打断”的、单一的、完整的操作。

在实践中应用：几乎所有的主流语言，都提供了“原子类”或“原子函数”。例如，在Java中，我们可以使用AtomicInteger类，来安全地，进行并发计数。Javaclass AtomicBankAccount { private AtomicInteger balance = new AtomicInteger(1000); public void deposit(int amount) { // addAndGet 方法，是一个“原子”的“加法并获取”操作 balance.addAndGet(amount); } // ... } balance.addAndGet(amount)这个操作，在底层，会被编译为一条或几条特殊的、由中央处理器直接支持的“比较并交换”指令。它能够在“一个”不可分割的指令周期内，就完成“读取-修改-写回”的全部动作，从而，从根本上，杜绝了被“中途打断”的可能性。

六、在流程与规范中“防范”

除了在代码层面，使用“锁”或“原子操作”，我们还需要，在团队的流程和规范中，建立起对“并发问题”的系统性“防范”。

编码规范：团队的《编码规范》中，必须，有专门的、详尽的章节，来规定“如何处理共享可变状态”、“锁的使用最佳实践”等。这份规范，应被沉淀在知识库中，作为团队的“必修课”。

代码审查：并发相关的缺陷，是所有类型的缺陷中，最难通过“测试”来复现和发现的。因此，严格的、由经验丰富的开发者，所执行的“代码审查”，是发现潜在“竞态条件”和“死锁”问题的、最重要的“人工防线”。在代码审查流程中，审查者，应将“检查所有对共享资源的访问”，作为一个最高优先级的审查项。

使用成熟的并发库：鼓励开发者，尽可能地，使用语言或成熟框架，所提供的、经过了千锤百炼的“高级并发工具”（如线程池、并发集合、消息队列等），而避免，去手动地，实现复杂的、底层的“线程同步”逻辑。