并发编程-volatile

青旅半醒 2022-10-04 14:59 245阅读 0赞

**目录**

前言：

普通 变量读写操作

然后根据这些交互操作并且结合上面的例子我们来看一下普通变量访问的流程图：

Volatile修饰变量的读写

Volitate最初的时候是使用总线锁：

Volatile实现 原理：

实现过程：

那么volatile会不会导致两个线程同时对内存中的值做修改？（volatile的实现原理）

Lock前缀指令会做两件事：

--------------------

# 前言：  #

上一篇JMM内存模型中已经提到了内存模型中提供了“缓存一致性协议”，那我们在多线程中是不是就可以实现多个线程之前修改同一个变量可见，并且线程之间可以起到隔离的效果， 为什么还要用什么 可以保证可见性的“Volatile”？

**下面我们先用一个例子来解决这个疑问？**

# **普通 变量读写操作** #

我们开启两个线程，有一个公共变量 initFlag，刚开始两个线程都会去主内存中读取initFlag，读取到的 都是false，然后线程2对initFlag修改值为 true

/**
     * @author heyufu
     * @description
     * @since 2021/6/18 11:26
     */
    public class ThreadState{
        
        private static boolean initFlag=false;
        public static void main(String[] args) throws InterruptedException {
    
    
            Thread thread=new Thread(()->{
                System.out.println("waiting..............");
                while(!initFlag){}
                System.out.println("感应到其他线程修改了变量");
            });
            Thread thread2=new Thread(()->{
                modValue();
            });
            //第一个线程开始
            thread.start();
            //让第一个线程睡足够
            Thread.sleep(3000);
            //开启第二个线程
            thread2.start();
        }
        public static void modValue(){
            System.out.println("starting..............");
            initFlag=true;
            System.out.println(test1);
        }
    }

结果：

![2021071416262834.png][]

根据运行结果可以知道：如果按照JMM可以实现内存可见性的理想情况下来说这个时候线程1应该是可以打印出System.out.println("感应到其他线程修改了变量"); 这句，但实际情况却是线程1并没有感知到 变量的修改

**所以这个例子是不是解决了开始的疑惑“有了JMM模型就可以解决线程共享变量的问题”？**

下面 在学Volatile之前来看一下JMM模型内存和工作内存的**交互操作**：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwNjMxMDYz_size_16_color_FFFFFF_t_70][]

## 然后根据这些交互操作并且结合上面的例子我们来看一下普通变量访问的流程图： ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwNjMxMDYz_size_16_color_FFFFFF_t_70 1][]

上面的流程图画的很清晰，但是当时我有一个疑惑就是线程2在修改了 initFlag变量之后会立马同步到主内存中吗？

我新加了一个线程 thread 3 来做测试；

Thread thread3=new Thread(()->{
                System.out.println("线程2修改之后我再次去拿变量，看看主内存中是否 已经修改" + initFlag);
            });
            //第一个线程开始
            thread.start();
            //让第一个线程睡足够
            Thread.sleep(3000);
            //开启第二个线程
            thread2.start();
            Thread.sleep(3000);
            thread3.start();

如果线程3读取出来的是true，那就说明线程2已经把修改的值同步到了主内存，只是线程1并没有感知到，所以他就自己很顽固，一直读取自己工作内存中的变量

结果：![20210714163534266.png][]

当我们普通写操作写完工作内存之后不会立即同步到主内存中，而是等待一个时间点来刷新到主内存，只是这个时间很快。

既然目前解决不了可见性的问题，那么我们就引入今天的主要话题：Volatile

# Volatile修饰变量的读写  #

## Volitate最初的时候是使用总线锁： ##

在一个线程写之前先对内存中的变量进行加锁，在整个线程结束之后进行释放锁，导致对一个变量的操作由并行变成了串行，这种效率太低了

我们先将变量加上Volatile修饰，再看结果：

出来了！出来了！ 这不就是我们想要的吗，说明线程1已经感受到了线程2 对内存中变量的修改

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwNjMxMDYz_size_16_color_FFFFFF_t_70 2][]

## Volatile实现 原理： ##

使用MESI缓存一致性协议（保证写到内存中的数据可以被其他cpu看到）：

## 实现过程： ##

有volatile变量修饰的变量在写操作的时候会出现 一个\#lock汇编指令，Lock前缀指令，Lock前缀指令会做两件事：

##  ##

![image.png][]

## 那么volatile会不会导致两个线程同时对内存中的值做修改？（volatile的实现原理） ##

### Lock前缀指令会做两件事： ###

1.  立马同步到主内存，会立马触发store--->write指令 并且对缓存行加锁，**在store操作之前加锁（假如这个时候会有其他线程同时加锁，那么就会进行争抢锁，谁争抢成功那么就加锁成功）**![image.png][image.png 1]
2.  开启缓存一致性协议，开启嗅探技术，保证内存缓存和内存已经其他线程的缓存在总线上保持一致，把其他线程的值设为无效

![image.png][image.png 2]

![image.png][]

到现在我们已经知道了Volatile的如何保证了多线程之间的可见性，但是光有Volatile是无法保证原子性的：

我们举个例子：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwNjMxMDYz_size_16_color_FFFFFF_t_70 3][]

当我们多个线程对同一个volatile变量做i++操作，当线程1和线程2同时拿到变量，并且同时+1操作，这个时候线程1，将内容更新到主内存，线程 2的变量失效了，再次去内存中拿变量 ，这个时候就 导致线程2的这次+1操作白做了 。可以通过 Synchronized 和  lock来保证同一时刻只有一个线程来访问该代码块

而且这个时候还会有一个问题就是当线程2来读内存 的时候就一定能确保主内存中已经同步好值了吗？ NO  NO  假如没有同步过来值，线程2不会一直等待，他会通过指令重排来执行下面的工作

这个时候就需要内存屏障了。

关于内存屏障和Synchronized请看本系列其他博客！

欢迎指点....

[2021071416262834.png]: /images/20221004/f43fb0df80a541be92f66725f7ac26bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwNjMxMDYz_size_16_color_FFFFFF_t_70]: /images/20221004/00fbd38fb293444290131fd9f4953dbf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwNjMxMDYz_size_16_color_FFFFFF_t_70 1]: /images/20221004/66eec89201e6401f8b526b9875a9eab0.png
[20210714163534266.png]: /images/20221004/9216fdf4f5d748dbb8d0d0d7871d860d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwNjMxMDYz_size_16_color_FFFFFF_t_70 2]: /images/20221004/0fbfaf1212c143cbaa060ad7cb75c444.png
[image.png]: /images/20221004/6eb343b55cc64378b0795e19a826462f.png
[image.png 1]: /images/20221004/beadb3d3e36d44e58eaabf7be06b34bd.png
[image.png 2]: /images/20221004/93808d7841b049f6b4c79249e33d9db7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwNjMxMDYz_size_16_color_FFFFFF_t_70 3]: /images/20221004/c5c17fef99e646c0944f41c4e03aa850.png