JVM类加载过程和编译器优化

文章目录

- 1. 加载
- 2. 链接
- - 2.1 验证
  - 2.2 准备
  - 2.3 解析
- 3 初始化
- - 3.1 类初始化练习
  - 3.2 懒汉式单例练习
- 4. 类加载器
- - 4.1 启动类加载器
  - 4.2 扩展类加载器
  - 4.3 双亲委派模式
  - 4.4 线程上下文类加载器
  - 4.4 自定义类加载器
- 5. 运行时优化
- - 5.1 即时编译
  - - 逃逸分析
    - 方法内联（Inlining）
    - 字段优化
  - 5.2 反射优化

对应视频点这里黑马家的
JVM内存结构
JVM垃圾回收与调优学习
JVM字节码技术与Java语法糖字节码分析
JVM类加载过程和编译器优化

思维导图

类加载Class类型的文件主要三步：加载->链接->初始化。链接过程又可以分为三步：验证->准备->解析。

1. 加载

将类的字节码载入方法区中，内部采用 C++ 的 instanceKlass 描述 java 类，它的重要 field 有：

_java_mirror 即 java 的类镜像，例如对 String 来说，就是 String.class，作用是把 klass 暴露给 java 使用
_super 即父类
_fields 即成员变量
_methods 即方法
_constants 即常量池
_class_loader 即类加载器，是哪个类加载了它
_vtable 虚方法表，构造方法入口地址
_itable 接口方法表

注意：

如果这个类还有父类没有加载，先加载父类

加载和链接可能是交替运行的

instanceKlass 这样的【元数据】是存储在方法区（1.8 后的元空间内），但 _java_mirror 是存储在堆中
可以通过前面介绍的 HSDB 工具查看

2. 链接

主要分为三个阶段：验证、准备、解析

2.1 验证

验证类是否符合 JVM规范，安全性检查，四种验证：文件格式验证，元数据验证，字节码验证，符号引用验证。

用 UE 等支持二进制的编辑器修改 HelloWorld.class 的魔数，在控制台运行会报错

E:gitjvmoutproductionjvm>java cn.itcast.jvm.t5.HelloWorld
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.ClassFormatError: Incompatible magic value
3405691578 in class file cn/itcast/jvm/t5/HelloWorld
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

2.2 准备

为 static 变量分配空间，设置默认值

static 变量在 JDK 7 之前存储于 instanceKlass 末尾，从 JDK 7 开始，存储于 _java_mirror 末尾
static 变量分配空间和赋值是两个步骤，分配空间在准备阶段完成，赋值在初始化阶段完成
如果 static 变量是 final 的基本类型，以及字符串常量，那么编译阶段值就确定了，赋值在准备阶段完成
如果 static 变量是 final 的，但属于引用类型，那么赋值也会在初始化阶段完成

这里我们要注意类对象的存储位置，可以看上面的那张图，是存储在堆中的！jdk6之前是跟着instanceKlass后面的

针对上面第二点所说的分配空间和赋值是两个步骤，这里准备了一个栗子来证明：

这里我们要回忆一下之前的知识点，我们的类在加载时会将所有的静态属性和局部变量放到一个构造方法()V里面，并且在类的构造方法之前执行（上一篇文章的2.8节）

public class LoadB {
    static int a;

}

对应字节码：

{
  static int a; //声明
    descriptor: I
    flags: ACC_STATIC

  public com.fx.classLoader.byteCode.LoadB();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1 // Method java/lang/Object."":()V
         4: return
      LineNumberTable:
        line 8: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lcom/fx/classLoader/byteCode/LoadB;
}

可以看到在字节码里，并没有赋值的操作（）

接着我们修改一下代码：

public class LoadB {
    static int a;
    static int b = 10;

}

对应字节码：

