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：

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

1 2 3 4

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=;
        while(!stop){//volatile 读操作，刚开始为false，当前线程本地为false，监听到volatile 写操作，然后去load主存
        i++;
                     }

        System.out.println("Stop thread："+i);//1466907008
                                              //
        }

        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）:

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