内存与垃圾回收——（三）运行时数据区

3_运行时数据区

内存是非常重要的系统资源，是硬盘和cpu的中间仓库及桥梁，承载着操作系统和应用程序的实时运行。JVM内存布局规定了Java在运行过程中内存申请、分配、管理的策略，保证了JVM的高效稳定运行。不同的JVM对于内存的划分方式和管理机制存在着部分差异。

3.1_运行时数据区内部结构

运行时环境：

每个Java应用程序都有一个Runtime类的实例，该实例允许该应用程序与运行该应用程序的环境进行交互。 当前运行时可以从getRuntime方法获得。

（JDK8的元数据区+JIT编译产物，就是JDK8以前的方法区。）

• 线程独占：每个线程都会有它独立的空间，随线程生命周期而创建和销毁。本地方法栈、虚拟机栈、程序计数器。
• 线程共享：所有线程能访问这块内存数据，随虚拟机或GC创建和销毁。堆、堆外内存（元数据区、代码缓存）。

3.2_JVM中的线程

在HotSpot JVM中，每个线程都与操作系统的本地线程直接映射；

操作系统负责所有线程的安排调度到任何一个可用的CPU上。一旦本地线程初始化成功，它就会调用Java线程中的run()方法；

Java线程执行终止后，本地线程也会回收。

后台线程分类：

• 虚拟机线程： 这种线程的操作时需要JVM达到安全点才会出现。这些操作必须在不同的线程中发生的原因是他们都需要JVM达到安全点，这样堆才不会变化。这种线程的执行包括“stop-the-world”的垃圾收集，线程栈收集，线程挂起以及偏向锁撤销。

• 周期任务线程： 这种线程是时间周期事件的提现（比如中断），他们一般用于周期性操作的调度执行。

• GC线程： 这种线程对于JVM里不同种类的垃圾收集行为提供了支持。

• 编译线程： 这种线程在运行时会降字节码编译成本地代码。

• 信号调度线程： 这种线程接收信号并发送给JVM,在它内部通过调用适当的方法进行处理。

3.3_程序计数器（PC寄存器）√

PC寄存器是用来存储指向下一条指令的地址，也即将要执行的指令代码。由执行引擎读取下一条指令。

• 它是一块很小的内存空间，几乎可以忽略不计。也是运行速度最快的存储区域。

• 在 JVM 规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的生命周期保持一致。

• 任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。程序计数器会存储当前线程正在执行的 Java 方法的 JVM 指令地址；或者，如果是在执行 native 方法，则是未指定值（undefined）。

• 它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

• 它是唯一一个在 Java 虚拟机规范中没有规定任何 OOM（Out Of Memory）情况的区域，而且没有垃圾回收。

常见问题：

1、使用PC寄存器存储字节码指令地址有什么用呢？（为什么使用PC寄存器记录当前线程的执行地址呢？）

（1）多线程宏观上是并行（多个事件在同一时刻同时发生）的，但实际上是并发交替执行的；

（2）因为CPU需要不停的切换各个线程，这时候切换回来以后，就得知道接着从哪开始继续执行；
（3）JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令。

众多线程在并发执行过程中，任何一个确定的时刻，一个处理器或者多核处理器中的一个内核，只会执行某个线程中的一条指令。

这样必然导致经常中断或恢复，如何保证分毫无差呢？每个线程在创建后，都会产生自己的程序计数器和栈帧，程序计数器在各个线程之间互不影响。

2、PC寄存器为什么会设定为线程私有？

（1）所谓的多线程在一个特定的时间段内只会执行其中某一个线程的方法，CPU会不停的做任务切换，这样必然会导致经常中断或恢复，如何保证分毫无差呢？

（2）为了能够准确地记录各个线程正在执行的当前字节码指令地址，最好的办法是为每一个线程都分配一个PC寄存器，这样一来各个线程之间便可以进行独立计算，从而不会出现相互干扰的情况。

3.4_Java虚拟机栈 √

3.4.1_虚拟机栈的基本概念

• 由于跨平台性的设计，Java的指令都是根据栈来设计的。不同平台CPU架构不同，所以不能设计为基于寄存器的。

• 优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令。

• 栈是运行时的单位，而堆是存储的单位。

• 栈解决程序的运行问题，即程序如何执行，或者说如何处理数据。堆解决的是数据存储的问题，即数据怎么放、放在哪儿。

• 一般来讲，对象主要都是放在堆空间的，是运行时数据区比较大的一块。

• 栈空间存放基本数据类型的局部变量，以及引用数据类型的对象的引用。

虚拟机栈的特点

• Java虚拟机栈（Java Virtual Machine Stack），早期也叫 Java栈。 每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应这个一次次的 Java方法调用。

• 是线程私有的

• 生命周期和线程是一致的

• 作用：主管Java程序的运行，它保存方法的局部变量（8种基本数据类型、对象的引用地址）、部分结果，并参与方法的调用和返回。

  • 局部变量：相较于成员变量（成员变量或称属性）
  • 基本数据变量：8种基本数据类型
  • 引用类型变量：类，数组，接口

• 栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器。

• JVM直接对java栈的操作只有两个：

  • 每个方法执行，伴随着进栈（入栈，压栈）
  • 执行结束后的出栈工作

• 对于栈来说不存在垃圾回收问题，但存在OOM异常。

栈中常见异常

Java 虚拟机规范允许Java栈的大小是动态的或者是固定不变的。

• 如果采用固定大小的 Java 虚拟机栈，那每一个线程的 Java 虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过 Java 虚拟机栈允许的最大容量，Java虚拟机将会抛出一个 StackOverflowError 异常。（栈内存默认大小为 1 M）

  /** StackOverflowError */
  public class StackErrorTest {
      public static void main(String[] args) {
          main(args);
      }
  }
  

• 如果 Java 虚拟机栈可以动态拓展，并且在尝试拓展的时候无法申请到足够的内存，或在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那Java虚拟机将会抛出一个 OutOfMemoryError 异常。

设置栈的大小-Xss

使用参数-Xss选项来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度。 （IDEA设置方法：Run -> EditConfigurations -> VM options 填入指定栈的大小 -Xss256k）

/**
 *  StackOverflowError
 *
 * 默认情况下：count = 11336
 * 在设置栈的大小 -Xss256k 后，count = 2363
 */
public class StackErrorTest {
    private static int count = 1;
    public static void main(String[] args) {
        System.out.println(count);
        count ++;
        main(args);
    }
}

3.4.2_栈的存储单位与结构

• 每个线程都有自己的栈，栈中的数据都是以**栈帧(Stack Frame)**的格式存在；

• 在这个线程上正在执行的每个方法都对应各自的一个栈帧；

• 栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息。

• JVM直接对java栈的操作只有两个，就是对栈帧的压栈和出栈，遵循先进后出 / 后进先出原则。

  

• 在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的，这个栈帧被称为当前栈帧(Current Frame)，与当前栈帧对应的方法就是当前方法（Current Frame），当前方法对应的类就是当前类（Current Class）。

• 执行引擎运行的所有字节码指令只针对当前栈帧进行操作；

• 如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前栈帧；

