运行时数据区

JVM中的程序计数寄存器（Program Counter Register），Register的命名源于CPU的寄存器，寄存器存储指令相关的现场信息。CPU只有把数据装载到寄存器才能够运行。这里，并非是广义上所指的物理寄存器，或许将其翻译为PC计数器（或指令计数器）会更加贴切（也称为程序钩子），并且也不容易引起一些不必要的误会。JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟。

作用：程序计数器用来存储指向下一条指令的地址，也就是即将要执行的指令代码。由执行引擎读取下一条指令。

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

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

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

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

字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。

它是唯一一个在Java虚拟机规范中没有规定任何OOM（OutofMemoryError）情况的区域（没有GC、OOM）。

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

因为CPU需要不停的切换各个线程,这时候切换回来以后,就得知道接着从哪开始继续执行

JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令

PC寄存器为什么设定为线程私有? 为了能够准确记录各个线程正在执行的当前字节码指令地址,最好的办法自然是为每一个线程都分配一个PC寄存器

本地方法栈

什么是本地方法？

本地方法接口的作用是融合不同的编程语言为Java所用,它的初衷是融合C/C++程序,Java诞生的时候是C/C++横行的时候,要想立足,必须由调用C/C++程序,于是就在内存中专门开辟了一块区域处理标记为native的代码。

本地方法栈

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

本地方法栈，也是线程私有的。

允许被实现成固定或者是可动态扩展的内存大小。（在内存溢出方面是相同的）

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

它的具体做法是在本地方法栈(Native Method Stack)中登记native方法,在Execution Engine执行时加载本地方法库（native libraies）。

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

本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区。
它甚至可以直接使用本地处理器中的寄存器
直接从本地内存的堆中分配任意数量的内存。

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

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

Java虚拟机栈

内存中的栈与堆

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

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

Java虚拟机栈是什么？

Java虚拟机栈（Java Virtual Machine Stack），早期也叫Java栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame）（局部变量表 | 操作数栈 | 动态链接 | 方法返回地址 | 一些附加信息），对应着一次次的Java方法调用，是线程私有的。

生命周期

生命周期和线程一致

作用

主管Java程序的运行，它保存方法的局部变量、部分结果，并参与方法的调用和返回。

栈的特点

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

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

每个方法执行，伴随着进栈
执行结束后的出栈工作

对于栈来说不存在垃圾回收问题（栈存在溢出的情况）

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

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

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

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

栈帧的内部结构

每个栈帧中存储着：

局部变量表（Local Variables）
操作数栈（operand Stack）（表达式栈）
动态链接（DynamicLinking）（指向运行时常量池的方法引用）
方法返回地址（Return Address）（方法正常退出或者异常退出的定义）
一些附加信息

栈帧的大小主要由局部变量表和操作数栈决定。

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

如果采用固定大小的Java虚拟机栈,那每一个线程的Java虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过Java虚拟机栈允许的最大容量,Java虚拟机将会抛出一个StackoverflowError异常

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

如何设置栈内存的大小？ -Xss size (即:-XX:ThreadStackSize) 一般默认为512k-1024k,取决于操作系统(jdk5之前,默认栈大小是256k;jdk5之后,默认栈大小是1024k)

栈的大小直接决定了函数调用的最大可达深度

局部变量表

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

定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型、对象引用（reference），以及returnAddress类型。
由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题
局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的Code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。
方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。
局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。

可以在ideal中使用jclasslib工具查看当前方法的信息。

java 复制代码

	@Test
	void test1(){
		int a=10;
		String s="123";
		double d=10.0;
		float f=9.0f;
	}

