jvm运行机制和volatile关键字详解

参考https://www.cnblogs.com/dolphin0520/p/3920373.html

JVM启动流程

1.java虚拟机启动的命令是通过java +xxx(类名，这个类中要有main方法)或者javaw启动的。

2.执行命令后，系统第一步做的就是装载配置，会在当前路径中寻找jvm的config配置文件。

3.找到jvm的config配置文件之后会去定位jvm.dll这个文件。这个文件就是java虚拟机的主要实现。

4.当找到匹配当前版本的jvm.dll文件后，就会使用这个dll去初始化jvm虚拟机。获得相关的接口。之后找到main方法开始运行。

上面这个过程的描述虽然比较简单，但是jvm的启动流程基本都已经涵盖在里面了。

jvm的基本结构

类加载器子系统就是通常我们所说的ClassLoader类加载器，首先我们会通过ClassLoader加载到jvm的内存中去，本地方法区主要就是native的方法调用，这个我们不前不做关心，

pc寄存器

每个线程拥有一个PC寄存器在线程创建时创建指向下一条指令的地址执行本地方法时，PC的值为undefined

方法区

方法区是用来保存类的原信息。用来描述类的信息，包括类型常量池，字段方法信息，方法字节码。在JDK6的时候字符串常量是放在方法区中，但是JDK7的时候就已经移到了堆中。所以从这方面来说方法区，堆中到底保存的是什么信息和jdk的版本有很大的关系。从一般意义上来说我们的方法区就是保存一些类的原信息。方法区通常和永久区（perm）关联在一起，保存一些相对稳定的数据，

java堆

1.java堆应该是和程序开发中最为密切的一个内存区间，我们在程序开发中通过new出来的对象基本上都是保存在java堆中。

2.堆是全局共享的，所有线程都共享java堆，也就是你创建了一个对象之后，所有的线程都是能够访问的。

3.从GC的角度看，java堆的结构和GC的算法是有关系的。

java栈

1.java栈和堆相比是线程私有的，栈是由一系列帧组成的，所以java栈也叫作帧栈。帧中保存的内容是一个方法的局部变量，操作数栈，常量池指针。每一次方法调用都会创建一个新的帧，并压栈。

局部变量表结构：

//操作数栈，以局部变量表为图纸，扩充图纸，并进行图纸修改（局部变量的运算）。

如果我们多次在堆上分配了对象空间，但是却忘记了删除对象，就会出现内存泄露，就是我们分配空间却没有删除。内存泄露在实际开发中是非常难以解决的问题，因为内存泄露有可能发生在任何地方。

我们可以采用右面的方法，声明一个对象，我们像上面右面的方法中声明一个对象，那么他并没有实际的划分内存空间，而只是在java栈上产生了一个引用。而这个引用在我们使用后会自动释放，不会产生内存泄露的问题。

我们从上面的代码和主时中可以交互，一个程序要想执行是需要几个内存区域交互配合执行的。

从上面这个图中我们可以发现，每个线程读取和存储的都是线程的工作内存。而线程的工作内存再到主存中的存储是肯定会有一些时差的。也就是改变了一个变量的值之后，另一个调用这个变量的对象是不能马上知道的。如果说要让其他线程立即可见这个改动，就要使用volatile关键字修饰。一旦使用这个关键字之后，所有调用这个变量的线程就直接去主存当中拿取数据。每个线程不能访问其他线程的工作内存。

下面这个图就是线程和本地内存和主存之间的关系。

线程总是在自己的本地内存中拿取变量，而本地内存中存储的只是共享变量的一个副本，真正的共享变量是存储在主存中的。所以这个之间存在了一定的时延和误差。

为了解决缓存(这里主要指工作内存)不一致性问题，通常来说有以下2种解决方法：

　　1）通过在总线加LOCK#锁的方式

　　2）通过缓存一致性协议

　　这2种方式都是硬件层面上提供的方式。

　　在早期的CPU当中，是通过在总线上加LOCK#锁的形式来解决缓存不一致的问题。因为CPU和其他部件进行通信都是通过总线来进行的，如果对总线加LOCK#锁的话，也就是说阻塞了其他CPU对其他部件访问（如内存），从而使得只能有一个CPU能使用这个变量的内存。比如上面例子中如果一个线程在执行 i = i +1，如果在执行这段代码的过程中，在总线上发出了LCOK#锁的信号，那么只有等待这段代码完全执行完毕之后，其他CPU才能从变量i所在的内存读取变量，然后进行相应的操作。这样就解决了缓存不一致的问题。