• 不同线程中所包含的栈帧是不允许相互引用的，即不能在一个栈帧中引用另外一个线程的栈帧；

• 如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧；

• Java方法有两种返回函数的方式，一种是正常的函数返回，使用return指令；另外一种是抛出异常。不管使用哪种方式，都会导致栈帧被弹出。

3.5_栈帧

3.5.1_栈帧的内部结构

每个栈帧中存储着：

1. 局部变量表（Local Variables）

2. 操作数栈（Operand Stack）（或表达式栈）

3. 动态链接（Dynamic Linking）（或执行"运行时常量池"的方法引用）

4. 方法返回地址（Return Adress）（或方法正常退出或者异常退出的定义）

5. 一些附加信息

3.5.2_局部变量表 ☆（Local Variables）

• 局部变量表也被称之为局部变量数组或本地变量表；

• 定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型、对象引用（reference），以及returnAddress类型；

• 由于局部变量表是建立在线程的栈上，是线程私有的数据，因此不存在数据安全问题；

  

• 局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的Code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的；

• **方法嵌套调用的次数由栈的大小决定。**一般来说，**栈越大，方法嵌套调用次数越多。**对一个函数而言，他的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间；

• **局部变量表中的变量只在当前方法调用中有效。**在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。

• JVM 使用局部变量表完成参数值到参数变量列表的传递过程的，如果是实例方法（非static），那么局部变量表的第 0 位索引的 Slot 默认是用于传递方法所属对象实例的引用，在方法中通过 this 访问。

  

Slot变量槽

(p49-p50的课再看一次)

• 参数值的存放总是在局部变量数组的index0开始，到数组长度-1的索引结束

• 局部变量表，最基本的存储单元是Slot(变量槽)

• 局部变量表中存放编译期可知的各种基本数据类型（8种），引用类型（reference），returnAddress类型的变量。

• 在局部变量表里，32位以内的类型只占用一个 Slot（包括returnAddress类型），64位的类型（long和double）占用两个 Slot。

  • byte、short、char、float 在存储前被转换为 int；boolean 也被转换为 int，0 表示 false，非 0 表示 true；
  • long 和 double 则占据两个 slot。

• JVM会为局部变量表中的每一个 Slot 都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值；

• 当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照声明顺序被复制到局部变量表中的每一个 Slot 上；

  

• 如果需要访问局部变量表中一个 64bit 的局部变量值时，只需要使用前一个索引即可。（比如：访问long或者double类型变量）

• 如果当前帧是由构造方法或者实例方法创建的（意思是当前帧所对应的方法是构造器方法或者是普通的实例方法），那么该对象引用 this 将会存放在 index 为 0 的 Slot 处,其余的参数按照参数表顺序排列。

• 静态方法中不能引用 this，是因为静态方法所对应的栈帧当中的局部变量表中不存在 this。

补充

• 在栈帧中，与性能调优关系最为密切的部分就是局部变量表。在方法执行时，虚拟机使用局部变量表完成方法的传递。
• 局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。

3.5.3_操作数栈 ☆（Operand Stack）

栈 ：可以使用数组或者链表来实现。

• 每一个独立的栈帧中除了包含局部变量表以外，还包含一个后进先出的操作数栈，也可以成为表达式栈。

• 操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈（push）/ 出栈（pop）。

  • 某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用他们后再把结果压入栈。（如字节码指令bipush操作）
  • 比如：执行复制、交换、求和等操作

• 操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间。

• 操作数栈就是JVM执行引擎的一个工作区，当一个方法开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的。

• 每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译器就定义好了，保存在方法的Code属性中，为max_stack的值。

• 栈中的任何一个元素都是可以任意的java数据类型

  • 32bit的类型占用一个栈单位深度
  • 64bit的类型占用两个栈深度单位

• 操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈push和出栈pop操作来完成一次数据访问。

• **如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，**并更新PC寄存器中下一条需要执行的字节码指令。

• 操作数栈中的元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译期间进行验证，同时在类加载过程中的类验证阶段的数据流分析阶段要再次验证。

• 另外，我们说Java虚拟机的解释引擎是基于栈的执行引擎,其中的栈指的就是操作数栈。

3.5.4_栈顶缓存技术（Top-of-Stack Cashing）

• 基于栈式架构的虚拟机所使用的零地址指令（即不考虑地址，单纯入栈出栈）更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派（instruction dispatch）次数和内存读/写次数
• 由于操作数是存储在内存中的，因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题，HotSpot JVM的设计者们提出了栈顶缓存技术，将栈顶元素全部缓存在物理CPU的 寄存器 中，以此降低对内存的读/写次数，提升执行引擎的执行效率。

3.5.5_动态链接（Dynamic Linking）

运行时常量池位于方法区（注意： JDK1.7 及之后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。）

• 每一个栈帧内部都包含一个指向运行时常量池Constant pool中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接。比如：invokedynamic指令。

  

• 在Java源文件被编译成字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Refenrence）保存在class字节码文件的常量池里。比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用（#n）转换为调用方法的直接引用。

3.5.6_方法的调用：解析和分派

在 JVM 中，将符号引用转换为调用方法的直接引用与方法的绑定机制相关。

• 静态链接
  当一个字节码文件被装载进 JVM 内部时，如果被调用的目标方法在编译期可知，且运行期保持不变时。这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接。
• 动态链接
  如果被调用的方法在编译期无法被确定下来，也就是说，只能够在程序运行期将调用方法的符号引用转换为直接引用，由于这种引用转换过程具备动态性，因此也就被称之为动态链接。

对应的方法的绑定机制为：早期绑定（Early Binding）和晚期绑定（Late Binding）。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程，仅发生一次。

• 早期绑定
  早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用。
• 晚期绑定
  如果被调用的方法在编译期无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式也就被称之为晚期绑定。（多态）

基于面向对象的编程语言始终保持着一个共性，那就是都支持封装，集成和多态等面向对象特性。既然这一类的编程语言具备多态特性，那么自然也就具备早期绑定和晚期绑定两种绑定方式。

Java中任何一个普通的方法其实都具备虚函数的特征，它们相当于C++语言中的虚函数（C++中则需要使用关键字virtual来显式定义）。如果在Java程序中不希望某个方法拥有虚函数的特征时，则可以使用关键字final来标记这个方法（编译器被确定）。

虚方法和非虚方法

非虚方法

• 如果方法在编译期就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法。

• 静态方法、私有方法、final方法、实例构造器（实例已经确定，this()调用本类的构造器）、父类方法（super调用）都是非虚方法。（不能被重写）

• 其他所有体现多态特性的方法称为虚方法。

子类对象的多态性使用前提：

​ ① 类的继承关系

​ ② 方法的重写

实际开发编写代码中用的接口，实际执行是导入的的三方jar包已经实现的功能

虚拟机中提供了以下几条方法调用指令：

• 普通调用指令：
  • invokestatic：调用静态方法，解析阶段确定唯一方法版本
  • invokespecial：调用方法、私有及父类方法，解析阶段确定唯一方法版本
  • invokevirtual：调用所有虚方法
  • invokeinterface：调用接口方法
• 动态调用指令：
  • invokedynamic：动态解析出需要调用的方法，然后执行 。（Java7新增）