{
  static int a;
    descriptor: I
    flags: ACC_STATIC

  static int b;
    descriptor: I
    flags: ACC_STATIC

  public com.fx.classLoader.byteCode.LoadB();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1    // Method java/lang/Object."":()V
         4: return
      LineNumberTable:
        line 8: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lcom/fx/classLoader/byteCode/LoadB;

  static {};  //可以这里调用了静态方法的构造方法
    descriptor: ()V
    flags: ACC_STATIC
    Code:
      stack=1, locals=0, args_size=0
         0: bipush        10
         2: putstatic     #2                  // Field b:I
         5: return
      LineNumberTable:
        line 10: 0
}

再看一下final修饰的静态变量

public class LoadB {
    static int a;
    static int b = 10;
    static final int c = 20;
}

{
  static int a;
    descriptor: I
    flags: ACC_STATIC

  static int b;
    descriptor: I
    flags: ACC_STATIC

  static final int c;
    descriptor: I
    flags: ACC_STATIC, ACC_FINAL
    ConstantValue: int 20

  public com.fx.classLoader.byteCode.LoadB();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."":()V
         4: return
      LineNumberTable:
        line 8: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lcom/fx/classLoader/byteCode/LoadB;

  static {};
    descriptor: ()V
    flags: ACC_STATIC
    Code:
      stack=1, locals=0, args_size=0
         0: bipush        10  // 10的赋值动作
         2: putstatic     #2                  // Field b:I
         5: return
      LineNumberTable:
        line 10: 0
}

可以看到有10的赋值动作，但是却找不到20的赋值动作，可以看出final修饰的静态方法并不是在调用()V构造方法时执行的，也就是并不是在初始化阶段完成的的，而是在准备阶段就完成了

2.3 解析

将常量池中的符号引用解析为直接引用

首先我们要知道类的加载都是惰性加载的，只有在要使用时才会进行加载

我们举一个例子来看一下解析的过程

我们首先应该知道，当类加载器加载类C时，只会对类C进行加载，并不会对类C进行链接和解析，当然类D也不会被加载、链接、初始化

之后我们会new C()，因为new会主动触发类C和类D的加载、链接、初始化，所以对比着来看解析的过程

public class Load2 {
    public static void main(String[] args) throws ClassNotFoundException,
            IOException {
        ClassLoader classloader = Load2.class.getClassLoader();
        // loadClass 方法不会导致类的解析和初始化
        Class c = classloader.loadClass("com.fx.classLoader.link.C");
        // new C();
        System.in.read();
    }
}

class C {
    D d = new D();
}

class D {
}

我们将项目启动并使用HSDB工具查看此时JVM中存在的类（在Java目录下执行）

java -cp ./lib/sa-jdi.jar sun.jvm.hotspot.HSDB

我们可以看到类C已经被加载进了JVM中，但是此时类D并没有被加载

接下来我们进类C中看下

可以看到类C左边的 JVM_CONSTANT_UnresolvedClass，表示这是一个未被解析的类

接下来我看下类解析的情况

public class Load2 {
    public static void main(String[] args) throws ClassNotFoundException,
            IOException {
//        ClassLoader classloader = Load2.class.getClassLoader();
//        // loadClass 方法不会导致类的解析和初始化
//        Class c = classloader.loadClass("com.fx.classLoader.link.C");
         new C();
        System.in.read();
    }
}

class C {
    D d = new D();
}

class D {
}

重新启动项目并用HSDB连接

可以看到此时其实类C和类D都已经加载了

我们进常量池里看一下，已经加载好了

所以总结一下：

解析的过程就是将常量池中的符号引用解析为直接引用

3 初始化

接下来是类加载的最后一个阶段

()V 方法

初始化即调用()V 方法，虚拟机会保证这个类的『构造方法』的线程安全

发生的时机

概括得说，类初始化是【懒惰的】
main 方法所在的类，总会被首先初始化
首次访问这个类的静态变量或静态方法时
子类初始化，如果父类还没初始化，会引发
子类访问父类的静态变量，只会触发父类的初始化
Class.forName
new 会导致初始化

不会导致类初始化的情况