　　但是上面的方式会有一个问题，由于在锁住总线期间，其他CPU无法访问内存，导致效率低下。

　　所以就出现了缓存一致性协议。最出名的就是Intel 的MESI协议，MESI协议保证了每个缓存中使用的共享变量的副本是一致的。它核心的思想是：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。

可见性

可见性是指一个线程修改了变量之后，其他线程能够立即知道。

保证可见性的方法就是上图提到的三种方法。

有序性和指令重排

有序性：在一个线程当中，所有的指令，所有的操作都是有序的。但是在线程外观察，在多线程的情况下去观察前面一个线程的行为，我们会发现这个行为有可能就是无序的(这种无序有两种原因，一种就是指令重排，另一种就是主存同步的延时，也就是说在线程A中更改了一个变量的值，同步主存也成功了，但是在线程B中我们可能还没来得及去同步主存中的值，这个时候对于线程B来说线程A的操作可能就是无序的)。

线程内串行语义：

写后读 a = 1;b = a; 写一个变量之后，再读这个位置。

写后写 a = 1;a = 2; 写一个变量之后，再写这个变量。

读后写 a = b;b = 1; 读一个变量之后，再写这个变量。

以上语句不可重排编译器不考虑多线程间的语义可重排： a=1;b=2;

eg：

int a = 10;    //语句1
int r = 2;    //语句2
a = a + 3;    //语句3
r = a*a;     //语句4

　　这段代码有4个语句，那么可能的一个执行顺序是：

　　那么可不可能是这个执行顺序呢：语句2 语句1 语句4 语句3

　　不可能，因为处理器在进行重排序时是会考虑指令之间的数据依赖性，如果一个指令Instruction 2必须用到Instruction 1的结果，那么处理器会保证Instruction 1会在Instruction 2之前执行。

　　虽然重排序不会影响单个线程内程序执行的结果，但是多线程呢？下面看一个例子：

//线程1:
context = loadContext();   //语句1
inited = true;             //语句2
 
//线程2:
while(!inited ){
  sleep()
}
doSomethingwithconfig(context);

　　上面代码中，由于语句1和语句2没有数据依赖性，因此可能会被重排序。假如发生了重排序，在线程1执行过程中先执行语句2，而此是线程2会以为初始化工作已经完成，那么就会跳出while循环，去执行doSomethingwithconfig(context)方法，而此时context并没有被初始化，就会导致程序出错。

　　从上面可以看出，指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。

　　也就是说，要想并发程序正确地执行，必须要保证并发编程特性（原子性、可见性以及有序性）。只要有一个没有被保证，就有可能会导致程序运行不正确。

1.原子性

　　在Java中，对基本数据类型的变量的读取和赋值操作是原子性操作，即这些操作是不可被中断的，要么执行，要么不执行。

　　上面一句话虽然看起来简单，但是理解起来并不是那么容易。看下面一个例子i：

　　请分析以下哪些操作是原子性操作：

x = 10;         //语句1
y = x;         //语句2
x++;           //语句3
x = x + 1;     //语句4

　　咋一看，有些朋友可能会说上面的4个语句中的操作都是原子性操作。其实只有语句1是原子性操作，其他三个语句都不是原子性操作。

　　语句1是直接将数值10赋值给x，也就是说线程执行这个语句的会直接将数值10写入到工作内存中。

　　语句2实际上包含2个操作，它先要去读取x的值，再将x的值写入工作内存，虽然读取x的值以及将x的值写入工作内存这2个操作都是原子性操作，但是合起来就不是原子性操作了。

　　同样的，x++和 x = x+1包括3个操作：读取x的值，进行加1操作，写入新的值。

　　所以上面4个语句只有语句1的操作具备原子性。

　　也就是说，只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。可以通过synchronized和Lock来实现。由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。

补充： volatile不能保证原子性

volatile关键字保证了操作的可见性，但是volatile不能保证操作是原子性

下面看一个例子：
public class Test {
    public volatile int inc = 0;
     
    public void increase() {
        inc++;
    }
     
