深入JVM内核2 JVM运行机制

深入JVM内核目录

1 JVM启动流程

JVM启动流程

2 JVM基本结构

2.1 PC寄存器

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

2.2 方法区

保存装载的类信息:
类型的常量池
字段、方法信息
方法字节码
通常和永久区(Perm)关联在一起

注意：
JDK6时，String等常量信息至于方法
JDK7时，已经移动到了堆

2.2 Java堆

和程序开发密切相关
应用系统对象都保存在Java堆中
所有线程共享Java堆
对分代GC来说，堆也是分代的
GC的主要工作区间

2.3 Java栈

线程私有
栈由一系列帧组成(因此Java栈也叫Java帧栈)
帧保存一个方法的局部变量、操作数帧、常量池指针
每一次方法调用创建一个帧，并压栈

局部变量表包括参数和局部变量

public class StackDemo {
    public static int runStatic(int i, long l, float f, Object o, byte b) {
        return 0;
    }
    public int runInstance(char c, short s, boolean b) {
        return 0;
    }
}

操作数栈

Java没有寄存器，所有参数传递使用操作数栈

public static int add(int a,int b){
int c=0;
c=a+b;
return c;
}

 0:   iconst_0 // 0压栈
 1:   istore_2 // 弹出int，存放于局部变量2
 2:   iload_0  // 把局部变量0压栈
 3:   iload_1 // 局部变量1压栈
 4:   iadd      //弹出2个变量，求和，结果压栈
 5:   istore_2 //弹出结果，放于局部变量2
 6:   iload_2  //局部变量2压栈
 7:   ireturn   //返回

栈上分配
逃逸分析
在JDK 6之后支持对象的栈上分析和逃逸分析，在JDK 7中完全支持栈上分配对象。其是否打开逃逸分析依赖于以下JVM的设置：

-XX:+DoEscapeAnalysis

进行逃逸分析之后，产生的后果是所有的对象都将由栈上分配，而非从JVM内存模型中的堆来分配。

public class OnStackTest {

    public static void alloc() {
        byte[] b = new byte[2];
        b[0] = 1;
    }

    public static void main(String[] args) {
        long b = System.currentTimeMillis();
        for (int i = 0; i < 100000000; i++) {
            alloc();
        }
        long e = System.currentTimeMillis();
        System.out.println(e - b);
    }
}

VM options配置

-server -Xmx10m -Xms10m   -XX:+DoEscapeAnalysis -XX:+PrintGC

输出结果：

[GC (Allocation Failure)  2048K->544K(9728K), 0.0005844 secs]
[GC (Allocation Failure)  2592K->552K(9728K), 0.0005943 secs]
[GC (Allocation Failure)  2600K->552K(9728K), 0.0009814 secs]
6

VM options配置

-server -Xmx10m -Xms10m   -XX:-DoEscapeAnalysis -XX:+PrintGC

输出结果：

[GC (Allocation Failure)  2048K->568K(9728K), 0.0018641 secs]
[GC (Allocation Failure)  2616K->560K(9728K), 0.0014770 secs]
[GC (Allocation Failure)  2608K->528K(9728K), 0.0014311 secs]
......省略
[GC (Allocation Failure)  3176K->1128K(9728K), 0.0015071 secs]
[GC (Allocation Failure)  3176K->1128K(9728K), 0.0013785 secs]
[GC (Allocation Failure)  3176K->1128K(9728K), 0.0011811 secs]
1084

程序的结果分析：
在进行逃逸分析的运行结果中，只执行了6次就退出程序了。而未进行逃逸分析的结果是1084次，就是说未进行逃逸分析的代码可以执行更多的调用次数。换句话来讲，就是未进行逃逸分析的堆空间远大于进行逃逸分析后使用的栈空间，堆的空间大于栈，这就是根本原因。

总结

小对象(一般几十个bytes)，在没有逃逸的情况下，可以直接分配在栈上
直接分配在栈上，可以自动回收，减轻GC压力
大对象或者逃逸对象无法栈上分配

栈上分配可以提升代码性能，降低在多线程情况下的锁使用，但是会受限于其空间的大小。

2.4 栈、堆、方法区交互

public class AppMain {
    //运行时, jvm 把appmain的信息都放入方法区 

    //main 方法本身放入方法区。
    public static void main(String[] args) {
        //test1是引用，所以放到栈区里， Sample是自定义对象应该放到堆里面 

        Sample test1 = new Sample(" 测试1 ");
        Sample test2 = new Sample(" 测试2 ");

        test1.printName();
        test2.printName();
    }

}

 class Sample
//运行时, jvm 把appmain的信息都放入方法区 
{
    private String name;

    //new Sample实例后， name 引用放入栈区里，  name 对象放入堆里 
    public Sample(String name) {
        this.name = name;
    }
    //print方法本身放入方法区里。
    public void printName() { System.out.println(name);
    }
}

 测试1 
 测试2

image.png

3 内存模型

每一个线程有一个工作内存和主存独立
工作内存存放主存中变量的值的拷贝

当数据从主内存复制到工作存储时，必须出现两个动作：第一，由主内存执行的读（read）操作；第二，由工作内存执行的相应的load操作；当数据从工作内存拷贝到主内存时，也出现两个操作：第一个，由工作内存执行的存储（store）操作；第二，由主内存执行的相应的写（write）操作

每一个操作都是原子的，即执行期间不会被中断

对于普通变量，一个线程中更新的值，不能马上反应在其他变量中
如果需要在其他线程中立即可见，需要使用 volatile 关键字

内存模型

可见性

一个线程修改了变量，其他线程可以立即知道

保证可见性的方法

volatile
synchronized(unlock之前，写变量值回主存)
final(一旦初始化完成，其他线程就可见)

有序性

在本线程内，操作都是有序的
在线程外观察，操作都是无序的。(指令重排或主内存同步延时)

指令重排

线程内串行语义

写后读 a = 1;b = a;    写一个变量之后，再读这个位置。
写后写 a = 1;a = 2;    写一个变量之后，再写这个变量。
读后写 a = b;b = 1;    读一个变量之后，再写这个变量。
以上语句不可重排
编译器不考虑多线程间的语义
可重排： a=1;b=2;

指令重排-破坏线程间的有序性

class OrderExample {
int a = 0;
boolean flag = false;

public void writer() {
    a = 1;                   
    flag = true;           
}

public void reader() {
    if (flag) {                
        int i =  a +1;      
        ……
    }
}
}

线程A首先执行writer()方法
线程B线程接着执行reader()方法
线程B在int i=a+1 是不一定能看到a已经被赋值为1

因为在writer中，两句话顺序可能打乱

线程A
flag=true
a=1
然而
线程B
flag=true(此时a=0)

指令重排-保证有序性的方法
class OrderExample

特别感谢

深入JVM内核—原理、诊断与优化