局部变量表，最基本的存储单元是Slot（变量槽）
参数值的存放总是在局部变量数组的index0开始，到数组长度-1的索引结束。
局部变量表中存放编译期可知的各种基本数据类型（8种），引用类型（reference），returnAddress类型的变量。
在局部变量表里，32位以内的类型只占用一个slot（包括returnAddress类型），64位的类型（long和double）占用两个slot。
byte、short、char 在存储前被转换为int，boolean也被转换为int，0表示false，非0表示true。
JVM会为局部变量表中的每一个Slot都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值
当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个slot上
如果需要访问局部变量表中一个64bit的局部变量值时，只需要使用前一个索引即可。（比如：访问long或double类型变量）
如果当前帧是由构造方法或者实例方法创建的，那么该对象引用this将会存放在index为0的slot处，其余的参数按照参数表顺序继续排列。

Slot的重复利用

栈帧中的局部变量表中的槽位是可以重用的，如果一个局部变量过了其作用域，那么在其作用域之后申明的新的局部变就很有可能会复用过期局部变量的槽位，从而达到节省资源的目的。

java 复制代码

public class SlotTest {
    public void localVarl() {
        int a = 0;
        System.out.println(a);
        int b = 0;
    }
    public void localVar2() {
        {
            int a = 0;
            System.out.println(a);
        }
        //此时的就会复用a的槽位
        int b = 0;
    }
}

静态变量与局部变量的对比

参数表分配完毕之后，再根据方法体内定义的变量的顺序和作用域分配。

我们知道类变量表有两次初始化的机会，第一次是在"准备阶段"，执行系统初始化，对类变量设置零值，另一次则是在"初始化"阶段，赋予程序员在代码中定义的初始值。

和类变量初始化不同的是，局部变量表不存在系统初始化的过程，这意味着一旦定义了局部变量则必须人为的初始化，否则无法使用。

java 复制代码

public void test(){
    int i;
    System. out. println(i);
}

这样的代码就是错误的，没有赋值不能够使用。

补充说明

局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。

操作数栈

每一个独立的栈帧包含一个后进先出（Last-In-First-Out）的操作数栈，也可以称之为表达式栈（Expression Stack）

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

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

代码举例

java 复制代码

public void testAddOperation(){
    byte i = 15; 
    int j = 8; 
    int k = i + j;
}

其对应的字节码指令信息

java 复制代码

	0: bipush 15 //将15入栈
    2: istore_1 //把15存储到局部变量表索引为1的位置，同时出栈
    3: bipush 8 //将8入栈
    5: istore_2 //把8存储到局部变量表中索引为2的位置，同时出栈
    6:iload_1 
    7:iload_2 
    8:iadd
    9:istore_3 
    10:return

执行流程

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

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

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

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

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

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

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

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

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

栈顶缓存 前面提过,基于栈式架构的虚拟机所使用的零地址指令更加紧凑,但完成一项操作的时候必然需要使用更多的入栈和出栈指令,这同时也就意味着将需要更多的指令分派(instruction dispatch)次数和内存读/写次数。

由于操作数是存储在内存中的,因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题,HotSpot JVM的设计者们提出了栈顶缓存(ToS,Top-of-Stack Cashing)技术,将栈顶元素全部缓存在物理CPU的寄存器中,以此降低对内存的读/写次数,提升执行引擎的执行效率(将计算的操作放到CPU寄存器里面去)

动态链接

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

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

为什么需要运行时常量池呢？

常量池的作用：就是为了提供一些符号和常量，便于指令的识别

方法的调用

静态链接(早期绑定):当一个字节码文件被装载进JVM内部时,如果被调用的目标方法在编译期可知,且运行期保持不变时。这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接 (invokestatic | invokespecial)

动态链接(晚期绑定):如果被调用的方法在编译期无法被确定下来,也就是说,只能够在程序运行期将调用方法的符号引用转换为直接引用,由于这种引用转换过程具备动态性,因此也就被称之为动态链接。体现了多态 (invokevirtual | invokeinterface)

非虚方法: 如果方法在编译器就确定了具体的调用版本,这个版本在运行时是不可变的。这样的方法称为非虚方法 (静态方法、私有方法、final方法、实例构造器(实例已经确定,this()表示本类的构造器)、父类方法(super调用)都是非虚方法)

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