前四条指令固化在虚拟机内部，方法的调用执行不可人为干预，而invokedynamic指令则支持由用户确定方法版本。

invokestatic指令和invokespecial指令调用的方法称为非虚方法；

invokevirtual（final修饰的除外，final为非虚方法）、invokeinterface指令调用的方法称称为虚方法。

invokedynamic

• JVM字节码指令集一直比较稳定，一直到 Java7 才增加了一个invokedynamic指令，这是 Java 为了实现【动态类型语言】支持而做的一种改进；
• 但是 Java7 中并没有提供直接生成 invokedynamic 指令的方法，需要借助 ASM 这种底层字节码工具来产生invokedynamic指令。直到 Java8 的 Lambda 表达式的出现，invokedynamic指令的生成，在 Java 中才有了直接生成方式；
• Java7 中增加的动态语言类型支持的本质是对 Java 虚拟机规范的修改，而不是对 Java 语言规则的修改，这一块相对来讲比较复杂，增加了虚拟机中的方法调用，最直接的受益者就是运行在 Java 平台的动态语言的编译器。

动态类型语言和静态类型语言

• 动态类型语言和静态类型语言两者的却别在于对类型的检查是在编译期还是在运行期，满足前者就是静态类型语言，反之则是动态类型语言。
• 直白来说， 静态语言是判断变量自身的类型信息；动态类型语言是判断变量值的类型信息，变量没有类型信息，变量值才有类型信息，这是动态语言的一个重要特征。
• Java是静态类型语言（尽管lambda表达式为其增加了动态特性），js，python是动态类型语言。

Java：String info = "Orcas"; //静态语言

JS：var name = "Orcas“；var name = 10; //动态语言

Python: info = 130; //动态语言

虽然 Java 在 JDK10时引入了var，可以局部变量类型推断，但 var 在编译阶段会被替换成所赋值的类型，因此 Java 依旧是一门静态语言。

方法重写的本质

1. 找到操作数栈的第一个元素所执行的对象的实际类型，记作C。

2. 如果在类型 C 中找到与常量池中的描述符、简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束；如果不通过，则返回java.lang.IllegalAccessError异常。

3. 否则，按照继承关系从下往上依次对 C 的各个父类进行第二步的搜索和验证过程。

4. 如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。

   IllegalAccessError介绍

   程序视图访问或修改一个属性或调用一个方法，这个属性或方法，你没有权限访问。一般的，这个会引起编译器异常。这个错误如果发生在运行时，就说明一个类发生了不兼容的改变。

虚方法表

P59

3.5.7_方法返回地址（Return Address）

• 存放调用该方法的PC寄存器的值（下一条指令的地址）

• 一个方法的结束，有两种方式：

  • 正常执行完成
  • 出现未处理的异常，非正常退出

• 无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。

  方法正常退出时，调用者（方法的调用者可能也是一个方法）的pc计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。

  而通过异常退出时，返回地址是要通过异常表来确定，栈帧中一般不会保存这部分信息。

• 本质上，方法的退出就是当前栈帧出栈的过程。此时，需要恢复上层方法的局部变量表、操作数栈、将返回值入调用者栈帧的操作数栈、设置PC寄存器值等，让调用者方法继续执行下去。

• 正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值。

当一个方法开始执行后，只有两种方式可以退出这个方法：

1、执行引擎遇到任意一个方法返回的字节码指令（return），会有返回值传递给上层的方法调用者，简称正常完成出口；

• 一个方法在正常调用完成之后究竟需要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定
• 在字节码指令中，返回指令包含ireturn（当返回值是boolean、byte、char、short和int类型时使用）、lreturn、freturn、dreturn以及areturn（引用类型的）
• 另外还有一个 return 指令供声明为void的方法、实例初始化方法、类和接口的初始化方法使用

2、在方法执行的过程中遇到了异常（Exception），并且这个异常没有在方法内进行处理，也就是只要在本方法的异常表中没有搜素到匹配的异常处理器，就会导致方法退出，简称异常完成出口；

方法执行过程中抛出异常时的异常处理，存储在一个异常处理表，方便在发生异常的时候找到处理异常的代码。

异常处理表：

3.5.8_一些附加信息（可选）

栈帧中还允许携带与Java虚拟机实现相关的一些附加信息。例如，对程序调试提供支持的信息。

3.6_本地方法栈 √

• Java 虚拟机栈用于管理 Java 方法的调用，而本地方法栈用于管理本地方法的调用。

• 线程私有的

• 允许被实现成固定或者是可动态拓展的内存大小。（和 Java 虚拟机栈在内存溢出方面情况是相同的）

  • 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个StackOverflowError异常。
  • 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么Java虚拟机将会抛出一个OutOfMemoryError异常。

• 本地方法是使用 C 语言实现的

• 它的具体做法是在 Native Method Stack 中登记native方法，在 Execution Engine 执行时加载本地方法库。

• 当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。

  • 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区

  • 它甚至可以直接使用本地处理器中的寄存器

  • 直接从本地内存的堆中分配任意数量的内存

• 并不是所有的 JVM 都支持本地方法。因为 Java 虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持 native 方法，也可以无需实现本地方法栈。

• 在 Hotspot JVM 中，直接将本地方法栈和虚拟机栈合二为一

3.7_堆 √ ☆

一个进程对应一个JVM实例，一个运行时数据区，又包含多个线程，这些线程共享了方法区和堆，每个线程包含了程序计数器、本地方法栈和虚拟机栈。

进程唯一，线程共享。

3.7.1_堆的核心概述

• 一个 JVM 实例只存在一个堆内存，堆也是 Java 内存管理的核心区域

• Java 堆区在 JVM 启动的时候即被创建，其空间大小也就确定了。是 JVM 管理的最大一块内存空间（堆内存的大小是可以调节的）

• 《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。（实例在堆内存中的存储方式，物理内存连续的采用指针碰撞，不连续的采用动态列表）

• 所有的线程共享 Java 堆，在这里还可以划分线程私有的缓冲区（TLAB：Thread Local Allocation Buffer）。（面试问题：堆空间一定是所有线程共享的么？不是，TLAB线程在堆中独有的）

• 《Java虚拟机规范》中对 Java 堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。从实际使用的角度看，“几乎”所有的对象的实例都在这里分配内存 （* 逃逸分析，栈上分配）

• 数组或对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。

• 在方法结束后，堆中的对象不会马上被移除（只是出栈），仅仅在垃圾收集的时候才会被移除

• 堆，是GC（Garbage Collection，垃圾收集器）执行垃圾回收的重点区域

堆内存大小的设置与查看

• Java 堆区用于存储 Java 对象实例，堆的大小在 JVM 启动时就已经设定好了，通过 -Xmx和 -Xms来进行设置

  • -Xms设置堆空间（年轻代+老年代）的初始内存大小，等价于-XX:InitialHeapSize
    • -X 是 JVM 的运行参数
    • ms 是 memory start
  • -Xmx设置堆的最大内存，等价于-XX:MaxHeapSize

