今天在干嘛
volatile
MoMo Lv5
  2024-06-17 16:36:58   2025-01-08 15:27:39    

volatile是什么

volatile 关键字和const对应，一样是一种类型修饰符，用它修饰的变量表示可以被某些编译器未知的因素更改，比如操作系统、硬件或者其它线程等。遇到这个关键字声明的变量，编译器对访问该变量的代码就不再进行优化，从而可以提供对特殊地址的稳定访问。当要求使用 volatile 声明的变量的值的时候，系统总是重新从它所在的内存读取数据，即使它前面的指令刚刚从该处读取过数据。
　　
在谈及线程安全时，常会说到一个变量——volatile。在《Java并发编程实战》一书中是这么定义volatile的——“Java语言提供了一种稍弱的同步机制，即volatile变量，用来确保将变量的更新操作通知到其他线程”。这句话说明了两点：

  1. volatile变量是一种同步机制
  2. volatile能够确保可见性

volatile变量能确保线程安全性吗？为什么？

　　什么是同步机制？在并发程序设计中，各进程对公共变量的访问必须加以制约，这种制约称为同步。也就是说，同步机制即为对共享资源的一种制约。那么问题来了：volatile这种“稍弱的同步机制”是怎么制约各个进程对共享资源的访问的呢？答案就在“volatile能够确保可见性”中。

可见性

volatile能够保证字段的可见性：volatile变量，用来确保将变量的更新操作通知到其他线程。volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会返回最新写入的值。

可见性和“线程如何对变量进行操作(取值、赋值等)”有关系：

我们要先明确一个定律：线程对变量的所有操作(取值、赋值等)都必须在工作内存（各线程独立拥有）中进行，而不能直接读写内存中的变量，各工作内存间也不能相互访问。对于volatile变量来说，由于它特殊的操作顺序性规定，看起来如同操作主内存一般，但实际上 volatile变量也是遵循这一定律的。

关于主存与工作内存之间具体的交互协议（即一个变量如何从主存拷贝到工作内存、如何从工作内存同步到主存等实现细节），Java内存模型中定义了以下八种操作来完成：

lock:(锁定)，unlock(解锁)，read(读取)，load(载入)，use(试用)， assign(赋值)，store(存储)，write(写入)。

volatile 对这八种操作有着两个特殊的限定，正因为有这些限定才让volatile修饰的变量有可见性以及可以禁止指令重排序 ：

  1. use动作之前必须要有read和load动作， 这三个动作必须是连续出现的。【表示：每次工作内存要使用volatile变量之前必须去主存中拿取最新的volatile变量】
  2. assign动作之后必须跟着store和write动作，这三个动作必须是连续出现的。【表示: 每次工作内存改变了volatile变量的值，就必须把该值写回到主存中】

　　有以上两条规则就能保证每个线程每次去拿volatile变量的时候，那个变量肯定是最新的， 其实也就相当于好多个线程用的是同一个内存，无工作内存和主存之分。而操作没有用volatile修饰的变量则不能保证每次都能获取到最新的变量值。

volatile究竟能否保证线程安全性

  1. volatile能保证线程安全的情况

要使 volatile 变量提供理想的线程安全性，必须同时满足两个条件

  • 对变量的写操作不依赖于当前值。
  • 变量没有包含在具有其他变量的不变式中。

可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。大多数编程情形都会与这两个条件的其中之一冲突（如：“若没有则添加”、“若相等则移出”的复合操作等复合操作都是与①或②相冲突的），使得 volatile 变量不能像 synchronized 那样普遍适用于实现线程安全。

  1. volatile不能保证线程安全的情况

volatile并不能保证变量操作的原子性。

先以 i++（ i++ 是非原子操作）为例：

1
private volatile int i = 0

两个线程同时执行 i++，

此时是两个线程同时从主内存中拿到 i 的最新值 0 ，并且同时对 i 进行 +1 操作并将和赋值回 i，最后同时将 +1 后的 i 值写回主内存中，最终 i == 1，很明显结果是错的。

