JVM 内存与垃圾回收篇-3-运行时数据区
运行时数据区
内存是非常重要的系统资源，是硬盘和CPU 的中间仓库及桥梁承载着操作系统和应用程序的实时运行。JVM内存布局规定了Java在运行过程中内存申请、分配、管理的策略，保证了JM的高效稳定运行。不同的JVM对于内存的划分方式和管理机制存在着部分差异。结合JVM虚拟机规范，来探讨一下经典的JVM内存布局。
Java虚拟机定义了若干种程序运行期间会使用到的运行时数据区，其中有一些会随着虚拟机启动而创建，随着虚拟机退出而销毁。另外一些则是与线程一一对应的，这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。
灰色的为单独线程私有的，红色的为多个线程共享的。即:
- 每个线：独立包括程序计数器、栈、本地栈。
- 线程间共享：堆、堆外内存(永久代或元空间、代码缓存)
程序计数器
PC寄存器用来存储指向下一条指令的地址，也即将要执行的指令代码。由执行引擎读取下一条指令。
- 它是一块很小的内存空间，几乎可以忽略不记。也是运行速度最快的存储区域。
- 在JVM规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的生命周期保持一致。
- 任何时间一个线程都只有一个方法在执行（当前方法）。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址：或者，如果是在执行native方法，则是未指定值（undefined）
- 它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成
- 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令
- 它是唯一一个在Java 虚拟机规范中没有规定任何outotMemoryError情况的区域
虚拟机栈
内存中的栈与堆
栈是运行时的单位，而堆是存储的单位。
栈解决程序的运行问题，即程序如何执行，或者说如何处理数据。堆解决的是数据存储的问题，即数据怎么放、放在哪儿。
Java虚拟机栈
每个线程在创建时会创建一个虚拟机栈，其内部保存一个个的栈帧（StackFrame）对应着一次次的Java方法调用
- 生命周期：与线程一致
- 作用：主管Java程序运行，保存方法的局部变量、部分结果，并参与方法调用和返回
栈中的异常
Java 虚拟机规范允许Java栈的大小是动态的或者是固定不变的
- 如果采用固定大小的Java虚拟机栈，那每一个线程的Java虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过JaJa虚拟机栈允许的最大容量，Java虚拟机将会抛出一个StackOverflowError 异常
- 如果Java虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那Java虚拟机将会抛出一个 OutofMemoryError 异常
设置栈内存大小
使用参数-Xss选项设置线程的最大占空间，栈的大小直接决定函数调用的最大可达深度
栈的存储单位
- 每个线程都有自己的栈，栈中的数据都是以栈帧（Stack Frame) 的格式存在
- 在这个线程上正在执行的每个方法都各自对应一个栈帧(Stack Frame)
- 栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息。
栈运行原理
JVM直接对Java栈的操作只有两个，就是对栈帧的压栈和出栈，遵循“先进后出”原则
在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧(栈顶栈帧) 是有效的，这个栈帧被称为当前栈帧(Current Frame)，与当前栈相对应的方法就是当前方法 (CurrentMethod)，定义这个方法的类就是当前类 (Current Class)
- 执行引擎运行的所有字节码指令只针对当前栈帧进行操作
- 如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前帧
- 不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈领之中引用另外一个线程的栈帧。
- 如果当前方法调用了其他方法，方法返回之际，当前栈会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧
- Java方法有两种返回函数的方式，，一种是正常的函数返回，使用return指令: 另外一种是抛出异常。不管使用哪种方式，都会导致栈顿被弹出
栈帧的内部结构
每个栈帧中存储着：
- 局部变量表 (Local Variables)
- 操作数栈 (Operand Stack) (或表达式栈)
- 动态链接（Dynamic Linking）（或指向运行时常量池的方法引用）
- 方法返回地址（Return Address）（或方法正常退出或者异常退出的定义）
- 一些附加信息
局部变量表
- 局部变量表也被称之为局部变量数组或本地变量表
- 定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量。这些数据类型包括各类基本数据类型、对象引用 (reference)，以及returnAddress类型。
- 由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题
局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的Code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。
方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少
- 局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后随着方法栈帧的销毁，局部变量表也会随之销毁。
Slot
- 参数值的存放总是在局部变量数组的index0开始，到数组长度-1的索引结束。
- 局部变量表，最基本的存储单元是slot (变量槽)
- 局部变量表中存放编译期可知的各种基本数据类型(8种)，引用类型(reference)，returnAddress类型的变量
- 在局部变量表里，32位以内的类型只占用一个slot （包括returnAddress类型），64位的类型（long和double）占用两个slot
- byte、short、char在存储前被转换为int，boolean也被转换为int，0表示false，非0表示true
- long和double则占据两个slot
- JVM会为局部变量表中的每一个slot都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值
- 当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个slot上
- 如果需要访问局部变量表中一个64bit的局部变量值时，只需要使用前一个索引即可。(访问long或double类型变量)
- 如果当前帧是由构造方法或者实例方法创建的，那么该对象引用this将会存放在index为0的slot处，其余的参数按照参数表顺序继续排列。
静态变量与局部变量的对比
- 参数表分配完毕之后，再根据方法体内定义的变量的顺序和作用域分配。
- 类变量表有两次初始化的机会，第一次是在“准备阶段”，执行系统初
始化，对类变量设置零值，另一次则是在“初始化”阶段，赋予程序员在代码中定义的初始值。 - 与类变量初始化不同的是，局部变量表不存在系统初始化的过程，这意味着一旦定义局部变量则必须人为的初始化，否则无法使用
补充说明
- 在栈帧中，与性能调优关系最为密切的部分就是前面提到的局部变量表。在方法执行时，虚拟机使用局部变量表完成方法的传递。
- 局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。
操作数栈
每一个独立的栈帧中除了包含局部变量表以外，还包含一个后进先出的操作数栈，也称之为表达式栈(Expression stack）。
操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据,即入栈(push)/出栈(pop) .
某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈。
如：执行复制、交换、求和等操作
操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间
操作数栈就是JVM执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的
每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的code属性中，为max_stack的值。
栈中的任何一个元素都是可以任意的Java数据类型。
- 32bit的类型占用一个栈单位深度
- 64bit的类型占用两个栈单位深度
操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈（push）和出栈（pop）操作来完成一次数据访问。
如果被调用的方法带有返回值，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。
操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译器期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。
另外，所谓的Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。
代码追踪
处理过程图
栈顶缓存技术
基于栈式架构的虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派次数和内存读/写次数。
由于操作数是存储在内存中的，因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题，提出了栈顶缓存技术，将栈顶元素全部缓存在物理CPU的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率。
动态链接
- 每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接。
- 在Java源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用保存在class文件的常量池里，比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用。
为什么需要该常量池
提供一些符号和常量。便于指令的识别
方法的调用
在JVM中，将行号引用转换为调用方法的直接引用与方法的绑定机制相关。
静态链接
当一个字节码文件被装载进JVM内部时，如果被调用的目标方法在编译期可知，且运行期保持不变时。这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接。
动态链接
如果被调用的方法在编译期无法被确定下来，只能够在程序运行期将调用方法的符号引用转换为直接引用，由于这种引用转换过程具备动态性，因此也就被称之为动态链接。
对应的方法的绑定机制为：早期绑定（Early Binding）和晚期绑定(Late Binding）。绑定是一个字段、方法或者类在符号引用裤替换为直接引用的过程，这仅仅发生一次。
早期绑定
早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，由于明确了被调用的目标方法，因此可以使用静态链接的方式将符号引用转换为直接引用。
晚期绑定
如果被调用的方法在编译期无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式称为晚期绑定。
非虚方法
- 如果方法在编译期就确定了具体的调用版本，这个版本在运行时是不可变的这样的方法称为非虚方法
- 静态方法、私有方法、final方法、实例构造器、父类方法都是非虚方法。
- 其他方法称为虚方法。
虚拟机中提供了以下几条方法调用指令
普通调用指令
| 调用指令 | 说明 |
|---|---|
| invokestatic | 调用静态方法，解析阶段确定唯一方法版本 |
| invokespecial | 调用<init>方法、私有及父类方法，解析阶段确定唯一方法版本 |
| invokevirtual | 调用所有虚方法 |
| invokeinterface | 调用接口方法 |
动态调用指令
| 调用指令 | 说明 |
|---|---|
| invokedynamic | 动态解析出需要调用的方法，然后执行 |
前四条指令固化在虚拟机内部，方法的调用执行不可人为干预。invokedynamic指令则支持由用户确定方法版本。其中invokestatic指令和invokespecial指令调用的方法称为非虚方法，其余的（final修饰的除外）称为虚方法。
动态类型语言和静态类型语言
动态类型语言和静态类型语言两者的区别就在于对类型的检查是在编译期还是在运行期，满足前者就是静态类型语言，反之是动态类型语言。
静态类型语言是判断变量自身的类型信息；动态类型语言是判断变量值的类型信息，变量没有类型信息，变量值才有类型信息，这是动态语言的一个重要特征。
方法重写的本质
- 找到操作数栈顶的第一个元素所执行的对象的实际类型，记作C
- 如果在类型C中找到与常量中的描述符合简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束；如果不通过，则返回
java.lang.IllegalAccessError异常。 - 否则，按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程
- 如果始终没有找到合适的方法，则抛出
java.lang.AbstractMethodError异常。
虚方法表
- 在面向对象的编程中，会很频繁的使用到动态分派，如果在每次动态分派的过程中都要重新在类的方法元数据中搜索合适的目标的话就可能影响到执行效率。因此，为了提高性能，JVM采用在类的方法区建立一个虚方法表(virtual method table）(非虚方法不会出现在表中)来实现。使用索引表来代替查找。
- 每个类中都有一个虚方法表，表中存放着各个方法的实际入口。
- 虚方法表创建时机：虚方法表会在类加载的链接阶段被创建并开始初始化，类的变量初始值准备完成之后，JVM会把该类的方法表也初始化完毕。
方法返回地址
- 作用：存放调用该方法的pc寄存器的值
- 一个方法的结束，有两种方式:
- 正常执行完成
- 出现未处理的异常，非正常退出
无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，调用者的pc计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是要通过异常表来确定，栈帧中一般不会保存这部分信息。
本质上，方法的退出就是当前伐帧出栈的过程。此时，需要恢复上层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等，让调用者方法继续执行下去。
- 正常完成出口和异常完成出口的区别：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值。
当一个方法开始执行后，只有两种方式可以退出这个方法
执行引擎遇到任意一个方法返回的字节码指令，会有返回值传递给上层的方法调用者，简称正常完成出口
- 一个方法在正常调用完成之后究竟霜要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定
- 在字节码指令中，返回指令包含ireturn（当返回值是boolean、byte、char.short和int类型时使用）、lreturn、 freturn. dreturn以及areturn，另外还有一个return指令供声明为void的方法、实例初始化方法、类和接口的初始化方法使用
在方法执行的过程中遇到了异常（Exception)，并且这个异常没有在方法内进行处理，也就是只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出。简称异常完成出口。
- 方法执行过程中抛出异常时的异常处理，存储在一个异常处理表，方便在发生异常的时候找到处理异常的代码
一些附加信息
栈帧中还允许携带与Java虚拟机实现相关的一些附加信息。例如，对程序调试提供支持的信息。
本地方法栈
本地方法接口
Native Method
Native Method就是一个Java调用非Java代码的接口，该方法的实现由非Java语言实现。在定义一个native method时，并不提供实现体（有些像定义一个Javainterface)，因为其实现体是由非java语言在外面实现的。
本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C++程序。
Why Native Method
与Java环境外交互：
有时Java应用需要与Java外面的环境交互，这是本地方法存在的主要原因。它为我们提供了一个非常简洁的接口，而且我们无需去了解Java应用之外的繁琐的细节。
与操作系统交互
JVM支持着Java语言本身和运行时库，它是Java程序赖以生存的平台，它由一个解释器（解释字节码）和一些连接到本地代码的库组成。它毕竟不是一个完整的系统，它经常依赖于一些底层系统的支持。
本地方法栈
- Java虚拟机栈用于管理Java方法的调用，而本地方法栈用于管理本地方法的调用。
- 本地方法栈，也是线程私有的。
- 允许被实现成固定或者是可动态扩展的内存大小。(在内存溢出方面是相同的)
- 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个stackoverflowError异常。
- 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，
或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么Java虚拟机将会抛出一个outofMemoryError异常
- 本地方法是使用C实现的
- 它的具体做法是Native Method stack中登记native方法，在Execution Engine执行时加载本地方法库。
- 当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限
- 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区
- 它甚至可以直接使用本地处理器中的寄存器
- 直接从本地内存的堆中分配任意数量的内存
并不是所有的JVM都支持本地方法。因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持native方法，也可以无需实现本地方法栈。
在Hotspot JVM中，直接将本地方法栈和虚拟机栈合二为一
堆
堆的核心概述
- 一个进程对应一个JVM实例，一个JVM实例只存在一个堆内存和方法区，堆也是Java内存管理的核心区域。
- Java堆区在JVM启动的时候即被创建，其空间大小也就确定了。是JVM管理的最大一块内存空间。
堆内存的大小是可以调节的 - 《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
- 所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区( Thread Local Allocation Buffer,TLAB)
- 数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置
- 在方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除
- 堆，是GC ( Garbage Collection，垃圾收集器）执行垃圾回收的重点区域
内存细分
设置堆内存大小
Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，可以通过选项-Xmx和-Xms来进行设置
| 参数 | 说明 |
|---|---|
-Xms（年轻代+老年代） |
用于表示堆区的起始内存，等价于-Xx:InitialHeapsize |
-Xmx（年轻代+老年代） |
用于表示堆区的最大内存，等价于-XX:MaxHeapsize |
- 一旦堆区中的内存大小超过
-Xmx所指定的最大内存时，将会抛出OutofMemoryError异常。 - 通常会将
-Xms和-Xmx两个参数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。 - 默认情况下，初始内存大小：物理电脑内存大小/ 64，最大内存大小：物理电脑内存大小/ 4
查看设置的参数
- 方式1：
jps / jstat -gc 进程id - 方式 2：
-XX:+PrintGCDetails
年轻代与老年代
存储在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
| 参数 | 说明 |
|---|---|
-XX:NewRatio |
设置新生代与老年代的比例，默认值是2 |
-XX:SurvivorRatio |
设置新生代中Eden区与Survivor区的比例，默认值是8 |
-XX:UseAdaptiveSizePolicy |
关闭自适应的内存分配策略 |
-Xmn |
设置新生代最大内存大小 |
- 在HotSpot中，Eden空间和另外两个survivor空间缺省所占的比例是8:1:1
- 几乎所有的Java对象都是在Eden区被new出来的。
- 绝大部分的Java对象的销毁都在新生代进行
- 可以使用选项
-Xmn设置新生代最大内存大小，参数一般使用默认值
对象分配过程
为新对象分配内存是一件非常严谨和复杂的任务，JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑Gc执行完内存回收后是否会在内存空间中产生内存碎片。
一般情况
特殊情况
- new的对象先放伊甸园区。此区有大小限制
- 当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃
圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区 - 然后将伊甸园中的剩余对象移动到幸存者0区。
- 如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会
放到幸存者1区。 - 如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区
啥时候能去养老区呢?可以设置次数。默认是15次，可以设置参数
-XX:MaxTenuringThreshold=<N>当养老区内存不足时，再次触发GC: Major GC，进行养老区的内存清理。
- 若养老区执行了Major GC之后发现依然无法进行对象的保存，就会产生OOM异常
注意：Eden区满时触发YGC，但幸存者区满时不会触发YGC
总结
- 针对幸存者se,s1区的总结:复制之后有交换，谁空谁是
to - 关于垃圾回收：频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间收集。
Minor GC、Major GC、Full GC
JVM在进行GC时，并非每次都对上面三个内存（新生代、老年代、方法区）区域一起回收的，大部分时候回收的都是指新生代
针对HotSpot VM的实现，它里面的Gc按照回收区域又分为两大种类型:一种是部分收集（Partial GC），一种是整堆收集（Full GC）
- 部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为:
- 新生代收集(Minor GC / Young GC)：只是新生代（Eden\S0、S1）的垃圾收集
- 老年代收集（Major GC / Old GC)：只是老年代的垃圾收集
- 目前，只有CMS GC会有单独收集老年代的行为
- 注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收
- 混合收集（Mixed GC)：收集整个新生代以及部分老年代的垃圾收集
- 目前，只有G1 GC会有这种行为
- 整堆收集（Full GC)：收集整个java堆和方法区的垃圾收集
年轻代GC（Minor GC）触发机制：
- 当年轻代空间不足时，就会触发Minor GC，这里的年轻代满指的是Eden代满，Survivor满不会引发GC。(每次Miror GC会清理年轻代的内存。)
- 因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快
- Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行
老年代GC（Major GC/Full GC）触发机制：
- 指发生在老年代的GC，对象从老年代消失时，“Major GC”或“Full GC”发生
- 出现Major GC，经常会伴随至少一次的Minor GC（但非绝对的），在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC
- Major GC的速度一般会比Minor GC慢1e倍以上，STW的时间更长。如果Major GC后，内存还不足，就报OOM
- Major GC的速度一般会比Minor GC慢
Full GC触发机制：
- 调用System.gc()时，系统建议执行Full GC，但是不必然执行
- 老年代空间不足
- 方法区空间不足
- 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
- 由Eden区、survivor space0 (From Space）区向survivor space1 (ToSpace）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
堆空间分代思想
分代的唯一理由就是优化GC性能。如果没有分代，那所有的对象都在一块。GC的时要找到哪些对象没用这样就会对堆的所有区域进行扫描。
而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。
内存分配策略
- 优先分配到Eden
- 大对象直接分配到老年代，尽量避免程序中出现过多的大对象
- 长期存活的对象分配到老年代
- 动态对象年龄判断：如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold 中要求的年龄。
- 空间分配担保：
-Xx:HandlePromotionFailure
为对象分配内存：TLAB
Why TLAB（Thread Local Allocation Buffer）
- 堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据
- 由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的
- 为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。
TLAB
- 从内存模型而不是垃圾收集的角度对Eden区域继续进行划分，JVM为每个线程分配了一个私有缓存区域,它包含在Eden空间内。
- 多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略
- 尽管不是所有的对象实例都能够在TLAB中成功分配内存，但JVM确实是将TLAB作为内存分配的首选。
- 在程序中，开发人员可以通过选项
-xx:UseTLAB设置是否开启TLAB空间 - 默认情况下，TLAB空间的内存非常小，仅占有整个Eden空间的1%，当然我们可以通过选项
-xX:TLABWasteTargetPercent设置TLAB空间所占用Eden空间的百分比大小。 - 一旦对象在TLAB空间分配内存失败时，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存。
对象分配过程：TLAB
堆空间的参数设置
| 堆空间的参数 | 说明 |
|---|---|
-XX:+PrintFlagsInitial |
查看所有的参数的默认初始值 |
-XX:+PrintFlagsFinal |
查看所有的参数的最终值（可能会存在修改，不再是初始值) |
-Xms |
初始堆空间内存（默认为物理内存的1/64） |
-Xmx |
最大堆空间内存（默认为物理内存的1/4） |
-Xmn |
设置新生代的大小（初始值及最大值） |
-XX:NewRatio |
配置新生代与老年代在堆结构的占比 |
-XX:SurvivorRatio |
设置新生代中Eden和S0/S1空间的比例- |
-XX:MaxTenuringThreshold |
设置新生代垃圾的最大年龄 |
-XX:+PrintGCDetails |
输出详细的cc处理日志 |
-XX:+PrintGC |
打印gc简要信息 |
-verbose:gc |
打印gc简要信息 |
-XX:HandlePromotionFailure |
是否设置空间分配担保，JDK7后失效 |
堆是否是分配对象的唯一选择
在Java虚拟机中，对象是在Java堆中分配内存的，有一种特殊情况，那就是如果经过逃逸分析(Escape Analysis)后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。
逃逸分析
- 使用逃逸分析手段将堆上的对象分配到栈，这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法
- 通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上
- 逃逸分析的基本行为就是分析对象动态作用域 ：
- 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸，没有发生逃逸的对象，则可以分配到栈上，随着方法执行的结束，栈空间就被移除
- 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。
参数设置
- 在JDK 6u23版本之后，HotSpot中默认就已经开启了逃逸分析
- 如果使用的是较早的版本，开发人员则可以通过：
- 选项
-XX: +DoEscapeAnalysis显式开启逃逸分析 - 通过选项
-XX:+PrintEscapeAnalysis查看逃逸分析的筛选结果
- 选项
结论
开发中能使用局部变量 的，就不要在方法外定义
- JIT编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。无须进行垃圾回收
- 常见的栈上分配的场景：成员变量赋值、方法返回值、实例引用传递
代码优化
使用逃逸分析，编译器可以对代码做出如下优化：
栈上分配 ：
将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
同步省略：
如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。
分离对象或标量替换：
有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。
标量（Scalar）是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。
相对的，那些还可以分解的数据叫做聚合量（Aggregate），Java中的对象就是聚合量，因为他可以分解成其他聚合量和标量。
在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。
标量替换参数设置∶参数-XX:+EliminateAllocations:开启标量替换(默认打开)，允许将对象打散分配在栈上。
最终结论
对象实例都是分配在堆上
方法区
栈、堆、方法区的交互关系
运行时数据区角度
线程共享角度
栈、堆、方法区交互关系
方法区的理解
对于HotSpotJVM而言，方法区别名叫做Non-Heap（非堆），目的是和堆分开。方法区看作独立于Java堆的内存空间
- 方法区（Method Area）与Java堆一样，是各个线程共享的内存区域
- 方法区在JVM启动的时候被创建，并且它的实际的物理内存空间中和Java堆区一样都可以是不连续的
- 方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展
- 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误
java.lang. outofMemoryError:PermGen space或者java. lang.outofMemoryError:Metaspace - 关闭JVM就会释放这个区域的内存
设置方法区大小
Jdk8及以后:
- 元数据区大小可以使用参数
-XX:Metaspacesize和-XX:MaxMetaspaceSize指定，替代上述原有的两个参数 - 默认值依赖于平台。windows下，-XX:Metaspacesize是21，-XX:MaxMetaspacesize的值是-1，即没有限制
- 与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存。如果元数据区发生溢出，虚拟机一样会抛出异常OutofMemoryError: Metaspace
-XX:Metaspacesize:设置初始的元空间大小。对于一个64位的服务器端JVM来说，其默认的-XX:Metaspacesize值为21MB。这就是初始的高水位线，一旦触及这个水位线，Full GC将会被触发并卸载没用的类（即这些类对应的类加载器不再存活），然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间。如果释放的空间不足，那么在不超过MaxMetaspacesize时，适当提高该值。如果释放空间过多，则适当降低该值。- 如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次。通过垃圾回收器的日志可以观察到Full GC多次调用。为了避免频繁地GC，建议将-XX: Metaspacesize设置为一个相对较高的值。
方法区的内部结构
方法区通常用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等
类型信息
对每个加载的类型（类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方法除外）
- 异常表（abstract和native方法除外）
每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
运行时常量池与常量池
- 方法区，内部包含了运行时常量池
- 字节码文件，内部包含了常量池
WHY 常量池
一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息那就是常量池表(Constant Pool Table)，包括各种字面量和对类型、域和方法的符号引用。
一个Java源文件中的类、接口，编译后产生一个字节码文件。而Java中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，可以存到常量池，这个字节码包含了指向常量池的引用。在动态链接的时候会用到运行时常量池
WHAT 常量池
在常量池内存储的数据类型包括数量值、字符串值、类引用、字段引用、方法引用
常量池可以看作一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量类型
WHAT 运行时常量池
- 运行时常量池（Runtime constant Pool）是 方法区 的一部分
- 常量池表（Constant Pool Table）是 Class 文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
- 在加载类和接口到虚拟机后，就会创建对应的运行时常量池
- JVM为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的。
- 运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址，这里换为真实地址
- 运行时常量池，相对于class文件常量池的另一重要特征是：具备动态性
- 运行时常量池类似于传统编程语言中的符号表（symbol table），但是它所包含的数据却比符号表要更加丰富一些
- 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过方法区所能提供的最大值，则JVM会抛OOM异常。
方法区使用举例
1 | public static void main(String[] args) { |
方法区的演进细节
永久代为什么要被元空间替换
随着Java8的到来，HotSpot VM中再也见不到永久代了。但是这并不意味着类的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域，这个区域叫做元空间（Metaspace） 。由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。
- 为永久代设置空间大小很难确定：在某些场景下，如果动态加载类过多，容易产生Perm区的OOM，而元空间和永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存，默认情况下，元空间大小仅受本地内存限制
- 对永久代进行调优很困难
StringTable为什么要调整
jdk7中将StringTable放到了堆空间中。因为永久代的回收效率很低，在full gc的时候才会触发。而full gc是老年代的空间不足、永久代不足时才会触发。
这就导致StringTable回收效率不高。而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。
方法区的垃圾回收
方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型
总结