java 复制代码

//普通调用指令:
1.invokestatic:调用静态方法,解析阶段确定唯一方法版本；
2.invokespecial:调用<init>方法、私有及父类方法,解析阶段确定唯一方法版本；
3.invokevirtual:调用所有虚方法；
4.invokeinterface:调用接口方法；
//动态调用指令(Java7新增):
5.invokedynamic:动态解析出需要调用的方法,然后执行 .

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

其中invokevirtual(final修饰的除外,JVM会把final方法调用也归为invokevirtual指令,但要注意final方法调用不是虚方法)、invokeinterface指令调用的方法称称为虚方法。

关于invokedynamic指令

JVM字节码指令集一直比较稳定,一直到java7才增加了一个invokedynamic指令,这是Java为了实现【动态类型语言】支持而做的一种改进

动态类型语言和静态类型语言两者的却别就在于对类型的检查是在编译期还是在运行期,满足前者就是静态类型语言,反之则是动态类型语言。

Java是静态类型语言(尽管lambda表达式为其增加了动态特性)，js、python是动态类型语言

方法返回地址

存放调用该方法的pc寄存器的值。一个方法的结束，有两种方式：

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

无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，调用者的pc计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是要通过异常表来确定，栈帧中一般不会保存这部分信息。

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

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

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

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

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

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

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

一些附加信息

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

问题小结与扩展

①. 栈溢出的情况?

栈溢出:StackOverflowError

栈中是不存在GC的,存在OOM和StackOverflowError

举个简单的例子:在main方法中调用main方法,就会不断压栈执行,直到栈溢出;

栈的大小可以是固定大小的,也可以是动态变化(动态扩展)的

如果是固定的,那么会抛出StackOverflowError

如果是动态扩展的,那么会抛出OOM异常(java.lang.OutOfMemoryError)

②. 调整栈大小,就能保证不出现溢出吗?

不能。因为调整栈大小,只会减少出现溢出的可能,栈大小不是可以无限扩大的,所以不能保证不出现溢出

③. 分配的栈内存越大越好吗?

不是,因为增加栈大小,会造成每个线程的栈都变的很大,使得一定的栈空间下,能创建的线程数量会变小

④. 垃圾回收是否会涉及到虚拟机栈?

不会;垃圾回收只会涉及到方法区和堆中,方法区和堆也会存在溢出的可能

程序计数器,只记录运行下一行的地址,不存在溢出和垃圾回收

虚拟机栈和本地方法栈,都是只涉及压栈和出栈,可能存在栈溢出,不存在垃圾回收

⑤. 方法中定义的局部变量是否线程安全?

如果对象是在内部产生，并在内部消亡，没有返回到外部，那么它就是线程安全的，反之则是线程不安全的。

java 复制代码

/**
方法中定义的局部变量是否线程安全?   具体问题具体分析
 */
public class LocalVariableThreadSafe {
    //s1的声明方式是线程安全的,因为线程私有,在线程内创建的s1 ,不会被其它线程调用
    public static void method1() {
        //StringBuilder:线程不安全
        StringBuilder s1 = new StringBuilder();
        s1.append("a");
        s1.append("b");
        //...
    }
    
    //stringBuilder的操作过程:是线程不安全的,
    // 因为stringBuilder是外面传进来的,有可能被多个线程调用
    public static void method2(StringBuilder stringBuilder) {
        stringBuilder.append("a");
        stringBuilder.append("b");
        //...
    }

    //stringBuilder的操作:是线程不安全的；因为返回了一个stringBuilder,
    // stringBuilder有可能被其他线程共享
    public static StringBuilder method3() {
        StringBuilder stringBuilder = new StringBuilder();
        stringBuilder.append("a");
        stringBuilder.append("b");
        return stringBuilder;
    }