下面我们再通过更详细的代码来验证“即使变量用了volatile来修饰，才进行非原子操作时依旧会出现线程安全问题”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class Window implements Runnable {
    private volatile int ticket = 100;

    public void run() {
        for (;;) {
            //通过下面的①②两个步骤我们可以发现：对一个共享资源可以多个线程同时进行修改，自然就会有线程安全问题。
            if (ticket > 0) {
                try {
                    Thread.sleep(100);//①多个线程同时判断到“ticket>0”，然后挂起了
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                //②多个线程同时醒来，同时进行“ticket--”操作：
                System.out.println(Thread.currentThread().getName() + ":" + ticket--);
            } else {
                break;
            }
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class A03UseVolatileIsNotThreadSafe {
    public static void main(String[] args) {
        Window w = new Window();

        Thread t1 = new Thread(w);
        Thread t2 = new Thread(w);
        Thread t3 = new Thread(w);

        t1.setName("窗口1");
        t2.setName("窗口2");
        t3.setName("窗口3");

        t1.start();
        t2.start();
        t3.start();
    }
}

测试结果：

  1. 出现了大量的重复数字；
  2. 最后还输出了 “-1”；==》说明变量即使用volatile修饰了但依旧出现了线程安全问题。

代码解析：
出现问题（1）的原因：线程存在“先检查后执行”的竞态条件。可能有两个线程同时拥有CPU的执行权（机器是双核的），它们判断到做“if (ticket > 0)”，并同时做“ticket–”操作。
　　　　
出现问题（2）的原因：

  1. 当ticket==1时，两个或多个线程同时通过了“if (ticket > 0)”的判断，并进入了判断框中去执行代码；
  2. 然后它们执行到“Thread.sleep(100);”就睡了；
  3. 睡醒后总有一个线程会先抢到cpu的执行权，然后执行“ticket–”操作，并将最新的ticket数值推送告知到每个线程；
  4. 此时那些在判断框中的其他的线程并不会再次做“if (ticket > 0)”的判断，而是直接拿最新的ticket并做“ticket–”操作。

　　　　
就算线程在“ticket–”之前每次都做“if (ticket > 0)”的判断，也依旧会有线程安全问题，因为又可能出现①那种同时通过判断的状态。

1
2
3
4
5
6
// volatile的典型用法：检查某个状态标记，以判断是否退出循环。
    volatile boolean asleep;
    ……
    while（ !asleep）{
        countSomeSheep（）；
    }

一、常见说法

volatile作用

1
2
3
int i=10;
int j = i；//(1)语句
int k = i；//(2)语句

这时候编译器对代码进行优化，因为在（1）、（2）两条语句中，i 没有被用作左值。这时候编译器认为i 的值没有发生改变，所以在（1）语句时从内存中取出 i 的值赋给 j 之后，这个值并没有被丢掉，而是在（2）语句时继续用这个值给 k 赋值。编译器不会生成出汇编代码重新从内存里取 i 的值，这样提高了效率。但要注意：（1）、（2）语句之间 i 没有被用作左值才行。

1
2
3
volatile int i=10;
int j = i；//(3)语句
int k = i；//(4)语句

volatile 关键字告诉编译器 i 是随时可能发生变化的，每次使用它的时候必须从内存中取出 i 的值，因而编译器生成的汇编代码会重新从 i 的地址处读取数据放在 k 中。

所以说使用 volatile 声明的变量的值的时候，系统总是重新从它所在的内存读取数据，即使它前面的指令刚刚从该处读取过数据。精确地说就是，优化器在用到这个变量时必须每次都小心地重新读取这个变量的值，而不是使用保存在寄存器里的备份。

volatile使用场景

  1. 中断服务程序中修改的（供其它程序检测的）变量需要加 volatile；

    当变量在触发某中断程序中修改，而编译器判断主函数里面没有修改该变量，因此可能只执行一次从内存到某寄存器的读操作，而后每次只会从该寄存器中读取变量副本，使得中断程序的操作被短路（“做与不做一个样”，相当于中断对变量的操作，编译器根本不知道，编译器只是从副本中 获取“实时”的值）。

  2. 多线程应用中被几个任务共享的变量应该加 volatile；

    简单地说就是防止编译器对代码进行优化，比如如下程序：

    1
    2
    3
    4
    XBYTE[2]=0x55;
    XBYTE[2]=0x56;
    XBYTE[2]=0x57;
    XBYTE[2]=0x58;

    • 对外部硬件而言，上述四条语句分别表示不同的操作，会产生四种不同的动作，但是编译器却会对上述四条语句进行优化，认为只有XBYTE[2]=0x58（即忽略前三条语句，只产生一条机器码）。

    • 也就是说，当读取一个变量时，编译器优化有时会先把变量读取到一个寄存器中；以后，再取变量值时，就直接从寄存器中取值；当内存变量或寄存器变量因别的线程等而改变了值，该寄存器的值不会相应改变，从而造成应用程序读取的值和实际的变量值不一致 。

原理

可见性原理

当对volatile变量进行写操作的时候，JVM会向处理器发送一条Lock#前缀的指令

而这个LOCK前缀的指令主要实现了两个步骤：

  1. 将当前处理器缓存行的数据写回到系统内存；
  2. 将其他处理器中缓存了该数据的缓存行设置为无效。

原因在于缓存一致性协议，每个处理器通过总线嗅探和MESI协议来检查自己的缓存是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行置为无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存中。

缓存一致性协议：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，就会从内存重新读取。

当volatile修饰的变量进行写操作的时候，JVM就会向CPU发送LOCK#前缀指令，通过缓存一致性机制确保写操作的原子性，然后更新对应的主存地址的数据。

处理器会使用嗅探技术保证在当前处理器缓存行，主存和其他处理器缓存行的数据的在总线上保持一致。在JVM通过LOCK前缀指令更新了当前处理器的数据之后，其他处理器就会嗅探到数据不一致，从而使当前缓存行失效，当需要用到该数据时直接去内存中读取，保证读取到的数据时修改后的值。

有序性原理

volatile 的 happens-before 关系

happens-before 规则中有一条是 volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
//假设线程A执行writer方法，线程B执行reader方法
class VolatileExample {
    int a = 0;
    volatile boolean flag = false;
    
    public void writer() {
        a = 1;              // 1 线程A修改共享变量
        flag = true;        // 2 线程A写volatile变量
    } 
    
    public void reader() {
        if (flag) {         // 3 线程B读同一个volatile变量
        int i = a;          // 4 线程B读共享变量
        ……
        }
    }
}

根据 happens-before 规则，上面过程会建立 3 类 happens-before 关系。

  • 根据程序次序规则：1 happens-before 2 且 3 happens-before 4。
  • 根据 volatile 规则：2 happens-before 3。
  • 根据 happens-before 的传递性规则：1 happens-before 4。

image

因为以上规则，当线程 A 将 volatile 变量 flag 更改为 true 后，线程 B 能够迅速感知。

volatile 禁止重排序

为了性能优化，JMM 在不改变正确语义的前提下，会允许编译器和处理器对指令序列进行重排序。JMM 提供了内存屏障阻止这种重排序。

Java 编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。

JMM 会针对编译器制定 volatile 重排序规则表。

image

为了实现 volatile 内存语义时，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。

对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎是不可能的，为此，JMM 采取了保守的策略。

  • 在每个 volatile 写操作的前面插入一个 StoreStore 屏障。
  • 在每个 volatile 写操作的后面插入一个 StoreLoad 屏障。
  • 在每个 volatile 读操作的后面插入一个 LoadLoad 屏障。
  • 在每个 volatile 读操作的后面插入一个 LoadStore 屏障。

volatile 写是在前面和后面分别插入内存屏障，而 volatile 读操作是在后面插入两个内存屏障。

image

为什么不能保证原子性

在多线程环境中，原子性是指一个操作或一系列操作要么完全执行，要么完全不执行，不会被其他线程的操作打断。

volatile关键字可以确保一个线程对变量的修改对其他线程立即可见，这对于读-改-写的操作序列来说是不够的，因为这些操作序列本身并不是原子的。考虑下面的例子：

1
2
3
4
5
6
7
public class Counter {
    private volatile int count = 0;
    
    public void increment() {
        count++; // 这实际上是三个独立的操作：读取count的值，增加1，写回新值到count
    }
}

在这个例子中，尽管count变量被声明为volatile，但increment()方法并不是线程安全的。当多个线程同时调用increment()方法时，可能会发生以下情况：

  • 线程A读取count的当前值为0。
  • 线程B也读取count的当前值为0（在线程A增加count之前）。
  • 线程A将count增加到1并写回。
  • 线程B也将count增加到1并写回。

在这种情况下，虽然increment()方法被调用了两次，但count的值只增加了1，而不是期望的2。这是因为count++操作不是原子的；它涉及到读取count值、增加1、然后写回新值的多个步骤。在这些步骤之间，其他线程的操作可能会干扰。

为了保证原子性，可以使用synchronized关键字或者java.util.concurrent.atomic包中的原子类（如AtomicInteger），这些机制能够保证此类操作的原子性：

1
2
3
4
5
6
7
public class Counter {
    private AtomicInteger count = new AtomicInteger(0);
    
    public void increment() {
        count.getAndIncrement(); // 这个操作是原子的
    }
}

在这个修改后的例子中，使用AtomicInteger及其getAndIncrement()方法来保证递增操作的原子性。这意味着即使多个线程同时尝试递增计数器，每次调用也都会正确地将count的值递增1。

  1. 1. volatile是什么
  2. 2. volatile变量能确保线程安全性吗？为什么？
    1. 2.1. 可见性
    2. 2.2. volatile究竟能否保证线程安全性
  3. 3. volatile作用
  4. 4. volatile使用场景
  5. 5. 原理
    1. 5.1. 可见性原理
    2. 5.2. 有序性原理
    3. 5.3. 为什么不能保证原子性
© 2023 - 2025    MoMo
Powered by Hexo & Theme Keep
Unique Visitor Page View
  1. 1. volatile是什么
  2. 2. volatile变量能确保线程安全性吗？为什么？
    1. 2.1. 可见性
    2. 2.2. volatile究竟能否保证线程安全性
  3. 3. volatile作用
  4. 4. volatile使用场景
  5. 5. 原理
    1. 5.1. 可见性原理
    2. 5.2. 有序性原理
    3. 5.3. 为什么不能保证原子性