前言

假期完结，开始下班了，又是丧气满满的一天，还好有花Gie的文章陪伴，不然我会寂寞到死的（臭不要脸）。

多线程曾经介绍了三篇多线程的很多知识点了，还没有看过的小伙伴记得花点工夫看下，本系列都是从浅到深，逐渐递进，不要想一口吃个瘦子哦，小心虚胖（手动狗头）。

狗剩子：花GieGie~，来这么早。

我：文章还没写完呢，还有一堆小伙伴等着我呢，必定来得早啊。

狗剩子：那你还在这蹲坑

我：.......

本章完结就要完结Java内存模型的解说了，虽说完结，然而前面会始终贯通在各个知识点中，多线程比拟根底的知识点解说的差不多了,本文正式引入了对volatile的剖析，接下来的几章也会对线程池、CAS、ThreadLocal、原子类、AQS、并发汇合等逐渐解说，看完这一系列，谁还能与你争锋（仍旧狗头护体）。

啪啪啪...看我如何打脸

注释

我：狗儿，你昨天提及了主内存和工作内存，上次介绍有点太糙了，明天能够再认真说一下嘛

好的呀，我都依你。

说到JMM主内存和工作内存，咱们就必须要先理解一下CPU缓存构造。

Core0、Core1代表两个核

L1：每个核上有两个L1, 一个用于存数据（Data Cache），一个用于存指令（Instruction Cache）

先看上图，CPU存在三级缓存L1/L2/L3，你可能会想CPU是闲着没事干，设计那么多层内存干啥，间接从主存（物理内存）中读写数据他不香吗，这样就省事多了。然而咱们要思考一下，CPU办事效率十分高，处理速度和物理内存相比不在同一个层级，如果CPU每次的读写都间接和主存交互，这样会大大降低指令的执行速递，这也就引出了这三级缓存。

a = a + 1

举个简略的栗子，当线程执行这个语句时，会先从主存当中读取变量a的值，拷贝到高速缓存中，而后CPU执行指令对变量a进行加1操作，并将数据写入缓存，最初将高速缓存中变量a批改后的值刷新到主存当中。

拓展：线程在获取数据时首先会在最快的缓存中（L1）找数据，如果缓存没有命中(Cache miss) 则往下一级找, 直到三级缓存都找不到时，那只有向内存（Main Memoy）查找数据了，未命中的次数越多，耗时也就越长。

我：那这个和咱们JMM的内存构造有什么关系嘞？

Java作为一门高级语言，屏蔽了这些底层细节，而是JMM定义了一套读写内存的标准。在JMM中，主内存和工作内存并非真正意义上的物理划分，而是JMM的一种形象，它将L1、L2以及寄存器形象成工作内存，每个处理器只能进行独享，而L3、RAM形象成主内存，在处理器之间进行共享。

JMM对于主内存/工作内存的束缚：

  • 所有变量存储在主内存中，每个线程领有本人的工作内存，工作内存中的变量是主内存中拷贝的正本；
  • 线程不能间接操作主内存，只能通过批改本地内存，而后本地内存同步到主内存；
  • 线程之间不能间接进行通信，只能通过主内存进行直达；
  • 正是因为线程间这种通信形式，加上线程之间通信是有延时的，这也就导致了可见性问题。
我：咱们有什么方法能够解决可见性问题吗？

咱们能够通过happens-before准则来解决可见性问题。

我：（粗率了，竟然没有听过）那...那能够说说这个具体是指什么吗？

happens-before具体是指什么呢，我举个栗子：动作A产生在动作B之前，那动作B必定可能看见动作A，这就是happens-before准则。

如果还是感觉很形象，那咱们再看个反例：两个线程（线程1、线程2），对于线程1执行的货色，线程2有时能够看到但有时候又看不到，这种状况下就不具备happens-before。这里看过花Gie蹲坑系列文章的小伙伴，应该能够想到上篇文章咱们解说过可见性的一个案例，呈现第四种状况，b=3，a=1的状况时《蹲坑也能进大厂》多线程系列-Java内存模型精讲，正是因为不具备happens-before准则。

我：说了happens-before，那它都有哪些利用呢？

这里先简略的列举一下，小伙伴们大抵理解一下happens-before波及到的范畴有哪些就足够了,前面会对每一项独自进行解说。

它的利用十分广，看上面这些分类，小伙伴们预计大部分都理解过的吧：

  • 单线程准则：

    单个线程中，依照程序的程序，前面的操作肯定能够看到后面的操作内容。

  • start()：

    主线程A启动线程B，线程B中能够看到主线程启动B之前的操作。

  • join()：

    主线程A期待子线程B实现，当子线程B执行结束后，主线程A能够看到线程B的所有操作。
  • volatile
  • synchronized、Lock

  • 工具类：

    • 线程平安容器：例如CurreentHashMap
    • CountDownLatch
    • Semaphore
    • 线程池
    • Future
    • CyclicBarrier

synchronized、线程池等知识点，这里因为篇幅限度，前面都会一一解说，逐渐更新，有趣味的小伙伴们能够关注一下（花Gie，明天的广告帮你打了，工资结一下吧）。

我：（老脸一粉）工资那个再说，你先说说volatile，我还等着去搬砖呢。

首先volatile是一种同步机制，一旦一个共享变量（成员变量、动态成员变量）被volatile润饰之后，那么就具备了以下两个作用：

  • 可见性：就是说一个线程批改了某个变量的值，其余线程可能立马感知到该变量已被批改；

  • 禁止指令重排序。

  • 对于可见性，我这里举个栗子：
