好书速览-深入理解JVM-Part1

文章目录

- 第二章、Java内存区域与内存溢出异常
- - 2.1 概述
  - 2.2 运行时数据区域
  - - 程序计数器（program Counter Register)
    - Java虚拟机栈
    - 本地方法栈
    - 堆
    - 方法区
    - 运行时常量池
    - 直接内存
  - 2.3 对象生命周期
  - - 2.3.1 对象的创建
    - 2.3.2 对象的内存布局
    - - 对象头
      - 类型指针
      - 对齐填充
    - 2.3.3 对象的访问定位
    - - 句柄访问
      - 直接指针访问
  - 2.4 实战：OutOfMemoryError异常
  - - - Java堆溢出
      - 虚拟机栈和本地方法栈溢出
      - 方法区和运行时常量池溢出

第二章、Java内存区域与内存溢出异常

2.1 概述

C/C++程序员操纵对象的所有权，管理开始到终结
Java：虚拟机自动内存管理机制，不需要为new再去delete和free
- 但有可能导致内存泄漏和溢出

2.2 运行时数据区域

程序计数器（program Counter Register)

小内存空间
线程执行字节码的行号指示器
- 通过改变PC 来选取下一条需要执行的字节码
- 例如、：分支、循环、跳转、异常处理、线程恢复
为帮助在线程切换时，各条线程互不影响，PC为线程私有
如果是执行Java方法，则PC为正在执行的虚拟机字节码指令的地址，如果是正在执行的是本地（Native）方法，则计数器的值为空
- 本地方法（Native 方法）的执行是由本地库或操作系统级别的代码来执行的，并不受虚拟机的直接管理。因此，虚拟机的程序计数器并不会记录本地方法的执行地址。
- 如果需要跟踪本地方法的执行位置，可能需要使用特定的调试工具或性能分析工具，这些工具可以提供一些方法来跟踪本地方法的执行地址或调用栈信息。
PC是唯一一个不会出现OutOfMemoryError情况的区域

Java虚拟机栈

线程私有
- 与线程生命周期相同
每个方法被执行，JVM都会创建一个栈帧（Stack Frame）
- 存储：
  - 局部变量表
  - 操作数栈
  - 动态链接
  - 方法出口
  - 。。。
- 每一个方法被调用到结束，都是一个栈帧从JVM出栈到入栈
- 局部变量表存放：
  - 编译期可知的各种Java虚拟机基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它并不等同于对象本身，
  - 可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）
- 局部变量槽（slot）
  - 数据类型在局部变量表中的存储空间以局部变量槽（Slot）来表示，其中64位长度的long和double类型的数据会占用两个变量槽，其余的数据类型只占用一个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小
- 两类异常状况：
  - 如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；
  - 如果Java虚拟机栈容量可以动态扩展，当栈扩展时无法申请到足够的内存会抛出OutOfMemoryError异常。
    在递归调用过程中，如果没有正确的终止条件，每次递归调用都会向线程的栈中压入新的方法调用帧，最终导致栈空间耗尽，抛出StackOverflowError异常:

public class StackOverflowExample {
    public static void main(String[] args) {
        stackOverflow();
    }
    
    public static void stackOverflow() {
        stackOverflow(); // 递归调用
    }
}

在创建大量线程并且每个线程需要大量的栈空间时，如果虚拟机栈容量不足以容纳所有线程的栈帧，而且栈空间无法动态扩展或者扩展时无法申请到足够的内存，则会抛出OutOfMemoryError异常。

public class OutOfMemoryExample {
    public static void main(String[] args) {
        while (true) {
            new Thread(new Runnable() {
                public void run() {
                    while (true) {
                        // 占用大量内存
                    }
                }
            }).start();
        }
    }
}

本地方法栈

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别只是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的本地（Native）方法服务。
与虚拟机栈一样，本地方法栈也会在栈深度溢出或者栈扩展失败时分别抛出StackOverflowError和OutOfMemoryError异常。
（例如hot-spot虚拟机会直接将本地方法栈和虚拟机栈合二为一）

堆