• 一旦堆区中的内存大小超过 -Xmx 所指定的最大内存时，将会抛出OOM异常。

  • 默认情况下，初始内存大小：物理内存大小 / 64；最大内存大小：物理内存大小 / 4。
  • 手动设置：如 -Xms600m -Xmx600m

• 通常会将-Xms和-Xmx两个参数配置相同的值，其目的是为了能够在Java垃圾回收机制清理完堆区后不需要重新计算分配堆区的大小，从而提高性能。（堆空间扩容和释放）

  • 比如说：默认空余堆内存小于40%时，JVM 就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM 会减少堆直到 -Xms 的最小限制。
    因此服务器一般设置 -Xms、-Xmx 相等以避免在每次 GC 后调整堆的大小

• 查看设置的堆内存参数：

  • 方式一： 终端输入jps ， 然后jstat -gc pid
  • 方式二：（控制台打印）Edit Configurations => VM Options 添加 -XX:+PrintGCDetails

/**
 * -Xms600m -Xmx600m
 */
public class OOMTest {
    public static void main(String[] args) {
        ArrayList<Picture> list = new ArrayList<>();
        while(true){
            try {
                Thread.sleep(20);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            list.add(new Picture(new Random().nextInt(1024 * 1024)));
        }
    }
}

class Picture{
    private byte[] pixels;

    public Picture(int length) {
        this.pixels = new byte[length];
    }
}

3.7.2_堆的内存细分

• JDK 7及以前堆内存逻辑上分为三部分：新生代+老年代+永久代（Xms/Xmx分配的内存物理上没有涉及永久区）

  • Young Generation Space： Young/New

    √ 又被分为Eden区和Survior区

  • Tenure generation Space： Old/Tenure

  • Permanent Space： Perm

• JDK 8及以后堆内存逻辑上分为三部分：新生代+老年代+元空间（Xms/Xmx分配的内存物理上没有涉及元空间）

  • Young Generation Space： Young/New

    √ 又被分为Eden区和Survior区

  • Tenure generation Space： Old/Tenure

  • Meta Space： Meta

年轻代与老年代

即堆空间

• 存储在 JVM 中的 Java 对象可以被划分为两类：

  • 一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速
  • 另外一类对象时生命周期非常长，在某些情况下还能与JVM的生命周期保持一致

• Java 堆区进一步细分可以分为年轻代（YoungGen）和老年代（OldGen）。其中年轻代可以分为Eden空间、Survivor0空间和Survivor1空间（有时也叫from区，to区）

• 新生代与老年代在堆结构的占比：

  • 默认-XX：NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3

  • 可以修改-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5

  • 在HotSpot中，新生代中Eden空间和另外两个Survivor空间缺省所占的比例默认是8 : 1 : 1（测试的时候是6 : 1 : 1），开发人员可以通过选项 -XX:SurvivorRatio 调整空间比例，如-XX:SurvivorRatio=8

    关闭自适应内存分配策略 -XX:-UseAdaptivesSizePolicy （+是打开）

  • 几乎所有的 Java 对象都是在 Eden 区被new出来的

  • 绝大部分的 Java 对象都销毁在新生代了（IBM公司的专门研究表明，新生代80%的对象都是“朝生夕死”的）

  • 可以使用选项-Xmn设置新生代内存大小（一般不设置）

3.7.3_对象的分配过程

为新对象分配内存是件非常严谨和复杂的任务，JVM 的设计者们不仅需要考虑内存如何分配、在哪里分配的问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。

1. new 的对象先存放 Eden 区。（此区有大小限制）

2. 当 Eden 区的空间填满时，程序又要创建对象，JVM 的垃圾回收器将对 Eden 区进行垃圾回收（Minor GC），将 Eden 区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到 Eden 区。

3. 而 Eden 区中剩余的幸存对象将移动到幸存者 S0 区。为每个对象分配了一个年龄计数器 age，赋值为 1。

   

4. Eden 区继续存放对象，若再次填满触发垃圾回收，此时还被占用的幸存对象将会存放至 S1 中（空的幸存者区to）；而上次幸存下来被存放于幸存者S0区的对象也会被判断是否需要被回收，如果没有回收，就会放到幸存者S1区，其age增加变为 2，此时 S0 区被清空，成为 to 区。（to 区即为下次从 Eden 过来的幸存者区）

5. 同理，会继续经历垃圾回收，此时会重新放回幸存者 S0 区，接着再去幸存者 S1 区。

   

6. 那么何时去老年代呢？可以设置age，触发进入老年区的阈值，默认是15。

• 通过参数 -XX:MaxTenuringThreshold=15 进行设置

7. 在老年代相对悠闲。当老年区内存不足时，再次触发 GC：Major GC，进行老年代的内存清理。

8. 若老年代执行了 Major GC 之后发现依然无法进行对象的存储，就会产生 OOM 异常。

总结：

• 针对幸存者 s0，s1 区：复制之后有交换，谁空谁是 to。
• 关于垃圾回收：频繁在新生代收集，很少在老年代收集，几乎不在永久区 / 元空间收集。

**注意：**只有 Eden 区满了才会触发 MinorGC / YGC，而幸存者区满了不会触发 MinorGC，它会随 Eden 区触发垃圾回收时一起进行回收（被动回收）。

流程图

两种特殊情况直接存放到老年代：

• 当超大对象无法在新生代存放时，将会被存放到老年代；若老年代也不够存放，将会进行 FGC / Major GC，进行老年代的垃圾回收；若垃圾回收后也无法存放，就会抛出 OOM 异常。

• 当幸存者区满后，直接晋升至老年代。

3.7.4_Minor GC、Major GC、Full GC

JVM 在进行 GC 时，并非每次都对上面三个内存区域（新生代、老年代、方法区）一起回收的，大部分时候回收都是指新生代。

针对 HotSpot VM 的实现，它里面的GC按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（Full GC）

• **部分收集：**不是完整收集整个 Java 堆的垃圾收集。其中又分为：

  • 新生代收集（Minor GC / Young GC）：只是新生代的垃圾收集
  • 老年代收集（Major GC / Old GC）：只是老年代的垃圾收集
    • 目前，只有 CMS GC 会有单独收集老年代的行为
    • 注意，很多时候 Major GC 会和 Full GC 混淆使用，需要具体分辨是老年代回收还是整堆回收
  • 混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集。
    • 混合收集不涉及方法区回收，只是新生代，老年代的混合收集。
    • 目前，只有 G1 GC 会有这种行为。(region)

• 整堆收集：收集整个Java堆和方法区的垃圾收集。

分代式GC策略的触发条件

• 年轻代GC（Minor GC）触发机制

  • 当年轻代空间不足时，就会触发 Minor GC，这里的年轻代满指的是 Eden 代满，Survivor 满不会引发 GC。（每次Minor GC会清理年轻代的内存，Survivor是被动GC）
  • 因为Java对象大多都具备朝生夕灭的特性，所以 Minor GC 非常频繁，新生代内存相对较小，一般回收速度也比较快。
  • Minor GC 会引发 STW（Stop the World），暂停其他用户的线程，等垃圾回收结束，用户线程才恢复运行。

• 老年代GC（Major GC/Full GC）触发机制