static boolean flag = true;public static void main(String[] args) throws InterruptedException {    //线程1    new Thread(new Runnable() {        @Override        public void run() {            while (flag){                System.out.println("啥也不是！！！！");                }        }    }).start();    Thread.sleep(10);    //线程2    new Thread(new Runnable() {        @Override        public void run() {            flag = false;        }    }).start();}

这段代码用于进行一个线程，置信有不少小伙伴用到过，然而这并不是一个正确进行线程的办法，因为这里存在极小概率会进行线程失败。当线程1更改了flag变量后，还没来得及将内容回写到主存当中，就被安顿做其余事件去了，此时线程1并不能感知到线程2曾经对flag变量进行批改，因而会继续执行上来。

如果用volatile润饰flag变量，那就齐全能够防止这种状况呈现，起因有以下几点：

  • 应用volatile关键字会强制将批改的值立刻写入主存；
  • 应用volatile关键字的话，当线程2进行批改时，会导致线程1的工作内存中缓存变量flag的缓存行有效（也就是上文提到的CPU中L1或者L2缓存中对应的缓存行有效）；
  • 因为线程1的工作内存中缓存变量flag的缓存行有效，所以线程1再次读取变量flag的值时会去主存读取。

因而线程2批改stop值时（批改线程2工作内存中的值，并将批改后的值写入内存），会使得线程1的工作内存中缓存变量stop的缓存行有效，而后线程1读取时，发现自己的缓存行有效，它会期待缓存行对应的主存地址被更新后，去对应的主存读取最新的值。

  • 禁止指令重排序

后面章节咱们提到编译器在解释代码时，理论执行的程序和咱们代码编写的程序很可能是不同的，直白的说就是编译器只保障执行后果和你想要的统一，但至于先执行哪句代码、后执行哪一句代码，我说了算。但这里仅仅是在单线程下比拟好用，一旦引入了多线程，就会呈现各种奇怪的问题。

这里举个简略的栗子：

//a、b为非volatile变量//flag为volatile变量 a = 2;        //语句1b = 0;        //语句2flag = true;  //语句3c = 4;         //语句4d = -1;       //语句5

因为flag变量为volatile变量，那么在进行指令重排序的过程的时候，不会将语句3放到语句1、语句2后面，也不会讲语句3放到语句4、语句5前面。然而要留神语句1和语句2的程序、语句4和语句5的程序是不作任何保障的。

并且volatile关键字能保障，执行到语句3时，语句1和语句2必然是执行结束了的，且语句1和语句2的执行后果对语句3、语句4、语句5是可见的。

我：这么说我就懂了，那 a++ 问题是不是也能依赖volatile解决呢？

这个咱们先看上面一段代码。

import java.util.concurrent.atomic.AtomicInteger;public class volatileDemo implements Runnable {   volatile int a;   //只有晓得该类在并发状态下进行自增或自减，是线程平安的即可   AtomicInteger realCount = new AtomicInteger();   public static void main(String[] args) throws InterruptedException {      Runnable r =  new volatileDemo();      Thread thread1 = new Thread(r);      Thread thread2 = new Thread(r);      thread1.start();      thread2.start();      thread1.join();      thread2.join();      //应用a++失去的后果      System.out.println(((volatileDemo) r).a);      //线程安全类失去的后果      System.out.println(((volatileDemo) r).realCount.get());   }   @Override   public void run() {      for (int i = 0; i < 1000; i++) {         a++;         //realCount减少1         realCount.incrementAndGet();      }   }}

失去的后果为：

这个是为什么呢，我明明加上volatile了呀，你这个咋不好使了呢，骗子，退钱。

淡定.....先别急，咱们先来扒开表面，深刻的理解一下 a++，这其实并非原子操作，而是蕴含了几个步骤：读取a的值，进行加1操作，最初把加好的值赋值给a。

看到这里是不是就不奇怪了，因为volatile并不能保障原子性。

比方上面这个流程：

  • 线程1读取到a的值并执行完+1动作（还未执最初的赋值）
  • 此时另一个线程2也读取到a的值并执行+1动作；
  • 线程1、线程2实现赋值，并将新值写回主存；
  • 能够看出线程2用于计算的a值仍旧为批改前的，所以等到线程2执行结束后，a的值会少减少一次。

我：讲的很棒，必须加鸡腿，那你把volatile给小伙伴们总结一下吧？

总结下来有以下几点：

  • volatile提供可见性。用于被多个线程共享的变量，保障被任意一个线程批改后，其余线程能立马获取到批改后的值；
  • volatile不能代替synchronized，它不具备原子性和互斥性；
  • volatile只作用于属性，能够禁止该属性被重排序；
  • volatile提供了happens-before保障，也就是说对volatile变量进行批改后，其余线程都能获取到批改后的值。

总结

明天这章又和大家进一步探讨了JMM，你是不是对它也有了一个新的意识呢，除此之外咱们还引入了新的知识点volatile，这个也是多线程中比拟根底且十分罕用的，十分有必要把握，肝了一天，篇幅有点长，小伙伴们肯定要耐下心看看。

下一章花Gie会持续介绍大家十分相熟的synchronized，会不会和你认知的不一样呢，咱们下一章见。心愿大家继续关注，为了大厂梦，咱们持续肝。

点关注，防走丢

以上就是本期全部内容，如有纰漏之处，请留言指教，非常感谢。我是花GieGie ，有问题大家随时留言探讨 ，咱们下期见。

文章继续更新，能够微信搜一搜「 Java开发零到壹 」第一工夫浏览，后续会继续更新Java面试和各类知识点，有趣味的小伙伴欢送关注，一起学习，一起哈。

原创不易，你怎忍心白嫖，如果你感觉这篇文章对你有点用的话，感激老铁为本文点个赞、评论或转发一下，因为这将是我输入更多优质文章的能源，感激！