Java堆（Java Heap）是虚拟机所管理的内存中最大的一块
Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例
Java几乎私有的对象实例几乎都是在这里分配内存
- 例外：
  - 栈上分配
  - 标量替换
所有线程共享的Java堆中可以划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）
- 以提升对象分配时的效率。
- 不过无论从什么角度，无论如何划分，都不会改变Java堆中存储内容的共性性，无论是哪个区域，存储的都只能是对象的实例，将Java堆细分的目的只是为了更好地回收内存，或者更快地分配内存。
Java堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的，这点就像我们用磁盘空间去存储文件一样，并不要求每个文件都连续存放。但对于大对象（典型的如数组对象），多数虚拟机实现出于实现简单、存储高效的考虑，很可能会要求连续的内存空间。
Java堆既可以被实现成固定大小的，也可以是可扩展的，不过当前主流的Java虚拟机都是按照可扩展来实现的（通过参数-Xmx和-Xms设定）。如果在Java堆中没有内存完成实例分配，并且堆也无法再扩展时，Java虚拟机将会抛出OutOfMemoryError异常
- -Xms 是 JVM 启动时堆内存的初始大小，而 -Xmx 是 JVM 可使用的最大堆内存大小。-Xms 设置的是 JVM 启动时即分配的内存，-Xmx 则是 JVM 运行过程中最大可以扩展到的内存上限。
- 32 位系统：
  - -Xms 默认是 1 MB。
  - -Xmx 默认是 1/4 的物理内存，但是最多不超过 1 GB。
- 64 位系统：
  - -Xms 默认是 1/64 的物理内存，最小 8 MB。
  - -Xmx 默认是 1/4 的物理内存，但不超过 32 GB

方法区

是各个线程共享的内存区域
它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
方法区在JDK 8以前常被混淆为“永久代”（Permanent Generation），但实际上二者并不等同。
- HotSpot虚拟机使用永久代来管理方法区内存，导致内存溢出问题频繁。
- 其他虚拟机如BEA JRockit和IBM J9没有永久代的概念，因此不会遇到类似问题。
- 随着Oracle收购BEA，计划统一虚拟机功能，HotSpot在JDK 7开始逐步移除永久代的内容，并在JDK 8彻底废弃永久代，改用本地内存中的元空间（Metaspace）来实现方法区。
- 也就是说：方法区的两种实现方案
  - 永久代
  - 元空间
如果方法区无法满足新的内存分配需求时，将抛出OutOfMemoryError异常。

运行时常量池

（Runtime Constant Pool）
方法区的一部分
- Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池表（Constant Pool Table），用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是说，并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可以将新的常量放入池中，
- 这种特性被开发人员利用得比较多的便是String类的intern()方法。
  - String.intern()：调用 String.intern() 方法时，JVM 会检查字符串池中是否已经存在相同内容的字符串：
    - 如果存在，则返回字符串池中的对象引用。
    - 如果不存在，则将该字符串添加到字符串池中，并返回该字符串的引用。
方法区的一部分，有可能会发生抛出异常

直接内存

在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。
- 这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。
- 动态扩展时也会出现OutOfMemoryError异常

2.3 对象生命周期

2.3.1 对象的创建

JVM识别new指令
1. 检查指令参数是否能在常量池中定位到类的符号引用
  - 并且该符号引用代表的类是否已经被加载、解析、初始化
    - 若没有则先进行类的加载
2. JVM为新生对象分配内存
  - 不连续的空间：JVM必须维护一个列表，记录可用内存块，在分配时从列表中找到一块足够大的空间分配给对象实例，并且更新列表上的记录
    - 常用的CMS基于清除算法的收集器，较为复杂
  - 连续的空间：所有被使用过的内存都被放在一边，空闲的内存被放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间方向挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”（Bump The Pointer）
    - Serial、ParNew等带压缩整理过程的收集器，简单高效
3. 考虑并发问题，是否会将同一个对象分配到同一片空间中
  - 方案一：JVM采用CAS配上失败重试，保证操作的原子性
  - 方案二：给不同将线程分配不同的创建对象的堆中内存空间（TLAB）
    - 称为本地线程分配缓冲，创建结束后，再同步存入堆
    - 虚拟机是否使用TLAB，可以通过-XX：+/-UseTLAB参数来设定。