  • 指发生在老年代的 GC，对象从老年代消失时，意味着 Major GC 或者 Full GC 发生了。
  • 出现了 Major GC，经常会伴随至少一次的 Minor GC（不是绝对的，在 Parallel Scavenge 收集器的收集策略里就有直接进行 Major GC 的策略选择过程）
    • 也就是老年代空间不足时，会先尝试触发 Minor GC；如果之后空间还不足，则触发 Major GC
  • Major GC 速度一般会比 Minor GC 慢 10 倍以上，STW时间更长
  • 如果 Major GC 后，内存还不足，就报 OOM 了

• Full GC触发机制 √ （性能调优部分细讲）

  触发Full GC执行的情况有以下五种

  1. 调用System.gc()时，系统建议执行 Full GC，但是不必然执行

  2. 老年代空间不足

  3. 方法区空间不足

  4. 通过 Minor GC 后进入老年代的平均大小大于老年代的可用内存

  5. 由 Eden 区，Survivor0（from）区向S1（to）区复制时，对象大小 > To Space 可用内存，则把该对象转存到老年代，且老年代的可用内存 < 该对象大小

  说明：Full GC 是开发或调优中尽量要避免的，这样暂停时间会短一些。

3.7.5_堆空间分代思想

为什么要把 Java 堆分代？不分代就不能正常工作了么？

• 经研究，不同对象的生命周期不同。70%-99% 的对象都是临时对象。

  • 新生代：有 Eden、Survivor（s0 / s1，又称为from / to）构成，to 总为空
  • 老年代：存放新生代中经历多次依然存活的对象

• 其实不分代完全可以，分代的唯一理由就是优化 GC 性能。如果没有分代，那所有的对象都在一块，GC 的时候要找到哪些对象没用，这样就会对堆的所有区域进行扫描。

  而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当 GC 的时候先把这块存储“朝生夕死”对象的区域进行回收。新生代 GC 频率高，老年代 GC 频率低，提高了性能。

3.7.6_内存分配策略

如果对象在 Eden 出生并经过第一次 Minor GC 后依然存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为 1。对象在 Survivor 区中每熬过一次 MinorGC，年龄就 +1，当它的年龄增加到一定程度（默认15，每个 JVM、每个 GC 都有所不同）时，就会被晋升到老年代中。

• 对象晋升老年代的年龄阈值，可以通过选项-XX：MaxTenuringThreshold来设置

针对不同年龄段的对象分配原则如下：

• 优先分配到 Eden

• 大对象（如长字符串、大数组）直接分配到老年代

  • 尽量避免程序中出现过多的大对象

• 长期存活的对象分配到老年代

• 动态对象年龄判断

• 如果 Survivor 区中相同年龄的所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象可以直接进入到老年代。无需等到 MaxTenuringThreshold 中要求的年龄。

• 空间分配担保机制

  -XX:HandlePromotionFailure：是否设置空间分配担保

  在发生 Minor GC 之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。

  • 如果大于，则此次 Minor GC 是安全的
  • 如果小于，则虚拟机会查看-XX:HandlePromotionFailure设置值是否允许担保失败。（JDK 7以后的规则 HandlePromotionFailure 可以认为就是 true）
    • 如果 HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。
      • 如果大于，则尝试进行一次 Minor GC，只是尝试看能否触发分配担保（我们肯定希望的是分配担保成功Eden–>old/tentired），但这次 Minor GC 依然是有风险的；
      • 如果小于，则改为进行一次 Full GC。
    • 如果 HandlePromotionFailure=false，则改为进行一次 Full GC。

  注意：在 JDK6 Update24之后（JDK7），HandlePromotionFailure 参数不会再影响到虚拟机的空间分配担保策略，观察 OpenJDK 中的源码变化，虽然源码中还定义了 HandlePromotionFailure 参数，但是在代码中已经不会再使用它。

  JDK6 Update24 之后的规则变为：只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行 Minor GC，否则将进行 Full GC。

3.7.7_线程本地分配缓存区 TLAB

为什么有TLAB（Thread Local Allocation Buffer）？

• 堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据。由于对象实例的创建在 JVM 中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的。

• 一般为了避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。

什么是TLAB？

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

TLAB说明

• 尽管不是所有的对象实例都能够在 TLAB 中成功分配内存，但 JVM 确实是将 TLAB 作为内存分配的首选。
• 通过选项-XX:UseTLAB 设置是否开启 TLAB 空间。
• 默认情况下，TLAB 空间的内存非常小，仅占有整个 Ede n空间的 1%，可以通过选项 -XX:TLABWasteTargetPercent 设置 TLAB 空间所占用 Eden 空间的百分比大小。
• 一旦对象在 TLAB 空间分配内存失败时，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在 Eden 空间中分配了内存。

TLAB 的本质是三个指针管理的区域：start，top 和 end，每个线程都会从 Eden 分配一块空间，例如说 100KB，作为自己的 TLAB，其中 start 和 end 是占位用的，标识出 Eden 中被该 TLAB 所管理的区域，占用 Eden中的一块空间不让其它线程来分配。

3.7.8_堆空间常用参数设置

• -XX:PrintFlagsInitial： 查看所有参数的默认初始值
• -XX:PrintFlagsFinal：查看所有的参数的最终值（可能会存在修改，不再是初始值）
  • 具体查看某个参数的指令：
    • jps：查看当前运行中的进程
    • jinfo -flag SurvivorRatio pid： 查看新生代中 Eden 和 S0/S1 空间的比例
• -Xms： 初始堆空间内存（默认为物理内存的1/64）
• -Xmx： 最大堆空间内存（默认为物理内存的1/4）
• -Xmn：设置新生代大小（初始值及最大值）
• -XX:NewRatio： 配置新生代与老年代在堆结构的占比（默认2，o : y）
• -XX:SurvivorRatio：设置新生代中Eden和S0/S1空间的比例
• -XX:MaxTenuringThreshold：设置新生代垃圾的最大年龄（默认15），年龄存在对象头中，占 4 位
• -XX:+PrintGCDetails：输出详细的 GC 处理日志
  • 打印GC简要信息：① -XX:+PrintGC ② -verbose:gc
• -XX:HandlePromotionFailure：是否设置空间分配担保

3.7.9_堆是分配对象存储的唯一选择吗？

在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述：

​ 随着 JIT 编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
   在 Java 虚拟机中，对象是在 Java 堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是如果经过逃逸分析（Escape Analysis）后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。
   此外，前面提到的基于 OpenJDK 深度定制的 TaoBaoVM，其中创新的 GCIH（GCinvisible heap）技术实现 off-heap，将生命周期较长的Java对象从 heap 中移至 heap 外，并且 GC 不能管理 GCIH 内部的Java对象，以此达到降低 GC 的回收频率和提升 GC 的回收效率的目的。

逃逸分析

如何将堆上的对象分配到栈，需要使用逃逸分析手段。

这是一种可以有效减少 Java 程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。

通过逃逸分析，Java Hotspot 编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。

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

• 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。（栈上分配）