    //stringBuilder的操作:是线程安全的；因为返回了一个stringBuilder.toString()相当于new了一个String,
    // 所以stringBuilder没有被其他线程共享的可能
    public static String method4() {
        StringBuilder stringBuilder = new StringBuilder();
        stringBuilder.append("a");
        stringBuilder.append("b");
        return stringBuilder.toString();

        /**
         * 结论:如果局部变量在内部产生并在内部消亡的,那就是线程安全的
         */
    }
}

堆

概述

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

堆可以在物理上是不连续的内存空间,但在逻辑上是连续的

Java堆区在JVM启动的时候即被创建,其空间大小也是确定的。是JVM管理最大的一块内存空间

所有的线程共享Java堆,在这里还可以划分线程私有的缓冲区(Thread Local Allocation Buffer,TLAB)

在方法结束后,堆中的对象不会马上被移除,仅仅在垃圾收集的时候才有被移除 (注意:一个进程就是一个JVM实例,一个进程中包含多个线程)

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

堆内存细分

Java 8及之后堆内存逻辑上分为三部分：新生区+养老区+元空间

Young Generation Space 新生区 Young/New 又被划分为Eden区和Survivor区
Tenure generation space 养老区 Old/Tenure
Meta Space 元空间 Meta

设置堆内存大小与OOM

Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项"-Xmx"和"-Xms"来进行设置。

"-Xms"用于表示堆区的起始内存，等价于-XX:InitialHeapSize
"-Xmx"则用于表示堆区的最大内存，等价于-XX:MaxHeapSize

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

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

默认情况下

初始内存大小：物理电脑内存大小 / 64
最大内存大小：物理电脑内存大小 / 4

年轻代与老年代

存储在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

当然开发人员可以通过选项"-xx:SurvivorRatio"调整这个空间比例。比如-xx:SurvivorRatio=8

几乎所有的Java对象都是在Eden区被new出来的。绝大部分的Java对象的销毁都在新生代进行了。

可以使用选项"-Xmn"设置新生代最大内存大小，这个参数一般使用默认值就可以了。

对象分配内存过程

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

（1）new的对象先放伊甸园区。此区有大小限制。

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

（3）然后将伊甸园中的剩余对象移动到幸存者0区。

（4）如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。

（5）如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。

（6）啥时候能去养老区呢？可以设置次数。默认是15次。

可以设置参数：进行设置-Xx:MaxTenuringThreshold= N

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

(8) 若养老区执行了Major GC之后，发现依然无法进行对象的保存，就会产生OOM异常。

Minor GC，MajorGC、Full GC

JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代，垃圾回收会出现STW现象（stop the world）暂停其他用户线程,等垃圾回收结束,用户线程才能恢复。

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

部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：
- 新生代收集（Minor GC / Young GC）：只是新生代的垃圾收集
- 老年代收集（Major GC / Old GC）：只是老年代的圾收集，major gc 的速度一般比Minor gc 慢10倍以上,STW时间更长。
- 目前，只有CMS GC会有单独收集老年代的行为。
- 注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。
混合收集（MixedGC）：收集整个新生代以及部分老年代的垃圾收集。
- 目前，只有G1 GC会有这种行为
整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集。

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

当年轻代空间不足时，就会触发MinorGC，这里的年轻代满指的是Eden区满，Survivor满不会引发GC。（每次Minor GC会清理年轻代的内存。）
因为Java对象大多都具备朝生夕灭的特性.，所以Minor GC非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。
Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行

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

指发生在老年代的GC，对象从老年代消失时，我们说 "Major GC" 或 "Full GC" 发生了
出现了Major Gc，经常会伴随至少一次的Minor GC（但非绝对的，在Paralle1 Scavenge收集器的收集策略里就有直接进行MajorGC的策略选择过程）
- 也就是在老年代空间不足时，会先尝试触发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区、survivor space0（From Space）区向survivor space1（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小

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

内存分配策略

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

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

针对不同年龄阶段的对象分配原则

①. 优先分配到Eden

②. 大对象直接分配到老年代区域(尽量避免程序中出现过多的大对象)

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