    public static void main(String[] args) {
        final Test test = new Test();
        for(int i=0;i<10;i++){
            new Thread(){
                public void run() {
                    for(int j=0;j<1000;j++)
                        test.increase();
                };
            }.start();
        }
         
        while(Thread.activeCount()>1)  //保证前面的线程都执行完
            Thread.yield();
        System.out.println(test.inc);
    }
}
 　　大家想一下这段程序的输出结果是多少？也许有些朋友认为是10000。但是事实上运行它会发现每次运行结果都不一致，都是一个小于10000的数字。

　　上面是对变量inc进行自增操作，由于volatile保证了可见性，那么在每个线程中对inc自增完之后，在其他线程中都能看到修改后的值啊，所以有10个线程分别进行了1000次操作，
　　那么最终inc的值应该是1000*10=10000。
　　这里面就有一个误区了，volatile关键字能保证可见性没有错，但是上面的程序错在没能保证原子性。可见性只能保证每次读取的是最新的值，但是volatile没办法保证对变量的
　　操作的原子性。

　　在前面已经提到过，自增操作是不具备原子性的，它包括读取变量的原始值、进行加1操作、写入工作内存。那么就是说自增操作的三个子操作可能会分割开执行，
　　就有可能导致下面这种情况出现：

　　假如某个时刻变量inc的值为10，
　　线程1对变量进行自增操作，线程1先读取了变量inc的原始值，然后线程1被阻塞了
　　然后线程2对变量进行自增操作，线程2也去读取变量inc的原始值，由于线程1只是对变量inc进行读取操作，而没有对变量进行修改操作，
　　所以不会导致线程2的工作内存中缓存变量inc的缓存行无效，
　　所以线程2会直接去主存读取inc的值，发现inc的值时10，
　　然后进行加1操作，并把11写入工作内存，最后写入主存。
　　然后线程1接着进行加1操作，由于已经读取了inc的值，注意此时在线程1的工作内存中inc的值仍然为10，所以线程1对inc进行加1操作后inc的值为11
　　，然后将11写入工作内存，最后写入主存。
　　那么两个线程分别进行了一次自增操作后，inc只增加了1.
　　根源就在这里，自增操作不是原子性操作，而且volatile也无法保证对变量的任何操作都是原子性的。

　　采用synchronized、lock、ActomicInteger可以达到原子性
　　在java 1.5的java.util.concurrent.atomic包下提供了一些原子操作类。atomic是利用CAS来实现原子性操作的（Compare And Swap）
　　CAS实际上是利用处理器提供的CMPXCHG指令实现的，而处理器执行CMPXCHG指令是一个原子性操作。

　　另外：volatile 不能保证提供操作的原子性，但可以利用其内存屏障（long类型得分两次写入，用valatile修饰后，只有当完全写入了，后面才能去使用），
　　如读 64 位数据类型，像 long 和 double 都不是原子的，但 volatile 类型的 double 和 long 就是原子的。

2.可见性

　　对于可见性，Java提供了volatile关键字来保证可见性。

　　当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。

　　而普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。

　　另外，通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。此外:final修饰的(一旦初始化完成，其他线程也就可见)

eg：

public class VolatileTest extends Thread{

        private volatile boolean stop = false;
        public void stopMe(){
        stop=true;//volatile 写操作
        }

        public void run(){
        int i=0;
        while(!stop){//volatile 读操作，刚开始为false，当前线程本地为false，监听到volatile 写操作，然后去load主存
        i++;
                     }
        
        System.out.println("Stop thread："+i);//1466907008
                                              //1319723236
        }

        public static void main(String args[]) throws InterruptedException{
            VolatileTest t=new VolatileTest();
        t.start();
        //Thread.sleep(1000);
        t.stopMe();
        //Thread.sleep(1000);
    
        }

}

但是用volatile修饰之后就变得不一样了：

　　第一：使用volatile关键字会强制将修改的值立即写入主存；//一般的读取还是从工作内存读取

　　第二：使用volatile关键字的话，当线程t进行修改时，会导致main线程的工作内存中缓存变量stop的缓存行无效

　　第三：由于main线程的工作内存中缓存变量stop的缓存行无效，所以需要再次读取变量stop的值时，这时会去主存读取。

那么在线程t修改stop值时（当然这里包括2个操作，工作内存store+主内存write），会使得main线程的工作内存中缓存变量stop的缓存行无效，然后main线程读取时，发现自己的缓存行无效（无效状态），它会等待缓存行对应的主存地址被更新之后，然后去对应的主存读取最新的值，那么main线程读取到的就是最新的正确的值。