4. 内存分配完成之后，虚拟机必须将分配到的内存空间（但不包括对象头）都初始化为零值（而不是初始值），如果使用了TLAB的话，这一项工作也可以提前至TLAB分配时顺便进行。
  - 这步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值。
5. 设置对象的对象头
  - 是哪个类
  - 如何查找到类的元数据
  - 对象的hashCode
  - GC分代年龄
  - 。。。

2.3.2 对象的内存布局

对象在堆内存的三个部分
- 对象头
- 实例数据
- 对齐填充

对象头

如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等
这部分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32个比特和64个比特，官方称它为“Mark Word”。
为节省对象头的容量
- 通过标志位来规定状态

类型指针

即对象指向它的类型元数据的指针，Java虚拟机通过这个指针来确定该对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据信息并不一定要经过对象本身，
如果对象是一个Java数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是如果数组的长度是不确定的，将无法通过元数据中的信息推断出数组的大小

对齐填充

这并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是任何对象的大小都必须是8字节的整数倍。对象头部分已经被精心设计成正好是8字节的倍数（1倍或者2倍），因此，如果对象实例数据部分没有对齐的话，就需要通过对齐填充来补全。

2.3.3 对象的访问定位

创建对象自然是为了后续使用该对象
我们的Java程序会通过栈上的reference数据来操作堆上的具体对象。
- 由于reference类型在《Java虚拟机规范》里面只规定了它是一个指向对象的引用，并没有定义这个引用应该通过什么方式去定位、访问到堆中对象的具体位置，所以对象访问方式也是由虚拟机实现而定的
主流的访问方式主要有使用句柄和直接指针两种：

句柄访问

Java堆中将可能会划分出一块内存来作为句柄池
reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自具体的地址信息

直接指针访问

Java堆中对象的内存布局就必须考虑如何放置访问类型数据的相关信息
reference中存储的直接就是对象地址，如果只是访问对象本身的话，就不需要多一次间接访问的开销
这两种对象访问方式各有优势
使用句柄来访问的最大好处就是reference中存储的是稳定句柄址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要被修改。
使用直接指针来访问最大的好处就是速度更快，它节省了一次指针定位的时间开销，由于对象访问在Java中非常频繁，因此这类开销积少成多也是一项极为可观的执行成本，就本书讨论的主要虚拟机HotSpot而言，它主要使用第二种方式进行对象访问（有例外情况，如果使用了Shenandoah收集器的话也会有一次额外的转发，具体可参见第3章），但从整个软件开发的范围来看，在各种语言、框架中使用句柄来访问的情况也十分常见

2.4 实战：OutOfMemoryError异常

Java堆溢出

idea配置JVM参数

Java堆用于储存对象实例，我们只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么随着对象数量的增加，总容量触及最大堆的容量限制后就会产生内存溢出异常。

Java堆内存溢出异常测试：

package oom;

import java.util.ArrayList;
import java.util.List;

public class HeapOOM {
    static class OOMObject {
    }

    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<OOMObject>();
        while (true) {
            list.add(new OOMObject());
        }
    }
}

出现OutOfMemoryError异常

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid13364.hprof ...
Heap dump file created [13477344 bytes in 0.042 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3210)
	at java.util.Arrays.copyOf(Arrays.java:3181)
	at java.util.ArrayList.grow(ArrayList.java:267)
	at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:241)
	at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:233)
	at java.util.ArrayList.add(ArrayList.java:464)
	at oom.HeapOOM.main(HeapOOM.java:13)

要解决内存区域的异常，可以通过内存映像分析工具）对Dump出来的堆转储快照进行分析。
具体步骤：

应确认内存中导致OOM的对象是否是必要的
1. 也就是要先分清楚到底是出现了内存泄漏（Memory Leak）
  1. 可进一步通过工具查看泄漏对象到GC Roots的引用链，找到泄漏对象是通过怎样的引用路径、与哪些GC Roots相关联，才导致垃圾收集器无法回收它们，根据泄漏对象的类型信息以及它到GC Roots引用链的信息，一般可以比较准确地定位到这些对象创建的位置，进而找出产生内存泄漏的代码的具体位置。