④. 动态对象年龄判断 (如果Survivor 区中相同年龄的所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄对象可以直接进入老年代,无须等到MaxTenurningThreshold中要求的年龄)

⑤. 空间分配担保 -XX:HandlePromotionFailure (JDK6之后,只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行Minor GC,否则将进行Full GC)

TLAB（Thread Local Allocation Buffer）

从内存模型而不是垃圾收集的角度,对Eden区域继续进行划分,JVM为每个线程分配了一个私有缓存区域,它包含在Eden空间内

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

默认情况下,TLAB空间的内存非常小,仅占有整个Eden空间的1%,当然可通过选项"-XX:TLABWasteTargePercent"设置TLAB空间所占Eden空间的百分比大小

一旦对象在TLAB空间分配内存失败时,JVM就会尝试着通过使用加锁机制确保数据操作的原子性,从而直接在Eden空间中分配内存

ThreadLocal 就是存储在TLAB中的。

堆空间参数总结

①. -XX:+PrintFlagsInitial : 查看所有的参数的默认初始值

②. -XX:+PrintFlagsFinal : 查看所有的参数的最终值(可能会存在修改(:表示修改了),不再是初始值)

③. 具体查看某个参数的指令: (jps:查看当前运行中的进程 jinfo -flag SurvivorRatio 进程id)

④. -Xms:初始堆空间内存 (默认为物理内存的1/64)

⑤. -Xmx:最大堆空间内存(默认为物理内存的1/4)

⑥. -Xmn:设置新生代的大小。(初始值及最大值)

⑦. -XX:NewRatio:配置新生代与老年代在堆结构的占比 (默认:-XX:NewRatio=2,表示新生代占1,老年代占2,新生代占整个堆的1/3 可以修改-XX:NewRatio=4,表示新生代占1,老年代占4,新生代占整个堆的1/5) ⑧. -XX:SurvivorRatio:设置新生代中Eden和S0/S1空间的比例 (Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1)

⑨. -XX:MaxTenuringThreshold:设置新生代垃圾的最大年龄

⑩. -XX:+PrintGCDetails:输出详细的GC处理日志 (如下这两种方式是简单的打印打印gc简要信息:① -XX:+PrintGC ② -verbose:gc)

⑩①. -XX:HandlePromotionFailure:是否设置空间分配担保 (JDK6之后,只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC,否则将进行Full GC)

堆是分配对象的唯一选择么？

在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是如果经过逃逸分析（Escape Analysis）后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配.。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。

逃逸分析

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

当一个对象在方法中被定义后,对象只在方法内部使用(这里关注的是这个对象的实体),则认为没有发生逃逸。
当一个对象在方法中被定义后,它被外部方法所引用,则认为发生逃逸。例如作为调用参数传递到其他地方中

代码演示

java 复制代码

//(1). 没有发生逃逸的对象,则可以分配到栈上,随着方法执行的结束,栈空间就被移除
public void my_method() {
    V v = new V();
    // use v
    // ....
    v = null;
}
//(2). 下面代码中的 StringBuffer sb 发生了逃逸
public static StringBuffer createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb;
}
//如果想要StringBuffer sb不发生逃逸,可以这样写
public static String createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb.toString();
}

复制代码

在JDK1.7版本之后,HotSpot中默认就已经开启了逃逸分析。

所以在开发中能使用局部变量的,就不要全局变量。

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

（1）栈上分配:将堆分配转化为栈分配。如果一个对象在子程序中被分配,要使指向该对象的指针永远不会发生逃逸,对象可能是栈上分配的候选,而不是堆上分配

（2）同步省略:如果一个对象被发现只有一个线程被访问到,那么对于这个对象的操作可以不考虑同步。

（3）分离对象或标量替换:有的对象可能不需要作为一个连续的内存结构存在也可以被访问到,那么对象的部分(或全部)可以不存储在内存,而是存储在CPU寄存器中

栈上分配

JIT编译器在编译期间根据逃逸分析的结果,发现如果一个对象并没有逃逸出方法的话,就可能被优化成栈上分配