访问类的 static final 静态常量（基本类型和字符串）不会触发初始化 (在类链接的准备阶段就完成)
类对象.class 不会触发初始化
创建该类的数组不会触发初始化
类加载器的 loadClass 方法
Class.forName 的参数 2 为 false 时

这里可能有点难理解，直接来一个例子：

每次只留一个打印，把其他的都注释掉，对比着来看

public class Load3 {
    static {
        System.out.println("main init");
    }
    public static void main(String[] args) throws ClassNotFoundException {
        // 1. 静态常量（基本类型和字符串）不会触发初始化
        System.out.println(B.b);
        // 2. 类对象.class 不会触发初始化
        System.out.println(B.class);
        // 3. 创建该类的数组不会触发初始化
        System.out.println(new B[0]);
        // 4. 不会初始化类 B，但会加载 B、A
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        cl.loadClass("cn.itcast.jvm.t3.B");
        // 5. 不会初始化类 B，但会加载 B、A
        ClassLoader c2 = Thread.currentThread().getContextClassLoader();
        Class.forName("cn.itcast.jvm.t3.B", false, c2);
        
        
        
        
        // 1. 首次访问这个类的静态变量或静态方法时
        System.out.println(A.a);
        // 2. 子类初始化，如果父类还没初始化，会引发
        System.out.println(B.c);
        // 3. 子类访问父类静态变量，只触发父类初始化
        System.out.println(B.a);
        // 4. 会初始化类 B，并先初始化类 A
        Class.forName("cn.itcast.jvm.t3.B");
    }
}
class A {
    static int a = 0;
    static {
        System.out.println("a init");
    }
}
class B extends A {
    final static double b = 5.0;
    static boolean c = false;
    static {
        System.out.println("b init");
    }
}

3.1 类初始化练习

public class Load4 {
    public static void main(String[] args) {
        System.out.println(E.a);
        System.out.println(E.b);
        System.out.println(E.c);
    }
}
class E {
    public static final int a = 10;
    public static final String b = "hello";
    public static final Integer c = 20;
}

前两个打印不会引起类的初始化，因为基本类型+String的赋值是在链接的准备阶段完成的

而第三个打印会引起初始化，因为Integer是类，会自动装箱，这个操作会在初始化阶段完成

字节码角度验证一下：

