Java基础之volatile应用实例分析

这篇文章主要介绍“Java基础之volatile应用实例分析”，在日常操作中，相信很多人在Java基础之volatile应用实例分析问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Java基础之volatile应用实例分析”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！问：请谈谈你对volatile的理解？
答：volatile是Java虚拟机提供的轻量级的同步机制，它有３个特性：
１）保证可见性
２）不保证原子性
３）禁止指令重排刚学完java基础，如果有人问你什么是volatile？它有什么作用的话，相信一定非常懵逼…
可能看了答案，也完全不明白，什么是同步机制？什么是可见性？什么是原子性？什么是指令重排？要想理解什么是可见性，首先要先理解JMM。JMM（Java内存模型，Java Memory Model）本身是免费云主机域名一种抽象的概念，并不真实存在。它描述的是一组规则或规范，通过这组规范，定了程序中各个变量的访问方法。JMM关于同步的规定：
１）线程解锁前，必须把共享变量的值刷新回主内存；
２）线程加锁前，必须读取主内存的最新值到自己的工作内存；
３）加锁解锁是同一把锁；由于JVM运行程序的实体是线程，创建每个线程时，JMM会为其创建一个工作内存（有些地方称为栈空间），工作内存是每个线程的私有数据区域。Java内存模型规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问。但线程对变量的操作（读取、赋值等）必须在工作内存中进行。因此首先要将变量从主内存拷贝到自己的工作内存，然后对变量进行操作，操作完成后再将变量写会主内存中。看了上面对JMM的介绍，可能还是优点懵，接下来用一个卖票系统来进行举例：１）如下图，此时卖票系统后端只剩下１张票，并已读入主内存中：ticketNum=1。
２）此时网络上有多个用户都在抢票，那么此时就有多个线程同时都在进行买票服务，假设此时有３个线程都读入了目前的票数：ticketNum=1，那么接着就会买票。
３）假设线程１先抢占到cpu的资源，先买好票，并在自己的工作内存中将ticketNum的值改为０：ticketNum=0，然后再写回到主内存中。此时，线程１的用户已经买到票了，那么线程２，线程３此时应该不能再继续买票了，因此需要系统通知线程２，线程３，ticketNum此时已经等于０了：ticketNum=0。如果有这样的通知操作，你就可以理解为就具有可见性。通过上面对JMM的介绍和举例，可以简单总结下。JMM内存模型的可见性是指，多线程访问主内存的某一个资源时，如果某一个线程在自己的工作内存中修改了该资源，并写回主内存，那么JMM内存模型应该要通知其他线程来从新获取最新的资源，来保证最新资源的可见性。在1.1中，已经基本理解了可见性的含义，接下来用代码来验证一下，volatile确实可以保证可见性。首先先验证下，不使用volatile，是不是就是没有可见性。运行结果如下图，可以看到虽然线程0已经将number的值改为了10，但是主线程还是在循环中，因为此时number不具有可见性，系统不会主动通知。
在上面代码的第7行给变量number添加volatile后再次测试，如下图，此时主线程成功退出了循环，因为JMM主动通知了主线程更新number的值了，number已经不为０了。
理解了上面说的可见性之后，再来理解下什么叫原子性？原子性是指不可分隔，完整性，即某个线程正在做某个业务时，中间不能被分割。要么同时成功，要么同时失败。还是有点抽象，接下来举个例子。如下图，创建了一个测试原子性的类：TestPragma。在add方法中将n加１，通过查看编译后的代码可以看到，n++被拆分为３个指令进行执行。因此可能存在线程１正在执行第１个指令，紧接着线程２也正在执行第１个指令，这样当线程１和线程２都执行完３个指令之后，很容易理解，此时n的值只加了１，而实际是有２个线程加了２次，因此这种情况就是不保证原子性。
在2.1中已经进行了举例，可能存在２个线程执行n++的操作，但是最终n的值却只加了１的情况，接下来对这种情况再用代码进行演示下。首先给MyData类添加一个add方法然后创建测试原子性的类：TestPragmaDemo。测试下20个线程给number各加1000次之后，number的值是否是20000。运行结果如下图，最终number的值仅为18410。
可以看到即使加了volatile，依然不保证有原子性。
上面介绍并证明了volatile不保证原子性，那如果希望保证原子性，怎么办呢？以下提供了２种方法方法1是在add方法上添加synchronized，这样每次只有１个线程能执行add方法。结果如下图，最终确实可以使number的值为20000，保证了原子性。但是，实际业务逻辑方法中不可能只有只有number++这１行代码，上面可能还有n行代码逻辑。现在为了保证number的值是20000，就把整个方法都加锁了（其实另外那n行代码，完全可以由多线程同时执行的）。所以就优点杀鸡用牛刀，高射炮打蚊子，小题大做了。给MyData新曾一个原子整型类型的变量num，初始值为0。让num也同步加20000次。结果如下图，可以看到，使用原子整型的num可以保证原子性，也就是number++的时候不会被抢断。在第2节中理解了什么是原子性，现在要理解下什么是指令重排？计算机在执行程序时，为了提高性能，编译器和处理器常常会对指令进行重排：
源代码–>编译器优化重排–>指令并行重排–>内存系统重排–>最终执行指令处理器在进行重排时，必须要考虑指令之间的数据依赖性。单线程环境中，可以确保最终执行结果和代码顺序执行的结果一致。但是多线程环境中，线程交替执行，由于编译器优化重排的存在，两个线程使用的变量能否保持一致性是无法确定的，结果无法预测。看了上面的文字性表达，然后看一个很简单的例子。
比如下面的mySort方法，在系统指令重排后，可能存在以下３种语句的执行情况：
１）1234
２）2134
３）1324
以上这３种重排结果，对最后程序的结果都不会有影响，也考虑了指令之间的数据依赖性。看完指令重排的简单介绍后，然后来看下单例模式的代码。首先是在单线程情况下进行测试，结果如下图。可以看到，构造方法只执行了一次，是没有问题的。
接下来在多线程情况下进行测试，代码如下。在多线程情况下的运行结果如下图。可以看到，多线程情况下，出现了构造方法执行了２次的情况。
在3.3中的多线程单里模式下，构造方法执行了两次，因此需要进行改进，这里使用双端检锁机制：Double Check Lock, DCL。即加锁之前和之后都进行检查。在多次运行后，可以看到，在多线程情况下，此时构造方法也只执行１次了。
需要注意的是3.4中的DCL版的单例模式依然不是100%准确的！！！是不是不太明白为什么3.4DCL版单例模式不是100%准确的原因？
是不是不太明白在3.1讲完指令重排的简单理解后，为什么突然要讲多线程的单例模式？因为3.4DCL版单例模式可能会由于指令重排而导致问题，虽然该问题出现的可能性可能是千万分之一，但是该代码依然不是100%准确的。如果要保证100%准确，那么需要添加volatile关键字，添加volatile可以禁止指令重排。接下来分析下，为什么3.4DCL版单例模式不是100%准确？查看instance = new SingletonDemo();编译后的指令，可以分为以下３步：
１）分配对象内存空间：memory = allocate();
２）初始化对象：instance(memory);
３）设置instance指向分配的内存地址：instance = memory;由于步骤２和步骤３不存在数据依赖关系，因此可能出现执行132步骤的情况。
比如线程1执行了步骤13，还没有执行步骤2，此时instance!=null，但是对象还没有初始化完成；
如果此时线程2抢占到cpu，然后发现instance!=null，然后直接返回使用，就会发现instance为空，就会出现异常。这就是指令重排可能导致的问题，因此要想保证程序100%正确就需要加volatile禁止指令重排。在3.1中简单介绍了下执行重排的含义，然后通过3.2-3.5，借助单例模式来举例说明多线程情况下，为什么要使用volatile的原因，因为可能存在指令重排导致程序异常。接下来就介绍下volatile能保证禁止指令重排的原理。首先要了解一个概念：内存屏障（Memory Barrier），又称为内存栅栏。它是一个CPU指令，有２个作用：
１）保证特定操作的执行顺序；
２）保证某些变量的内存可见性；由于编译器和处理器都能执行指令重排。如果在指令之间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说，通过插入内存屏障，禁止在内存屏障前后的指令执行重排需优化。内存屏障的另一个作用是强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。到此，关于“Java基础之volatile应用实例分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注百云主机网站，小编会继续努力为大家带来更多实用的文章！

相关推荐: Vue dialog模态框如何封装

这篇“Vuedialog模态框如何封装”文章的知识点大部分人都不太理解，所以小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这篇文章能有所收获，下面我们一起来看看这篇“Vuedialog模态框如何封装”文章吧。首先我们需要一个遮…