并发编程为什么会出问题？

现代计算机为了提高计算机的整体能力，操作系统做出了以下努力：

• CPU增加了缓存

CPU对于数据的计算速度远远高于从内存中存取数据的速度，为了缓和CPU与内存之间的速度差异，计算机的制造商为CPU增加了缓存

• 操作系统增加了进程和线程

为了解决单任务执行的效率瓶颈，提升系统资源管理和并发能力，操作系统引入的进程和线程

• 优化CPU指令执行顺序

我们写的并发程序在操作系统上运行时，对于CPU缓存的使用可能会不太合理，造成CPU缓存的浪费，为了使CPU的缓存能够得到更加合理的利用，编译程序对CPU上指令的执行顺序进行了优化

那么，这样做会有什么问题呢？我们以java语言来阐述一下，先来看看java的内存模型：

Java内存模型规定了所有的变量都存储在主内存（物理内存）中，每条线程还有自己的工作内存，线程对变量的所有操作都必须在工作内存中进行。不同的线程无法访问其他线程的工作内存里的内容。

• 缓存（java线程的工作内存）带来的可见性问题

在这个例子中，即使线程2将flag设为false，线程1可能仍然看不到这个变化，导致无限循环。这是因为flag变量没有被正确同步，线程1可能一直读取的是自己工作内存中的缓存值。

• 线程切换带来的原子性问题

这个例子计算结果并不是期望的20000。count++大致可以分成三步CPU指令：

指令1：把变量count从内存加载的CPU寄存器。

指令2：在寄存器中执行count++操作。

指令3：将结果写入缓存（可能是CPU缓存，也可能是内存）

线程t1将count=0加载到CPU的寄存器后，假如此时发生了线程切换。此时内存中的count值仍然为0，线程t2将count=0加载到寄存器，执行count++操作，并将count=1写到内存。此时假如CPU切换到线程t1，执行线程t1中的count++操作后，线程t1中的count值为1，线程t1将count=1写入内存，此时内存中的count值最终为1,而不是期望的2。所以，如果在CPU中存在正在执行的线程，恰好此时CPU发生了线程切换，则可能会导致原子性问题，这也是导致并发编程频繁出问题的根源之一。

• 指令重排带来的有序性问题

在Java程序中，一个经典的案例就是使用双重检查机制来创建单例对象。例如，在下面的代码中，在getInstance()方法中获取对象实例时，首先判断instance对象是否为空，如果为空，则锁定当前类的class对象，并再次检查instance是否为空，如果instance对象仍然为空，则为instance对象创建一个实例

对于上面的instance=new SingletonDemo代码来说，会有3个CPU指令与其对应。

• 分配内存空间。
• 初始化对象。
• 将instance引用指向内存空间。

正常执行的CPU指令顺序为1—>2—>3，CPU对程序进行重排序后的执行顺序可能为1—>3—>2。在多线程获取单例时，就会出现问题。

线程B获得了未初始化完成的对象。

Java如何解决多线程三大难题？

可见性问题的解决方案是volatile关键字。它就像给变量加了实时同步功能，任何修改都会立即刷新到主内存，并让其他线程的工作内存失效。

原子性问题需要synchronized或原子类。synchronized像给代码段加锁，确保同一时间只有一个线程执行。原子类如AtomicInteger则利用CAS(Compare-And-Swap)机制实现无锁线程安全。

指令重排问题通过内存屏障解决。volatile和synchronized都会插入特定屏障，阻止某些重排序。

JAVA内存模型规范

java内存模型是一个非常复杂的规范，Java内存模型中引入了Happens-Before原则来保证多线程环境下操作之间的可见性和顺序性，确保程序执行的正确性。

Happens-Before原则:

• 【原则一】程序次序规则

在一个线程中，按照代码的顺序，前面的操作Happens-Before于后面的任意操作，这个规则比较符合单线程的思维：在同一个线程中，程序在前面对某个变量的修改一定是对后续操作可见的。

• 【原则二】volatile变量规则

对一个volatile变量的写操作，Happens-Before于后续对这个变量的读操作

• 【原则三】传递规则

如果A Happens-Before B，并且B Happens-Before C，则A Happens-Before C

• 【原则四】锁定规则

对一个锁的解锁操作 Happens-Before于后续对这个锁的加锁操作

在进入synchronized代码块之前，会自动加锁，在代码块执行完毕后，会自动释放锁，假设有这样一段程序运行在syncgronized代码块中将变量x的值，假如有线程A获取到锁执行完synchronized代码块之后将x变量的值修改为10，并释放synchronized锁。当线程B进入synchronized代码块时，能够获取到线程A对x变量的写操作，也就是说，线程B访问到的x变量的值为10。

• 【原则五】线程启动规则

如果线程A调用了线程B的start()方法来启动线程，则start()操作Happens-Before于线程B中的任意操作

• 【原则六】线程终止规则