  public void method(){
      V v = new V();  // 栈上分配
      //use V
      //......
      v = null;
  }
  

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

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

上述方法返回的sb在方法外被使用，发生了逃逸，如果想要StringBuffer sb不逃出方法，可以这样写：

public static String createStringBuffer(String s1,String s2){
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb.toString();  // 返回了String对象，sb无法被外部调用
}

如何快速的判断是否发生了逃逸分析，就看 new 的对象实体是否有可能在方法外被调用

public class EscapeAnalysis {

    public EscapeAnalysis obj;

    /*
    方法返回EscapeAnalysis对象，发生逃逸
     */
    public EscapeAnalysis getInstance(){
        return obj == null? new EscapeAnalysis() : obj;
    }
    /*
    为成员属性赋值，发生逃逸
     */
    public void setObj(){
        this.obj = new EscapeAnalysis();
    }
    //思考：如果当前的obj引用声明为static的？仍然会发生逃逸。

    /*
    对象的作用域仅在当前方法中有效，没有发生逃逸
     */
    public void useEscapeAnalysis(){
        EscapeAnalysis e = new EscapeAnalysis();
    }
    /*
    引用成员变量的值，发生逃逸
     */
    public void useEscapeAnalysis1(){
        EscapeAnalysis e = getInstance();
        //getInstance().xxx()同样会发生逃逸
    }
}

参数设置

• 在 JDK 6u23 版本之后，HotSpot 中默认就已经开启了逃逸分析
• 如果使用了较早的版本，可以通过
  • -XX:DoEscapeAnalysis 显式开启逃逸分析
  • -XX:+PrintEscapeAnalysis 查看逃逸分析的筛选结果

结论：开发中能使用局部变量的，就不要使用在方法外定义

代码优化

使用逃逸分析，编译器可以对代码做如下优化：

1. 栈上分配：将堆分配转化为栈分配。如果一个对象在子线程中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
2. 同步省略：如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
3. 分离对象或标量替换：有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在 CPU 寄存器中。

栈上分配

• JIT 编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。分配完成之后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须机型垃圾回收了。
• 常见的发生逃逸的场景：给成员变量赋值、方法返回值、实例引用传递

栈上分配测试

/**
 * 设置不开启逃逸分析
 * -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
 */
public class StackAllocation {
    public static void main(String[] args) {
        long start = System.currentTimeMillis();

        for (int i = 0; i < 10000000; i++) {
            alloc();
        }
        // 查看执行时间
        long end = System.currentTimeMillis();
        System.out.println("花费的时间为： " + (end - start) + " ms");
        // 为了方便查看堆内存中对象个数，线程sleep
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e1) {
            e1.printStackTrace();
        }
    }

    private static void alloc() {
        User user = new User();//未发生逃逸
    }

    static class User {

    }
}

当开启逃逸分析后，执行速度变化，性能提升。

如果将堆空间减少为 -Xmx256m -Xms256m

• 未开启逃逸分析，则会触发GC

• 而开启逃逸分析，不会触发GC

同步省略

• 线程同步的代价是相当高的，同步的后果是降低并发性和性能。

• 在动态编译同步块的时候，JIT 编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。

  如果没有，那么 JIT 编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。

分离对象或标量替换

• 标量（Scalar）：是指一个无法在分解成更小的数据的数据。Java 中的原始数据类型就是标量。
• 相对的，那些还可以分解的数据叫做 聚合量（Aggregate），Java 中对象就是聚合量，因为它可以分解成其他聚合量和标量。
• 在 JIT 阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过 JIT 优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来替代。这个过程就是标量替换。

public class ScalarTest {
    public static void main(String[] args) {
        alloc();   
    }
    public static void alloc(){
        Point point = new Point(1,2);
    }
}
class Point{
    private int x;
    private int y;
    public Point(int x,int y){
        this.x = x;
        this.y = y;
    }
}

标量替换后

public static void alloc(){
    int x = 1;
    int y = 2;
}

Point 这个聚合量经过逃逸分析后，发现没有逃逸，就被替换成两个标量。

标量替换的好处就是可以大大减少堆内存的占用。因为一旦不需要创建对象，就不再需要分配堆内存了。
标量替换为栈上分配提供了很好的基础。

配置参数：

-XX:+EliminateAllocations，开启标量替换（默认开启）

总结

• 关于逃逸分析的论文在1999年就已经发表了，但直到JDK1.6才有实现，而且这项技术到如今也并不是十分成熟的。

• 其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。

• 一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。

• 虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。

• 注意到有一些观点，认为通过逃逸分析，JVM 会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于 JVM 设计者的选择。Oracle Hotspot JVM 中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。

  但至少分离对象或标量替换这一点还是存在的，优化了代码运行的效率，减少了堆空间的占用，体现了栈上分配的思想。

• 目前很多书籍还是基于 JDK7 以前的版本，JDK 已经发生了很大变化，intern 字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是，intern 字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。

小结

• 年轻代是对象的诞生、成长、消亡的区域，一个对象在这里产生、应用、最后被垃圾回收器收集、结束生命。
• 老年代放置长生命周期对象，通常都是从 Survivor 区域筛选拷贝过来的 Java 对象。当然，也有特殊情况，我们知道普通的对象会被分配在TLAB上，如果对象较大，JVM 会试图直接分配在 Eden 其他位置上；如果对象较大，完全无法在新生代找到足够长的连续空闲空间，JVM 就会直接分配到老年代。
• 当 GC 只发生在年轻代中，回收年轻代对象的行为被称为 MinorGC。当 GC 发生在老年代时则被称为 MajorGC 或者 FullGC。一般的，MinorGC 的发生频率要比 MajorGC 高很多，即老年代中垃圾回收发生的频率大大低于年轻代。
• 字符串常量池在堆空间（jdk7及以后）

3.8_方法区 √ ☆

3.8.1_方法区概述

从线程是否共享角度来看运行时数据区结构

堆、栈、方法区的交互关系

person 引用指向堆空间的对象实例数据，它又会指向对象的类型数据。

3.8.2_方法区的基本理解

方法区别名又称 Non-Heap（非堆）。

尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。需要与堆分开。

因此，方法区是一块独立于 Java 堆的内存空间。

• 方法区（Method Area）与 Java 堆一样，是各个线程共享的内存区域。

• 方法区在 JVM 启动时就会被创建，并且它的实际的物理内存空间中和 Java 堆区一样都可以是不连续的。

• 方法区的大小，跟堆空间一样，可以选择固定大小或者可拓展。

• 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误：java.lang.OutOfMemoryError: PermGen space 或者 java.lang.OutOfMemoryError: Metaspace。

  造成的原因可能为：

  • 加载大量的第三方jar包
  • Tomcat 部署的工程过多（30-50个）
  • 大量动态生成反射类

• 关闭 JVM 就会释放这个区域的内存。

3.8.3_Hotspot中方法区的演进

• 在jdk7及以前，习惯上把方法区称为永久代。jdk8 开始，使用元空间取代了永久代。

• 本质上，方法区和永久代并不等价。仅是对 Hotspot 而言的。《java虚拟机规范》对如何实现方法区，不做统一要求。例如：BEA JRockit / IBM J9 中不存在永久代的概念。

  • 现在看来，当年使用永久代，不是好的主意。导致 Java 程序更容易 OOM（超过-XX:MaxPermSize上限）。

