Java 虚拟机详解

1. Java 虚拟机

1.1 什么是虚拟机

  Java 虚拟机，是一个可以执行 Java 字节码的虚拟机进程。Java 源文件被编译成能被 Java 虚拟机执行的字节码文件( .class )。

  Java 被设计成允许应用程序可以运行在任意的平台，而不需要程序员为每一个平台单独重写或者是重新编译。Java 虚拟机让这个变为可能，因为它知道底层硬件平台的指令长度和其他特性。

  但是，跨平台的是 Java 程序(包括字节码文件)，，而不是 JVM。JVM 是用 C/C++ 开发的，是编译后的机器码，不能跨平台，不同平台下需要安装不同版本的 JVM 。

  也就是说，JVM 能够跨计算机体系结构来执行 Java 字节码，主要是由于 JVM 屏蔽了与各个计算机平台相关的软件或者硬件之间的差异，使得与平台相关的耦合统一由 JVM 提供者来实现。

  

1.2 JVM 由哪些部分组成

VM 的结构基本上由 4 部分组成：

• 类加载器：在 JVM 启动时或者类运行时将需要的 class 加载到 JVM 中；
• 内存区：将内存划分成若干个区以模拟实际机器上的存储、记录和调度功能模块，如实际机器上的各种功能的寄存器或者 PC 指针的记录器等；
• 执行引擎：执行引擎的任务是负责执行 class 文件中包含的字节码指令，相当于实际机器上的 CPU；
• 本地方法调用：调用 C 或 C++ 实现的本地方法的代码返回结果。

  

2. JVM 内存结构

  JVM 运行内存的分类如上图所示，JVM 内存区域主要分为线程私有区域【程序计数器、虚拟机栈、本地方法区】、线程共享区域【JAVA 堆、方法区】、直接内存。

  线程私有数据区域生命周期与线程相同, 依赖用户线程的启动/结束 而 创建/销毁(在 Hotspot VM 内, 每个线程都与操作系统的本地线程直接映射, 因此这部分内存区域的存/否跟随本地线程的 生/死对应)。线程共享区域随虚拟机的启动/关闭而创建/销毁。

  直接内存并不是 JVM 运行时数据区的一部分, 但也会被频繁的使用: 在 JDK 1.4 引入的 NIO 提 供了基于 Channel 与 Buffer 的 IO 方式, 它可以使用 Native 函数库直接分配堆外内存, 然后使用 DirectByteBuffer 对象作为这块内存的引用进行操作(详见: Java I/O 扩展), 这样就避免了在 Java 堆和 Native 堆中来回复制数据, 因此在一些场景中可以显著提高性能。

  

2.1 程序计数器（线程私有）

  程序计数器，Java 线程私有，类似于操作系统里的 PC 计数器，它可以看做是当前线程所执行的字节码的行号指示器：

• 如果线程正在执行的是一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Native 方法，这个计数器值则为空（Undefined）；
• 此内存区域是唯一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区

  

2.2 虚拟机栈（线程私有）

  虚拟机栈（栈内存），Java线程私有，虚拟机栈描述的是 Java 方法执行的内存模型：

• 每个方法在执行的同时都会创建一个栈帧（Stack Frame） 用于存储局部变量表、操作数栈、动态链接、方法出口等信息；
• 每一个方法从调用直至执行完成 的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程；
• 栈帧（ Frame）是用来存储数据和部分过程结果的数据结构，同时也被用来处理动态链接 (Dynamic Linking)、 方法返回值和异常分派（ Dispatch Exception）。栈帧随着方法调用而创建，随着方法结束而销毁——无论方法是正常完成还是异常完成（抛出了在方法内未被捕获的异 常）都算作方法结束。

  

2.3 本地方法区（线程私有）

  本地方法区和 Java Stack 作用类似, 区别是虚拟机栈为执行 Java 方法服务, 而本地方法栈则为 Native 方法服务, 如果一个 VM 实现使用 C-linkage 模型来支持 Native 调用, 那么该栈将会是一个 C 栈，但 HotSpot VM 直接就把本地方法栈和虚拟机栈合二为一。

  

2.4 堆（Heap - 线程共享）- 运行时数据区

  堆即运行时数据区，所有线程共享的一块区域，JVM 垃圾收集器管理的主要区域：

• 目前主要的垃圾回收算法都是分代收集算法，所以 Java 堆中还可以细分为：新生代和老年代；再细致一点的有 Eden 空间、From Survivor 空间、To Survivor 空间等，默认情况下新生代按照 8:1:1 的比例来分配；
• 根据 Java 虚拟机规范的规定，Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘一样。

  Java 堆从 GC 的角度还可以细分为: 新生代(Eden 区、From Survivor 区和 To Survivor 区)和老年代。

  

2.4.1 新生代

  是用来存放新生的对象。一般占据堆的 1/3 空间。由于频繁创建对象，所以新生代会频繁触发 MinorGC 进行垃圾回收。新生代又分为 Eden 区、ServivorFrom、ServivorTo 三个区。

  

2.4.1.1 Eden 区

  Java 新对象的出生地（如果新创建的对象占用内存很大，则直接分配到老年代）。当 Eden 区内存不够的时候就会触发 MinorGC，对新生代区进行一次垃圾回收。

  

2.4.1.2 ServivorFrom

  上一次 GC 的幸存者，作为这一次 GC 的被扫描者。

  

2.4.1.3 ServivorTo

  保留了一次 MinorGC 过程中的幸存者。

  