线程A等待线程B的完成(在线程A中调用了线程B的join方法)，线程B完成后，线程A可以看到线程B对共享变量的修改

• 【原则七】线程中断规则

对线程interrupt()方法的调用Happens-Before于被中断线程的代码检测到中断事件的发生

例如

上面的程序代码。在主线程中中断线程B之前，将共享变量x的值修改为100，则当线程B检测到中断事件时，访问到的x变量的值为100

• 【原则八】对象终止规则

一个对象的初始化完成Happens-Before于它的finalize()方法的开始

Happens-Before规则的核心作用

• 可见性保障：若操作A happens-before操作B，则A对共享变量的修改对B可见2。
• 禁止重排序：编译器/处理器需遵守规则顺序，避免破坏语义的重排序。
• 跨线程同步：通过锁、volatile等机制建立线程间操作顺序约束

Happens-Before规则底层实现：

主要依靠内存屏障指令：

• 硬件级屏障 CPU指令集提供的内存屏障指令
• 禁止屏障前后的指令重排，
• 强制刷新缓存，写操作后强制刷新到主内存，读操作前清空本地缓存

volatile特性

volatile关键字在Java中提供了两大核心保证：

• 可见性保证：对volatile变量的修改立即对所有线程可见
• 有序性保证：禁止指令重排序

volatitle实现机制：

volatile写操作底层伪指令

mov [flag], 1 ; 写操作

sfence ; StoreStore屏障 - 保证普通写完成

mfence ; StoreLoad屏障 - 刷新到主内存并阻塞后续读

volatile读操作底层伪指令

lfence ; LoadLoad屏障 - 阻塞后续读直到完成

mov eax, [flag] ; 读操作

lfence ; LoadStore屏障 - 阻止读后操作重排序

使用注意事项

volatile不保证复合操作原子性

如:

volatile int count = 0;

count++; // 非原子操作，需要synchronized或AtomicInteger

count++实际包含3个非原子步骤：

1. 读取count值到寄存器

2. 寄存器值+1

3. 写回主内存

volatile的内存屏障只能保证可见性和有序性，无法阻止多个线程同时进入临界区，当多线程并发执行时，可能出现两个线程同时读取到相同初始值，导致最终结果少加

建议使用场景：

仅当需要跨线程可见性时使用volatile

1，状态标志位（最常用）

适用于需要跨线程通信的简单状态控制，如线程启停控制

public class TaskController {

private volatile boolean running = true;

public void stop() {

running = false; // 修改立即对所有线程可见

}

public void execute() {

while (running) { // 安全读取最新状态

// 执行任务

}

}

}

2，双重检查锁定（DCL单例模式）

上文有使用示例

synchronized的深度解析

synchronized是Java实现线程同步的核心机制，通过内置的监视器锁(Monitor)保证代码块或方法的原子性、可见性和有序性。其核心特性包括：

• 原子性：确保同一时刻只有一个线程能执行同步代码块
• 可见性：线程释放锁前会将共享变量刷新到主内存
• 有序性：防止编译器和处理器对同步代码块内的指令重排序

三种基本使用方法：

1. 实例方法同步（锁当前对象实例）

public synchronized void method() {...}

2. 静态方法同步（锁Class对象）

public static synchronized void staticMethod() {...}

3. 同步代码块（锁指定对象）

public void blockMethod() {

synchronized(lockObj) {...}

}

synchronized实现原理：

synchronized 修饰的代码块编译为 monitorenter 和 monitorexit 指令

监视器（Monitor）是 Java 中实现线程同步的底层机制，每个 Java 对象都可关联一个 Monitor，每个 Monitor 包含三个关键队列：

• Owner：持有锁的线程指针（初始为 null)
• EntryList：竞争锁失败的阻塞线程队列（BLOCKED 状态）
• WaitSet：调用 wait() 后进入等待的线程队列（WAITING 状态）

锁竞争流程:

线程执行monitorenter指令时尝试获取monitor的 所有权，过程如下：

如果monitor的进入数为0，则该线程进入monitor成为Owner，然后将进入数设置为1,如果该线程已经是Owner，只是重新进入，进入数加1，如果其它线程已经是monitor的Owner，则该线程进入EntryList阻塞。直到monitor的进入数为0，再重新尝试获取monitor的所有权

执行monitorexit的线程必须是monitor的Owner

指令执行时，monitor的进入数减1，如果减1后进入数为0，则释放锁，唤醒 EntryList 线程非公平竞争。

这里顺便提一下，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify/notifyAll等方法，否则会抛出
java.lang.IllegalMonitorStateException的异常的原因。

线程协作

• 线程调用 wait() 释放锁并进入 WaitSet；
• 其他线程调用 notify() 将 WaitSet 线程移回 EntryList

注意:jdk1.6后，synchronized的实现经历了多次优化升级，即锁升级

无锁 → 偏向锁 → 轻量级锁 → 重量级锁（关联 Monitor）

后续专门写文章细说