代码举例：

java 复制代码

public class test1 {
    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 -XX:-DoEscapeAnalysis -Xlog:gc*

输出结果

开启逃逸分析（我的JDK版本是11，默认是开启逃逸分析的）

-Xmx256m -Xms256m -Xlog:gc*

同步替换（锁消除）

①. 从JIT角度看相当于无视它了,这个锁对象没有被共享给其他线程

②. 例如下面的代码,根本起不到锁的作用代码中对hellis这个对象加锁(每个线程都有一个hellis对象的锁),但是hellis对象的生命周期只在f( )方法中,并不会被其他线程所访问到,所以在JIT编译阶段就会被优化掉,优化成:

java 复制代码

public void f() {
    Object hellis = new Object();
    synchronized(hellis) {
        System.out.println(hellis);
    }
}
// JIT会将它变成这样
public void f() {
  	Object hellis = new Object();
	System.out.println(hellis);
}

注意:字节码文件中并没有进行优化,可以看到加锁和释放锁的操作依然存在,同步省略操作是在解释运行时发生的

分离对象或标量替换

①. 标量(scalar)是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量

②. 相对的,那些还可以分解的数据叫做聚合量(Aggregate),Java中的对象就是聚合量,因为他可以分解成其他聚合量和标量

③. 在JIT阶段,如果经过逃逸分析,发现一个对象不会被外界访问的话,那么经过JIT优化,就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换

代码演示

java 复制代码

public static void main(String args[]) {
    alloc();
}
class Point {
    private int x;
    private int y;
}
private static void alloc() {
    Point point = new Point(1,2);
    System.out.println("point.x" + point.x + ";point.y" + point.y);
}
//以上代码,经过标量替换后,就会变成
private static void alloc() {
    int x = 1;
    int y = 2;
    System.out.println("point.x = " + x + "; point.y=" + y);
}

方法区

方法区也被称为元空间或永久代。

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

方法区在哪里？

《Java虚拟机规范》中明确说明："尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。"但对于HotSpotJVM而言，方法区还有一个别名叫做Non-Heap（非堆），目的就是要和堆分开。

所以，方法区看作是一块独立于Java堆的内存空间

方法区的基本理解

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域。
方法区在JVM启动的时候被创建，并且它的实际的物理内存空间中和Java堆区一样都可以是不连续的。
方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。
方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误：java.lang.OutOfMemoryError: PermGen space 或者java.lang.OutOfMemoryError: Metaspace
- 加载大量的第三方的jar包；Tomcat部署的工程过多（30~50个）；大量动态的生成反射类
关闭JVM就会释放这个区域的内存。

方法区的内部结构

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

类型信息

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

（1）这个类型的完整有效名称（全名=包名.类名）

（2）这个类型直接父类的完整有效名（对于interface或是java.lang.object，没有父类）

（3）这个类型的修饰符（public，abstract，final的某个子集）

（4）这个类型直接接口的一个有序列表

域（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方法除外）

- 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

non-final的类变量

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

运行时常量池 VS 常量池

方法区，内部包含了运行时常量池
字节码文件，内部包含了常量池
要弄清楚方法区，需要理解清楚Class文件，因为加载类的信息都在方法区。
要弄清楚方法区的运行时常量池，需要理解清楚Class文件中的常量池。

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

为什么需要常量池？

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

常量池内存储的数据类型包括：

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

运行时常量池

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

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

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

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

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

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

java 复制代码

"Exception in thread 'dubbo client x.x connector' java.lang.OutOfMemoryError:PermGen space"

复制代码

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

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

有些人认为方法区（如HotSpot虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如JDK 11时期的ZGC收集器就不支持类卸载）。一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏

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

StringTable为什么要调整位置

jdk7中将StringTable放到了堆空间中。因为永久代的回收效率很低，在full gc的时候才会触发。而full gc是老年代的空间不足、永久代不足时才会触发。

这就导致StringTable回收效率不高。而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。