在多线程环境下，即便使用了完全相同的输入，程序的计算结果也常常会变得不确定，其根本原因在于操作系统对线程的“调度”本身，具有内在的、微观层面的“不可预测性”，而这种不可预测的执行时序，一旦与“对共享资源的并发修改”相结合，就会引发致命的“竞态条件”。这一问题的产生，主要涉及五大核心因素：源于多线程执行时序的“不可预测性”、多个线程对“共享资源”的并发修改、非“原子性”操作在执行中途被打断、处理器缓存与主内存之间的“可见性”问题、以及缺少必要的“同步”机制来保障操作的互斥性。
其中，多个线程对“共享资源”的并发修改，是所有不确定性问题的“犯罪现场”。例如，当多个线程，在几乎同一时刻，都去对一个共享的“全局计数器”进行“加一”操作时，这个看似简单的动作，在底层，会被分解为“读取-修改-写回”三个步骤。由于线程调度的不确定性，多个线程，可能会同时“读取”到同一个旧值，然后各自，在其基础上，进行计算和写回，最终，导致多次“加一”操作的效果，被相互“覆盖”，只相当于进行了一次，从而产生了与预期完全不符的、不确定的计算结果。
一、问题的根源、从“单行道”到“多车道高速”
要理解这个问题的本质，我们必须首先，在脑中，建立一个关于“单线程”与“多线程”程序执行流程的、清晰的对比模型。
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)这个操作，在底层，会被编译为一条或几条特殊的、由中央处理器直接支持的“比较并交换”指令。它能够在“一个”不可分割的指令周期内，就完成“读取-修改-写回”的全部动作，从而，从根本上，杜绝了被“中途打断”的可能性。
六、在流程与规范中“防范”
除了在代码层面，使用“锁”或“原子操作”，我们还需要，在团队的流程和规范中，建立起对“并发问题”的系统性“防范”。
编码规范：团队的《编码规范》中，必须，有专门的、详尽的章节，来规定“如何处理共享可变状态”、“锁的使用最佳实践”等。这份规范，应被沉淀在知识库中，作为团队的“必修课”。
代码审查：并发相关的缺陷，是所有类型的缺陷中，最难通过“测试”来复现和发现的。因此，严格的、由经验丰富的开发者，所执行的“代码审查”，是发现潜在“竞态条件”和“死锁”问题的、最重要的“人工防线”。在代码审查流程中，审查者，应将“检查所有对共享资源的访问”，作为一个最高优先级的审查项。
使用成熟的并发库：鼓励开发者，尽可能地，使用语言或成熟框架，所提供的、经过了千锤百炼的“高级并发工具”（如线程池、并发集合、消息队列等），而避免，去手动地，实现复杂的、底层的“线程同步”逻辑。
常见问答 (FAQ)
Q1: “进程”和“线程”有什么区别？
A1: “进程”，是操作系统，进行资源分配的最小单位，它通常，拥有自己独立的内存空间。而“线程”，则是中央处理器，进行任务调度的最小单位，它运行在进程的“内部”，并共享其父进程的内存空间。正因为“共享内存”，才使得线程间的通信，非常高效，但也因此，而引入了“并发修改”的风险。
Q2: 什么是“竞态条件”？
A2: “竞态条件”，是指一个系统的行为或输出，意外地，取决于多个线程或进程，其无法被预知的、相对的“执行时序”。我们文中，那个因为“读-改-写”操作被“交错”执行，而导致存款丢失的银行账户案例，就是最经典的竞态条件。
Q3: “死锁”、“活锁”和“饥饿”有什么区别？
A3: 死锁，是多个线程，相互“永久阻塞”，都在等待对方释放资源。活锁，则是多个线程，都在“积极地”行动，但却因为不断地相互“谦让”，而导致，所有人都无法取得进展。饥饿，则是指某个或某些“低优先级”的线程，因为调度原因，而长时间地，无法获得执行的机会。
Q4: 是不是所有多线程程序，都一定会出现结果不确定的问题？
A4: 不是。如果一个多线程程序，其所有的线程，都只在自己的“私有数据”上进行操作，而不涉及任何“共享资源”的“修改”，那么，它的执行结果，就是确定的。不确定性，只在“并发写共享资源”这个特定的场景下，才会出现。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：百晓生，转转请注明出处：https://www.chuangxiangniao.com/p/638965.html
微信扫一扫 
支付宝扫一扫 