2. 还是内存溢出（Memory Overflow）。
  1. 如果不是内存泄漏，换句话说就是内存中的对象确实都是必须存活的，那就应当检查Java虚拟机的堆参数（-Xmx与-Xms）设置，与机器的内存对比，看看是否还有向上调整的空间。再从代码上检查是否存在某些对象生命周期过长、持有状态时间过长、存储结构设计不合理等情况，尽量减少程序运行期的内存消耗。

内存溢出（Out of Memory）：
意思：内存溢出指的是程序在申请内存时，没有足够的内存供其使用，导致申请失败或者程序运行崩溃。
原因：通常是因为程序在运行过程中申请了大量的内存空间，而这些空间无法被JVM及时回收和释放，最终导致JVM中没有足够的内存供应用程序继续运行。
常见原因：例如，程序中存在内存泄漏，或者申请的内存空间过大，但未能及时释放。常见情况包括不正确的对象引用、缓存管理不当等。

内存泄漏（Memory Leak）：
意思：内存泄漏是指程序中分配出的内存由于某种原因未能被释放，虽然这部分内存已经无法被程序使用，但也不能被操作系统回收，最终导致系统的可用内存逐渐减少。
原因：通常是因为程序员在编写代码时未注意到某些对象引用仍然存在，导致这些对象无法被垃圾回收器正确地识别和释放。
常见原因：例如，静态集合类引用导致的对象无法释放、长生命周期的对象引用未能及时断开等。

虚拟机栈和本地方法栈溢出

虽然可以用-Xoss参数（设置本地方法栈大小），但实际上无用，栈容量只能用-Xss参数来决定
虚拟机栈和本地方法栈的两种异常情况：
- 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常
- 如果虚拟机的栈内存允许动态扩展，当扩展栈容量无法申请到足够的内存时，将抛出OutOfMemoryError异常。
由于HotSpot不支持栈内存动态扩展，所以除非在创建线程申请内存时就因无法获得足够内存而出现OutOfMemoryError异常，否则在线程运行时是不会因为扩展而导致内存溢出的，只会因为栈容量无法容纳新的栈帧而导致StackOverflowError异常。

实验结果表明：无论是由于栈帧太大还是虚拟机栈容量太小，当新的栈帧内存无法分配的时候，HotSpot虚拟机抛出的都是StackOverflowError异常。可是如果在允许动态扩展栈容量大小的虚拟机上，相同代码则会导致不一样的情况。譬如远古时代的Classic虚拟机，这款虚拟机可以支持动态扩展栈内存的容量，在Windows上的JDK 1.0.2运行代码清单2-5的话（如果这时候要调整栈容量就应该改用-oss参数了），得到的结果是：

方法区和运行时常量池溢出

由于运行时常量池是方法区的一部分，所以这两个区域的溢出测试可以放到一起进行。
前面曾经提到HotSpot从JDK 7开始逐步“去永久代”的计划，并在JDK 8中完全使用元空间来代替永久代的背景故事，在此我们就以测试代码来观察一下，使用“永久代”还是“元空间”来实现方法区，对程序有什么实际的影响。

String::intern()是一个本地方法，它的作用是如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象的引用；否则，会将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用。在JDK 6或更早之前的HotSpot虚拟机中，常量池都是分配在永久代中，我们可以通过-XX：PermSize和-XX：MaxPermSize限制永久代的大小，即可间接限制其中常量池的容量，具体实现如代码清单2-7所示，请读者测试时首先以JDK 6来运行代码

/**
 * VM Args：-XX:PermSize=6M -XX:MaxPermSize=6M
 *
 * @author zzm
 */
public class RuntimeConstantPoolOOM {
    public static void main(String[] args) {
// 使用Set保持着常量池引用，避免Full GC回收常量池行为
        Set<String> set = new HashSet<String>();
// 在short范围内足以让6MB的PermSize产生OOM了
        short i = 0;
        while (true) {
            set.add(String.valueOf(i++).intern());
        }
    }
}

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
at java.lang.String.intern(Native Method)
at org.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java: 18)