• 在 jdk8 中，终于完全废弃了永久代的概念，改用与 JRockit、J9 一样在本地内存中实现的元空间（Metaspace）来代替。

• 元空间的本质和永久代类似，都是对 JVM 规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存（PC内存）。

• 永久代、元空间并不只是名字变了，内部结构也调整了。

• 根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出 OOM 异常.。

3.8.4_设置方法区大小

方法区的大小不必是固定的，JVM 可以根据应用的需要动态调整。

• jdk7及以前（永久代）：

  • -XX:PermSize设置永久代初始分配空间。默认值是 20.75M。
  • -XX:MaxPermSize 设定永久代最大可分配空间。32 位机器默认是 64M，64 位机器模式是 82M。
  • 当 JVM 加载的类信息容量超过了这个值，会报异常OutOfMemoryError: PermGen space。

• jdk8及以后（元空间）：

  • 元数据区大小可以使用参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize指定，替代上述原有的两个参数。

  • 默认值依赖于平台。windows下，-XX:MetaspaceSize是21M，-XX:MaxMetaspaceSize 的值是 -1， 即没有限制。

  • 与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存。 如果元数据区发生溢出，虚拟机一样会拋出异常 OutOfMemoryError: Metaspace。

  • -XX:MetaspaceSize： 设置初始的元空间大小。对于一个64位的服务器端JVM来说， 其默认的-XX:MetaspaceSize值为 21MB。这就是初始的高水位线，一旦触及这个水位线，Full GC 将会被触发并卸载没用的类（即这些类对应的类加载器不再存活），然后这个高水位线将会重置。

    新的高水位线的值取决于 GC 后释放了多少元空间。如果释放的空间不足，那么在不超过 MaxMetaspaceSize 时，适当提高该值。如果释放空间过多，则适当降低该值。

  • 如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次。通过垃圾回收器的日志可以观察到 Full GC 多次调用。为了避免频繁地 GC，建议将 -XX:MetaspaceSize设置为一个相对较高的值。

jdk7及以前：
查询 jps  -> jinfo -flag PermSize [进程id]
    -XX:PermSize=100m -XX:MaxPermSize=100m

jdk8及以后：
查询 jps  -> jinfo -flag MetaspaceSize [进程id]
    -XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m

3.8.5_方法区内存溢出

溢出例子

/**
 * jdk6/7中：
 * -XX:PermSize=10m -XX:MaxPermSize=10m
 *
 * jdk8中：
 * -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
 *
 */
public class OOMTest extends ClassLoader {
    public static void main(String[] args) {
        int j = 0;
        try {
            OOMTest test = new OOMTest();
            for (int i = 0; i < 10000; i++) {
                //创建ClassWriter对象，用于生成类的二进制字节码
                ClassWriter classWriter = new ClassWriter(0);
                //指明版本号，修饰符，类名，包名，父类，接口
                classWriter.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
                //返回byte[]
                byte[] code = classWriter.toByteArray();
                //类的加载
                test.defineClass("Class" + i, code, 0, code.length);//Class对象
                j++;
            }
        } finally {
            System.out.println(j);
        }
    }
}

解决 OOM

要解决 OOM 异常或 heap space 的异常，一般的手段是首先通过内存映像分析工具（如 Eclipse Memory Analyzer） 对 dump 出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow） 。

• 如果是内存泄漏（分配的内存空间未被及时回收），可进一步通过工具查看泄漏对象到 GC Roots 的引用链（堆当中的闲置对象由于引用链的引用关系无法被回收，虽然它已经属于闲置的资源）。于是就能找到泄漏对象是通过怎样的路径与 GC Roots 相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息，以及 GC Roots 引用链的信息，就可以比较准确地定位出泄漏代码的位置。
• 如果不存在内存泄漏，换句话说就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xmx与-Xms） ，与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

3.8.6_方法区的内部结构

用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。

类型信息

对每个加载的类型（ 类class、接口interface、枚举enum、注解annotation），JVM必须在方法区中存储以下类型信息：

• 这个类型的完整有效名称（全名=包名.类名）
• 这个类型直接父类的完整有效名（对于 interface 或是 java. lang.Object，都没有父类）
• 这个类型的修饰符（public， abstract， final 的某个子集）
• 这个类型直接接口的一个有序列表

域（Field，成员变量）信息

• JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
• 域的相关信息包括：域名称、 域类型、域修饰符（public， private， protected， static， final， volatile， transient 的某个子集）

方法（Method）信息

JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序：

• 方法名称
• 方法的返回类型（或 void）
• 方法参数的数量和类型（按顺序）
• 方法的修饰符（public， private， protected， static， final， synchronized， native ， abstract的一个子集）
• 方法的字节码（bytecodes）、操作数栈、局部变量表及大小（ abstract 和 native 方法除外）
• 异常表（Exception table）（ abstract 和 native方法除外）
  • 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

在字节码文件被类加载器加载后，方法区会在类信息中记录所使用的类加载器。

non-final 的类变量（非声明为 final 的 static 静态变量）

• 静态变量和类关联在一起，随着类的加载而加载，他们成为类数据在逻辑上的一部分
• 类变量被类的所有实例所共享，即使没有类实例也可以访问它

下面代码不会报空指针异常

public class MethodAreaTest {
    public static void main(String[] args) {
        Order order = null;
        order.hello();
        System.out.println(order.count);
    }
}

class Order {
    public static int count = 1;
    public static final int number = 2;


    public static void hello() {
        System.out.println("hello!");
    }
}

输出

hello!
1

全局常量（static final）:

被声明为 final 的类变量的处理方法则不同，每个全局常量在编译的时候就被分配了。

如果使用final和static同时修饰一个 field 字段，并且这个字段是基本类型或者String类型的，那么编译器 javac 在编译这个字段的时候，会在对应的field_info结构体中增加一个ConstantValue类型的结构体，在类加载的准备阶段根据**ConstantValue的值进行显示赋值**，它不会被赋予默认值；

而没有被 final 修饰的static 变量 count，它会在准备阶段被初始化为 0 或 null 等默认值，而后在初始化阶段（触发类构造器**<clinit>()** ）进行显示赋值。

示例：

  public static int count;
    descriptor: I
    flags: ACC_PUBLIC, ACC_STATIC

  public static final int number;
    descriptor: I
    flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
    ConstantValue: int 2

<clinit>()

#####运行时常量池 VS 常量池

• 方法区内部包含了运行时常量池
• 字节码文件内部包含了常量池

常量池

一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息那就是常量池表（Constant Pool Table），包括各种字面量和对类型、域和方法的符号引用。

为什么需要常量池？

一个 Java 源文件中的类、接口，编译后产生一个字节码文件。而 Java 中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池；而这个字节码包含了指向常量池的引用。在动态链接的时候会用到运行时常量池。

#num

常量池中有什么？

• 数量值
• 字符串值
• 类引用
• 字段引用
• 方法引用

小结

字节码中的常量池结构（constant pool），可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名，方法名，参数类型、字面量等信息。

运行时常量池