联想上文中提到的缓存一致性协议。最出名的就是Intel 的MESI协议，MESI协议保证了每个缓存中使用的共享变量的副本是一致的。它核心的思想是：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时（触发操作），发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。

3.有序性

volatile能保证有序性

在前面提到volatile关键字能禁止指令重排序，所以volatile能在一定程度上保证有序性。

　volatile关键字禁止指令重排序有两层意思：

　　1）当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；

　　即volatile是分水岭。

　　2）在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

　　可能上面说的比较绕，举个简单的例子：

//x、y为非volatile变量
//flag为volatile变量
 
x = 2;        //语句1
y = 0;        //语句2
flag = true;  //语句3
x = 4;         //语句4
y = -1;       //语句5

由于flag变量为volatile变量，那么在进行指令重排序的过程的时候，不会将语句3放到语句1、语句2前面，也不会讲语句3放到语句4、语句5后面。但是要注意语句1和语句2的顺序、语句4和语句5的顺序是不作任何保证的。

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

那么我们回到前面举的一个例子：

//线程1:
context = loadContext();   //语句1
inited = true;             //语句2
 
//线程2:
while(!inited ){
  sleep()
}
doSomethingwithconfig(context);
 　　前面举这个例子的时候，提到有可能语句2会在语句1之前执行，那么久可能导致context还没被初始化，而线程2中就使用未初始化的context去进行操作，导致程序出错。

　　这里如果用volatile关键字对inited变量进行修饰，就不会出现这种问题了，因为当执行到语句2时，必定能保证context已经初始化完毕。

Java内存模型具备一些先天的“有序性”，即不需要通过任何手段就能够得到保证的有序性，这个通常也称为 happens-before 原则。如果两个操作的执行次序无法从happens-before原则推导出来，那么就不能保证它们的有序性，虚拟机可以随意地对它们进行重排。

指令重排的基本原则（满足这些规则将不用重排）或者说happens-before规则：

1.程序顺序原则，一个线程内保证语义的串行性。

2.volatile规则：volatile关键字变量的写是先发生于读的。

3.锁规则：解锁必然发生随后加锁之前。

4.传递性：A先于B，B先于C，那么A必然先于C。

5.线程启动规则：线程的start方法优先于该线程的其他方法

6.线程中断规则：线程的中断（interrupt()）先于线程被中断后的代码。

7.线程终结规则：线程的所有操作先于线程的终结(Thread.join())。

8.对象终结规则：对象的构造函数执行结束先于finalize()方法的调用。

volatile的原理和实现机制

　　前面讲述了源于volatile关键字的一些使用，下面我们来探讨一下volatile到底如何保证可见性和禁止指令重排序的。

　　加入volatile关键字时，会多出一个lock前缀指令

　　lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：

　　1）它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成；即分水岭

　　2）它会强制将对缓存的修改操作立即写入主存；

　　3）如果是写操作，它会导致其他CPU中对应的缓存行无效。

使用volatile关键字的场景：

synchronized关键字是防止多个线程同时执行一段代码，那么就会很影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized，但是要注意volatile关键字是无法替代synchronized关键字的，因为volatile关键字无法保证操作的原子性

1.状态标记量

volatile boolean flag = false;
 
while(!flag){
    doSomething();
}
 
public void setFlag() {
    flag = true;
}
 

volatile boolean inited = false;
//线程1:
context = loadContext();  
inited = true;            
 
//线程2:
while(!inited ){
sleep()
}
doSomethingwithconfig(context);
 

2.double check

class Singleton{
    private volatile static Singleton instance = null;
     
    private Singleton() {
         
    }
     
    public static Singleton getInstance() {
        if(instance==null) {
            synchronized (Singleton.class) {
                if(instance==null)
                    instance = new Singleton();//我的感觉是，虽然构造行为是原子的，但是写入的是当前线程的工作内存，会让其他线程instance==null成立，从而再次构造。
            }
        }
        return instance;
    }
}
 　　至于为何需要这么写请参考：

　　《Java 中的双重检查（Double-Check）》http://blog.csdn.net/dl88250/article/details/5439024

　　和http://www.iteye.com/topic/652440

解释运行:

　　解释执行以解释方式运行字节码解释执行的意思是：读一句执行一句

编译运行（JIT）:

　　将字节码编译成机器码直接执行机器码运行时编译编译后性能有数量级的提升