{
  public com.fx.classLoader.init.Load4();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."":()V
         4: return
      LineNumberTable:
        line 8: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lcom/fx/classLoader/init/Load4;

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: bipush        10
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(I)V
         8: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
        11: ldc           #5                  // String hello
        13: invokevirtual #6                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        16: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
        19: getstatic     #7                  // Field com/fx/classLoader/init/E.c:Ljava/lang/Integer;
        22: invokevirtual #8                  // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
        25: return
      LineNumberTable:
        line 10: 0
        line 11: 8
        line 12: 16
        line 13: 25
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      26     0  args   [Ljava/lang/String;
}

3.2 懒汉式单例练习

public class Load9 {
    public static void main(String[] args) {
        Singleton.test();
        Singleton.getInstance();
    }
}
class Singleton{
    private Singleton(){}
    private static class LazyHolder{
        private static final Singleton SINGLETON = new Singleton();
        static {System.out.println("LazyHolder init...");}
    }
    public static Singleton getInstance(){
        return LazyHolder.SINGLETON;
    }
    public static void test(){
        System.out.println("test...");
    }
}

只执行test时不会引起Singleton的初始化

当执行getInstance会引起初始化

4. 类加载器

以 JDK 8 为例：

名称	加载哪的类	说明
Bootstrap ClassLoader	JAVA_HOME/jre/lib	无法直接访问
Extension ClassLoader	JAVA_HOME/jre/lib/ext	上级为 Bootstrap，显示为 null
Application ClassLoader	classpath	上级为 Extension
自定义类加载器	自定义	上级为 Application

4.1 启动类加载器

我们自己的类一般是app类加载器进行加载，但是我们也可以通过一些参数来指定使用那个类加载器进行加载

用 Bootstrap 类加载器加载类：

public class F {
    static{
        System.out.println("bootstrap F init...");
    }
}

在cmd窗口进入类目录下并使用命令执行：

java -Xbootclasspath/a:.com.fx.classLoader.init.Load5_1
bootstrap F init
null

public class Load5_1 {
    public static void main(String[] args) throws ClassNotFoundException {
        Class clazz = Class.forName("com.fx.classLoader.init.F");
        System.out.println(clazz.getClassLoader());
    }
}

-Xbootclasspath 表示设置 bootclasspath
其中 /a:. 表示将当前目录追加至 bootclasspath 之后
可以用这个办法替换核心类
- java -Xbootclasspath:
- java -Xbootclasspath/a:<追加路径>
- java -Xbootclasspath/p:<追加路径>

4.2 扩展类加载器

4.3 双亲委派模式

所谓的双亲委派，就是指调用类加载器的 loadClass 方法时，查找类的规则

注意

这里的双亲，翻译为上级似乎更为合适，因为它们并没有继承关系

来看一段loadClass的源码：

protected Class loadClass(String name, boolean resolve)
    throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // 1. 检查该类是否已经加载
        Class c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    // 2. 有上级的话，委派上级 loadClass
                    c = parent.loadClass(name, false);
                } else {
                    // 3. 如果没有上级了（ExtClassLoader），则委派
                    BootstrapClassLoader
                        c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
            }
            if (c == null) {
                long t1 = System.nanoTime();
                // 4. 每一层找不到，调用 findClass 方法（每个类加载器自己扩展）来加载
                c = findClass(name);
                // 5. 记录耗时
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

我们可以通过debug的方式来执行体会一下加载的过程

4.4 线程上下文类加载器

我们在使用 JDBC 时，都需要加载 Driver 驱动，不知道你注意到没有，不写

Class.forName("com.mysql.jdbc.Driver")

也是可以让 com.mysql.jdbc.Driver 正确加载的，你知道是怎么做的吗？

让我们追踪一下源码：

public class DriverManager {
    // 注册驱动的集合
    private final static CopyOnWriteArrayList registeredDrivers
        = new CopyOnWriteArrayList<>();
    // 初始化驱动
    static {
        loadInitialDrivers();
        println("JDBC DriverManager initialized");
}

先不看别的，看看 DriverManager 的类加载器：

System.out.println(DriverManager.class.getClassLoader());

打印 null，表示它的类加载器是 Bootstrap ClassLoader，会到 JAVA_HOME/jre/lib 下搜索类，但 JAVA_HOME/jre/lib 下显然没有 mysql-connector-java-5.1.47.jar 包，这样问题来了，在 DriverManager 的静态代码块中，怎么能正确加载 com.mysql.jdbc.Driver 呢？

继续看 loadInitialDrivers() 方法：

private static void loadInitialDrivers() {
        String drivers;
        try {
            drivers = AccessController.doPrivileged(new PrivilegedAction
                    () {
                public String run() {
                    return System.getProperty("jdbc.drivers");
                }
            });
        } catch (Exception ex) {
            drivers = null;
        }
        // 1）使用 ServiceLoader 机制加载驱动，即 SPI
        AccessController.doPrivileged(new PrivilegedAction() {
            public Void run() {
                ServiceLoader loadedDrivers =
                        ServiceLoader.load(Driver.class);
                Iterator driversIterator = loadedDrivers.iterator();
                try{
                    while(driversIterator.hasNext()) {
                        driversIterator.next();
                    }
                } catch(Throwable t) {
                    // Do nothing
                }
                return null;
            }
        });
        println("DriverManager.initialize: jdbc.drivers = " + drivers);
        // 2）使用 jdbc.drivers 定义的驱动名加载驱动
        if (drivers == null || drivers.equals("")) {
            return;
        }
        String[] driversList = drivers.split(":");
        println("number of Drivers:" + driversList.length);
        for (String aDriver : driversList) {
            try {
                println("DriverManager.Initialize: loading " + aDriver);
                // 这里的 ClassLoader.getSystemClassLoader() 就是应用程序类加载器
                Class.forName(aDriver, true,
                        ClassLoader.getSystemClassLoader());
            } catch (Exception ex) {
                println("DriverManager.Initialize: load failed: " + ex);
            }
        }
    }

于是要显示的调用Classd的forName方法使用一个能加载驱动的加载器加载驱动

类加载还有一个原则：全盘负责

默认是使用本来的加载器加载依赖类的

由于JDBC在核心类库中，它由启动类加载器加载，由于驱动是在他的类初始化方法中加载的

所以驱动是DriverManager的依赖

默认是由启动类加载器加载，但找不到，不可能加载到驱动

于是要显示的调用Classd的forName方法使用一个能加载驱动的加载器加载驱动

再看 1）它就是大名鼎鼎的 Service Provider Interface （SPI）

约定如下，在 jar 包的 META-INF/services 包下，以接口全限定名名为文件，文件内容是实现类名称

这样就可以使用

ServiceLoader<接口类型> allImpls = ServiceLoader.load(接口类型.class);
Iterator<接口类型> iter = allImpls.iterator();
while(iter.hasNext()) {
    iter.next();
}

来得到实现类，体现的是【面向接口编程+解耦】的思想，在下面一些框架中都运用了此思想：

JDBC
Servlet 初始化器
Spring 容器
Dubbo（对 SPI 进行了扩展）

接着看 ServiceLoader.load 方法：

public static  ServiceLoader load(Class service) {
    // 获取线程上下文类加载器
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

线程上下文类加载器是当前线程使用的类加载器，默认就是应用程序类加载器，它内部又是由 Class.forName 调用了线程上下文类加载器完成类加载，具体代码在 ServiceLoader 的内部类 LazyIterator 中
4.4 自定义类加载器
问问自己，什么时候需要自定义类加载器

1）想加载非 classpath 随意路径中的类文件
2）都是通过接口来使用实现，希望解耦时，常用在框架设计
3）这些类希望予以隔离，不同应用的同名类都可以加载，不冲突，常见于 tomcat 容器

步骤：

继承 ClassLoader 父类
要遵从双亲委派机制，重写 findClass 方法
注意不是重写 loadClass 方法，否则不会走双亲委派机制

读取类文件的字节码 4. 调用父类的 defineClass 方法来加载类
使用者调用该类加载器的 loadClass 方法

如何确定一个类相同？

报名类名相同并且其类加载器也要相同

5. 运行时优化 5.1 即时编译逃逸分析
分层编译（TieredCompilation）

先来个例子

public class JIT1 { public static void main(String[] args) { for (int i = 0; i < 200; i++) { long start = System.nanoTime(); for (int j = 0; j < 1000; j++) { new Object(); } long end = System.nanoTime(); System.out.printf("%dt%dn",i,(end - start)); } } }

结果：

0 46500 1 55000 2 47700 3 52300 4 52500 5 49200 6 51800 7 46400 8 54800 9 66000 10 69000 11 45000 12 54900 13 47400 14 85500 15 56400 16 49200 17 54600 18 56300 19 102100 20 78700 21 50600 22 272100 23 48800 24 94700 25 72900 26 61600 27 378900 28 102400 29 60300 30 63000 31 241300 32 59400 33 169200 34 49000 35 57900 36 66900 37 55700 38 70100 39 68900 40 60700 41 53800 42 51200 43 48200 44 61500 45 57500 46 83300 47 58700 48 53400 49 56500 50 49300 51 51200 52 52400 53 61200 54 53800 55 47300 56 84100 57 60100 58 56700 59 49500 60 56700 61 61100 62 88300 63 65000 64 66500 65 63400 66 26400 67 12800 68 12400 69 12300 70 31500 71 11300 72 39500 73 13400 74 15500 75 21200 76 14500 77 15200 78 70200 79 20900 80 11000 81 14000 82 17800 83 12100 84 24000 85 13700 86 12800 87 8800 88 12600 89 9400 90 8400 91 14200 92 12200 93 15400 94 19400 95 12300 96 14900 97 12800 98 17300 99 15800 100 12300 101 10800 102 35700 103 14500 104 10300 105 11400 106 18700 107 10900 108 10800 109 12400 110 9800 111 10800 112 14200 113 9100 114 23700 115 14400 116 11200 117 10800 118 11000 119 11400 120 11100 121 12400 122 12500 123 10100 124 10200 125 14500 126 10400 127 15200 128 11300 129 11700 130 12700 131 14400 132 13100 133 11000 134 8700 135 14700 136 10900 137 18200 138 10900 139 11700 140 12800 141 12400 142 53200 143 195900 144 59800 145 600 146 800 147 600 148 700 149 700 150 700 151 600 152 600 153 900 154 600 155 600 156 600 157 600 158 800 159 600 160 800 161 500 162 500 163 500 164 700 165 500 166 600 167 600 168 600 169 700 170 400 171 600 172 500 173 500 174 900 175 700 176 400 177 700 178 700 179 600 180 500 181 1000 182 600 183 600 184 500 185 600 186 1200 187 700 188 600 189 500 190 400 191 400 192 700 193 600 194 600 195 600 196 500 197 600 198 600 199 600

可以看到在145次运行的时候，加载类的速度一下子就变快的

原因是什么呢？

JVM会将执行状态分成了 5 个层次：

0 层，解释执行（Interpreter）
1 层，使用 C1 即时编译器编译执行（不带 profiling）
2 层，使用 C1 即时编译器编译执行（带基本的 profiling）
3 层，使用 C1 即时编译器编译执行（带完全的 profiling）
4 层，使用 C2 即时编译器编译执行

profiling 是指在运行过程中收集一些程序执行状态的数据，例如【方法的调用次数】，【循环的回边次数】等

即时编译器（JIT）与解释器的区别

解释器是将字节码解释为机器码，下次即使遇到相同的字节码，仍会执行重复的解释
JIT 是将一些字节码编译为机器码，并存入 Code Cache，下次遇到相同的代码，直接执行，无需再编译
解释器是将字节码解释为针对所有平台都通用的机器码
JIT 会根据平台类型，生成平台特定的机器码

对于占据大部分的不常用的代码，我们无需耗费时间将其编译成机器码，而是采取解释执行的方式运行；另一方面，对于仅占据小部分的热点代码，我们则可以将其编译成机器码，以达到理想的运行速度。执行效率上简单比较一下 Interpreter < C1 < C2，总的目标是发现热点代码（hotspot名称的由来），优化之

刚才的一种优化手段称之为【逃逸分析】，发现新建的对象是否逃逸。可以使用 -XX:- DoEscapeAnalysis 关闭逃逸分析，再运行刚才的示例观察结果

-XX:-DoEscapeAnalysis

参考资料：Java HotSpot Virtual Machine Performance Enhancements (oracle.com)

小结：

即时编译器就是将热点代码的机器码缓存起来，下次遇到相同的代码直接执行

c1比解释器速度快大概五倍

c2比解释器快大概10到100倍

JDK 9 引入了一种新的编译模式 AOT，它是直接将字节码编译成机器码，这样就避免了 JIT 预热等各方面的开销。

老师没讲出逃逸分析的作用：通过逃逸分析后的对象，可将这些对象直接在栈上进行分配，而非堆上。极大的降低了GC次数，从而提升了程序整体的执行效率。

方法内联（Inlining）
private static int square(final int i) { return i * i; }

System.out.println(square(9));

如果发现 square 是热点方法，并且长度不太长时，会进行内联，所谓的内联就是把方法内代码拷贝、粘贴到调用者的位置：

System.out.println(9 * 9);

还能够进行常量折叠（constant folding）的优化

System.out.println(81);
字段优化
JMH 基准测试请参考：http://openjdk.java.net/projects/code-tools/jmh/
5.2 反射优化

JVM类加载过程和编译器优化

Java相关栏目本月热门文章