• 运行时常量池（ Runtime Constant Pool）是方法区的一部分。
• 常量池表（Constant Pool Table）是 Class 文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
• 运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池。
• JVM 为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的。
• 运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里换为真实地址。
  • 运行时常量池，相对于Class文件常量池的另一重要特征是：具备动态性。
    • String.intern()
• 运行时常量池类似于传统编程语言中的符号表（symbol table） ，但是它所包含的数据却比符号表要更加丰富一些。
• 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则 JVM 会抛OutOfMemoryError异常。

3.8.7_方法区的使用

案例

public class MethodAreaDemo {
    public static void main(String[] args) {
        int x = 500;
        int y = 100;
        int a = x / y;
        int b = 50;
        System.out.println(a + b);
    }
}

1、sipush 500：将 500 压入操作数栈，程序计数器记录了序号 0

2、istore_1 ：将数据存储到本地变量表 1 的位置

（非静态方法，本地变量表 0 的位置存储 this）

3、bipush 100：将 100 压入操作数栈

4、istore_2：弹出操作数栈栈顶的 100，存储到本地变量表 2 的位置

5、iload_1：读取本地变量 1，压入操作数栈

6、iload_2：读取本地变量 2，压入操作数栈

7、idiv：将栈顶两个 int 类型数弹栈相除，将结果 5 压入操作数栈

8、istore_3：将结果存储到本地变量表 3 的索引位置

9、bipush 50：将 50 压入操作数栈

10、istore 4：弹出操作数栈顶，将 int 类型值保存至局部变量表 4

11、getstatic： # 2 符号引用

12、iload_3：将本地变量表 3 取出，压入操作数栈

13、iload 4：将本地变量表 4 取出，压入操作数栈

14、iadd：将栈顶两 int 类型数弹栈相加，结果入栈

15、invokevirtual：#3 方法引用，调用 pringln方法

16、return：void 函数返回，main 方法执行结束

3.8.8_方法区的演进细节

只有HotSpot才有永久代。 BEA JRockit、IBM J9 等来说，是不存在永久代的概念的。原则上如何实现方法区属于虛拟机实现细节，不受《Java虚拟机规范》管束，并不要求统一。

Hotspot中方法区的变化：

演变过程

jdk1.8 及之后： 无永久代，类型信息、字段、方法、常量保存在本地内存的元空间。

但字符串常量池、静态变量仍留在堆空间。

除此之外，元空间（或称方法区），不再使用虚拟机内存，而是使用本地内存。

永久代为什么要被元空间替换？

• 随着 Java8 的到来，HotSpot VM 中再也见不到永久代了。但是这并不意味着类的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域，这个区域叫做元空间（ Metaspace ）。

• 由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。

• 这项改动是很有必要的，原因有：

  • 为永久代设置空间大小是很难确定的。 在某些场景下，如果动态加载类过多，容易产生 Perm区的 OOM。比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现致命错误。

    • "Exception in thread' dubbo client x.x connector' java.lang.OutOfMemoryError: PermGenspace"

    而元空间和永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。

  • 对永久代进行调优是很困难的。

StringTable为什么要调整？

• jdk7中将 StringTable 放到了堆空间中。
• 因为永久代的回收效率很低，在 full gc 的时候才会触发。而full GC 是老年代的空间不足、永久代不足时才会触发。这就导致了 StringTable 回收效率不高。而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。

静态变量存放在哪？

静态引用对应的对象实体始终都存放在堆空间。

静态变量、成员变量、局部变量的存放位置

/**
 * 《深入理解Java虚拟机》中的案例：
 * staticObj、instanceObj、localObj 存放在哪里？
 */
public class StaticObjTest {
    static class Test {
        static ObjectHolder staticObj = new ObjectHolder();
        ObjectHolder instanceObj = new ObjectHolder();

        void foo() {
            ObjectHolder localObj = new ObjectHolder();
            System.out.println("done");
        }
    }

    private static class ObjectHolder {
    }

    public static void main(String[] args) {
        Test test = new StaticObjTest.Test();
        test.foo();
    }
}

staticObj 变量随着 Test 的类型信息存放在方法区，instanceObj 成员变量随着 Test 的对象实例存放在 Java 堆，localObj 局部变量则是存放在 foo() 方法栈帧的局部变量表中。

hsdb>scanoops 0x00007f32c7800000 0x00007f32c7b50000 JHSDB_ _TestCase$Obj ectHolder
0x00007f32c7a7c458 JHSDB_ TestCase$Obj ectHolder
0x00007f32c7a7c480 JHSDB_ TestCase$Obj ectHolder
0x00007f32c7a7c490 JHSDB_ TestCase$Obj ectHolder

测试发现：三个对象的数据在内存中的地址都落在Eden区范围内（scanoops 0x00007f32c7800000 0x00007f32c7b50000 JHSDB_ _TestCase$Obj ectHolder），所以结论：只要是对象实例必然会在 Java 堆中分配。

接着，找到了一个引用该 staticObj 对象的地方，是在一个 java.lang.Class 的实例里，并且给出了这个实例的地址。

通过 Inspector 查看该对象实例，可以清楚看到这确实是一个 java.lang.Class 类型的对象实例，里面有一个名为 staticObj 的实例字段：

• 从《Java 虛拟机规范》所定义的概念模型来看，所有 Class 相关的信息都应该存放在方法区之中，但方法区该如何实现，《Java 虚拟机规范》并未做出规定，这就成了一件允许不同虚拟机自己灵活把握的事情。
• JDK7 及其以后版本的 Hotspot 虚拟机选择把静态变量与类型在 Java 语言一端的映射 Class 对象存放在一起，存储于 Java 堆之中。

3.8.9_方法区的垃圾回收

有些人认为方法区（如Hotspot，虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java 虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如 JDK11 时期的 ZGC 收集器就不支持类卸载）。

​ 一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前 Sun 公司的 Bug 列表中，曾出现过的若干个严重的 Bug 就是由于低版本的 Hotspot 虚拟机对此区域未完全回收而导致内存泄漏。

方法区的垃圾收集主要回收两部分内容：常量池中废奔的常量和不再使用的类型。

常量池中废奔的常量

• 先来说说方法区内常量池之中主要存放的两大类常量：字面量和符号引用。

  字面量比较接近 Java 语言层次的常量概念，如文本字符串、被声明为 final 的常量值等。而符号引用则属于编译原理方面的概念。

• 常量池中包括下面三类常量：

  • 1、类和接口的全限定名
  • 2、字段的名称和描述符
  • 3、方法的名称和描述符

• HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。回收废弃常量与回收 Java 堆中的对象非常类似。

常量池中不再使用的类型

• 判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：

  • 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类及其任何派生子类的实例。
  • 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如 OSGi、JSP 的重加载等，否则通常是很难达成的。
  • 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

• Java虛拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot 虚拟机提供了 -Xnoclassgc 参数进行控制，还可以使用 -verbose: class 以及 -XX: +TraceClass-Loading 、-XX: +TraceClassUnLoading 查看类加载和卸载信息

• 在大量使用反射、动态代理、CGLib 等字节码框架，动态生成 JSP 以及 OSGi 这类频繁自定义类加载器的场景中，通常都需要 Java 虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

3.9_小结

运行时数据区