2.4.1.4 为什么需要 Survivor

  如果没有 Survivor 区，Eden 区每进行一次 Minor GC，存活的对象就会被送到老年代，老年代很快就会被填满。而有很多对象虽然一次 Minor GC 没有消灭，但其实或许第二次，第三次就需要被清除。这时候移入老年区，很明显不是一个明智的决定。

  所以，Survivor 的存在意义就是减少被送到老年代的对象，进而减少老年代 GC 的发生。Survivor 的预筛选保证，只有经历 15 次 Minor GC 还能在新生代中存活的对象，才会被送到老年代。

  

2.4.1.5为什么需要 From 和 To 两个呢

  这种机制最大的好处就是可以解决内存碎片化，整个过程中，永远有一个 Survivor 区是空的，另一个非空的 Survivor 区是无碎片的。

  假设只有一个 Survivor 区，Minor GC 执行后，Eden 区被清空了，存活的对象放到了 Survivor 区，而之前 Survivor 区中的对象，可能也有一些是需要被清除的。那么问题来了，这时候我们怎么清除它们？

  在这种场景下，我们只能标记清除，而我们知道标记清除最大的问题就是内存碎片，在新生代这种经常会消亡的区域，采用标记清除必然会让内存产生严重的碎片化。

  因为 Survivor 有 2 个区域，所以每次 Minor GC，会将之前 Eden 区和 From 区中的存活对象复制到 To 区域。第二次 Minor GC 时，To 区 到 From 区 ，以此反复。

  

2.4.2 老年代

  主要存放应用程序中生命周期长的内存对象。 大对象直接进入老年代（大对象是指需要大量连续内存空间的对象）。这样做的目的是，避免在 Eden 区和两个 Survivor 区之间发生大量的内存拷贝（新生代采用复制算法收集内存）。

下面三种情况也会直接进入老年代：

• 大对象：大对象指需要大量连续内存空间的对象，这部分对象不管是不是“朝生夕死”，都会直接进到老年代。这样做主要是为了避免在 Eden 区及 2 个 Survivor 区之间发生大量的内存复制。当你的系统有非常多“朝生夕死”的大对象时，需要注意。
• 长期存活对象：虚拟机给每个对象定义了一个对象年龄 Age 计数器。正常情况下对象会不断的在 Survivor 的 From 区与 To 区之间移动，对象在 Survivor 区中每经历一次 Minor GC，年龄就增加 1 岁。当年龄增加到 15 岁时，这时候就会被转移到老年代。
• 动态对象年龄：虚拟机并不重视要求对象年龄必须到 15 岁，才会放入老年区，如果 Survivor 空间中相同年龄所有对象大小的总合大于 Survivor 空间的一半，年龄大于等于该年龄的对象就可以直接进去老年区。

  

2.4.3 TLAB

2.4.3.1 什么是 TLAB （Thread Local Allocation Buffer）

• 从内存模型而不是垃圾回收的角度，对 Eden 区域继续进行划分，JVM 为每个线程分配了一个私有缓存区域，它包含在 Eden 空间内
• 多线程同时分配内存时，使用 TLAB 可以避免一系列的非线程安全问题，同时还能提升内存分配的吞吐量，因此我们可以将这种内存分配方式称为快速分配策略
• OpenJDK 衍生出来的 JVM 大都提供了 TLAB 设计

  

2.4.3.2 为什么要有 TLAB

• 堆区是线程共享的，任何线程都可以访问到堆区中的共享数据
• 由于对象实例的创建在 JVM 中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的
• 为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度

  尽管不是所有的对象实例都能够在 TLAB 中成功分配内存，但 JVM 确实是将 TLAB 作为内存分配的首选。

  在程序中，可以通过 -XX:UseTLAB 设置是否开启 TLAB 空间。默认情况下，TLAB 空间的内存非常小，仅占有整个 Eden 空间的 1%，我们可以通过 -XX:TLABWasteTargetPercent 设置 TLAB 空间所占用 Eden 空间的百分比大小。一旦对象在 TLAB 空间分配内存失败时，JVM 就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在 Eden 空间中分配内存。

  

2.4.4 堆是分配对象存储的唯一选择吗

随着 JIT 编译期的发展和逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
                               ——《深入理解 Java 虚拟机》

  

2.4.4.1 逃逸分析

  逃逸分析(Escape Analysis)是目前 Java 虚拟机中比较前沿的优化技术。这是一种可以有效减少 Java 程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。通过逃逸分析，Java Hotspot 编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。

逃逸分析的基本行为就是分析对象动态作用域：

• 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
• 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中，称为方法逃逸。

public static StringBuffer craeteStringBuffer(String s1, String s2) {
   
   StringBuffer sb = new StringBuffer();
   sb.append(s1);
   sb.append(s2);
   return sb;
}

  StringBuffer sb是一个方法内部变量，上述代码中直接将sb返回，这样这个 StringBuffer 有可能被其他方法所改变，这样它的作用域就不只是在方法内部，虽然它是一个局部变量，称其逃逸到了方法外部。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。

  
上述代码如果想要 StringBuffer sb不逃出方法，可以这样写：

public static String createStringBuffer(String s1, String s2) {
   
   StringBuffer sb = new StringBuffer();
   sb.append(s1);
   sb.append(s2);
   return sb.toString();
}

  不直接返回 StringBuffer，那么 StringBuffer 将不会逃逸出方法。

参数设置：