运行时内存篇-程序员の小站

1. 程序计数器

为了保证程序(在操作系统中理解为进程)能够连续地执行下去，CPU必须具有某些手段来确定下一条指令的地址。而程序计数器正是起到这种作用，所以通常又称为指令计数器
在程序开始执行前，必须将它的起始地址，即程序的一条指令所在的内存单元地址送入PC，因此程序计数器（PC）的内容即是从内存提取的第一条指令的地址。当执行指令时，CPU将自动修改PC的内容，即每执行一条指令PC增加一个量，这个量等于指令所含的字节数，以便使其保持的总是将要执行的下一条指令的地址。
由于大多数指令都是按顺序来执行的，所以修改的过程通常只是简单的对PC加1。
当程序转移时,转移指令执行的最终结果就是要改变PC的值，此PC值就是转去的地址，以此实现转移。有些机器中也称PC为指令指针IP（Instruction Pointer）

[!SUCCESS] 小结

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

PC寄存器用来存储指向下一条指令的地址，也即将要执行的指令代码。执行引擎的字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。

JVM中的程序计数寄存器（Program Counter Register）中， Register 的命名源于CPU的寄存器，寄存器存储指令相关的现场信息。 CPU只有把数据装载到寄存器才能够运行。

这里，并非是广义上所指的物理寄存器，或许将其翻译为PC计数器（或指令计数器）会更加贴切(也称为程序钩子) ，并且也不容易引起一些不必要的误会。JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟。

它是一块很小的内存空间，几乎可以忽略不计。也是运行速度最快的存储区域。不会随着程序的运行需要更大的空间
在JVM规范中，每个线程都有它自己的程序计数器，是线程私有的。声明周期与线程的声明周期保持一致。
他是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

PC寄存器之所以设置为线程私有是因为所谓的多线程在一个特定的时间段内只会执行其中某一个线程的方法，CPU会不停的做任务切换。这样必然导致经常中断或回复，如何保证分毫不差呢？为了能够准确的记录各个线程正在执行的当前字节码指令地址，最好的办法自然是为每一个线程都分配一个PC寄存器，这样一来各个线程之间便可以进行独立计算，从而不会出现相互干扰的情况。

2. 虚拟机栈

2.1 概述

Java虚拟机栈(Java Virtual Machine Stack)早期也叫Java栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应着一次次的Java方法调用。他是线程私有的，声明周期也和线程的声明周期一致。栈是一种快速有效的分配存储方式，访问的速度仅次于程序计数器。

Java虚拟机规范允许Java栈的大小是动态的或者是固定不变的。如果采用固定大小的Java虚拟机栈，那每一个线程的Java虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过Java虚拟机栈允许的最大容量，Java虚拟机将会抛出一个 StackOverflowError 异常；如果Java虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那Java虚拟机将会抛出—个 OutOfMemoryError 异常。

栈内存的大小一般默认为512k-1024k(取决于操作系统)。栈的大小直接决定了函数调用的最大可达深度。在JDK5.0之前默认栈的大小是256k,之后的默认栈大小是1024k。栈内存的大小可以通过参数-Xss size (即：-XX:ThreadStackSize)来进行调节：

2.2 栈的单位:栈帧(Stack Frame)

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

在一个线程上正在执行的每个方法都各自对应一个栈帧(Stack Frame)。栈帧是一个内存区块，是一个数据集，维持着方法执行过程中的各个数据的信息。

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

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

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

JVM直接对Java栈的操作遵循着先进后出、后进先出的原则。不同线程中所包含的栈帧是不允许存在相互引用的，既不可能在一个栈帧中引用另外一个线程的栈帧。如果当前方法调用了其他方法，方法返回之际，当前栈帧会穿回此方法的执行结果给前一个栈帧，接着虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧。Java方法有两种返回函数的方式，一种是正常的函数返回，使用return指令；另外一种是抛出异常。不管使用哪种方式，都会导致栈帧被弹出。

2.3 栈帧内部结构

每个栈帧中存储着局部变量表、操作数栈、动态链接、方法返回地址和一些附加信息

2.3.1 局部变量表(local variables)

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

可以看到，在Class文件的局部变量表中，显示了每个局部变量的作用域范围、所在的槽位的索引(index列)、变量名(name列)和数据类型(J表示long型)

关于Slot的理解

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

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

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);
        }
        //此时的b就会复用a的槽位
        int b = 0;
    }
}

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

参数表分配完毕之后，再根据方法体内定义的变量的顺序和作用域分配
类变量表有两次初始化的机会，第一次是在“准备阶段”，执行系统初始化，对类变量设置零值，另一次则是在“初始化”阶段，赋予程序员在代码中定义的初始值。
和类变量初始化不同的是，局部变量表不存在系统初始化的过程，这意味着一旦定义了局部变量则必须人为的初始化，否则无法使用

与GC Roots的关系
局部变量表中的变量也是重要的蓝记回收根节点。只要被局部变量表中直接或间接引用的对象都不会被回收。

2.3.2 操作数栈(Operand Stack)

我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。每一个独立的栈帧中除了包含局部变量表以外，还包含一个后进先出（Last-In-First-Out）的操作数栈，也可以称之为表达式栈（Expression Stack）。操作数栈就是JVM执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的。每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的Code属性中，为max_stack的值。栈中的任何一个元素都是可以任意的Java数据类型。32bit的类型占用一个栈单位深度，64bit的类型占用两个栈单位深度。操作数栈在方法执行过程中，根据字节码指令，并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈（push）和出栈（pop）操作，往栈中写入数据或提取数据来完成一次数据访问。某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈。比如：执行复制、交换、求和等操作。如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。

代码例子

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

字节码指令信息

public void testAddOperation();
     Code:
     0: bipush        15
     2: istore_1
     3: bipush        8
     5: istore_2
     6: iload_1
     7: iload_2
     8: iadd
     9: istore_3
     10: return

操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间。操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译器期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。

字节码分析:

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

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

2.3.3 动态链接(或指向运行时常量池的方法引用)

每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接（Dynamic Linking）。比如：invokedynamic指令。在Java源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Reference）保存在class文件的常量池里。比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用。

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

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

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

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

随着高级语言的横空出世，类似于Java一样的基于面向对象的编程语言如今越来越多，尽管这类编程语言在语法风格上存在一定的差别，但是它们彼此之间始终保持着一个共性，那就是都支持封装、继承和多态等面向对象特性，既然这一类的编程语言具备多态特性，那么自然也就具备早期绑定和晚期绑定两种绑定方式。
Java中任何一个普通的方法其实都具备虚函数的特征，它们相当于C++语言中的虚函数（C++中则需要使用关键字virtual来显式定义）。如果在Java程序中不希望某个方法拥有虚函数的特征时，则可以使用关键字final来标记这个方法。

如果方法在编译期就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法。静态方法、私有方法、final方法、实例构造器、父类方法都是非虚方法。其他的方法称为虚方法。

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

普通调用指令
- invokestatic：调用静态方法，解析阶段确定唯一方法版本
- invokespecial：调用< init>方法、私有及父类方法，解析阶段确定唯一方法版本
- invokevirtual：调用所有虚方法
- invokeinterface：调用接口方法
动态调用指令
- invokedynamic：动态解析出需要调用的方法，然后执行
  前四条指令固化在虚拟机内部，方法的调用执行不可人为干预，而invokedynamic指令则支持由用户确定方法版本。其中invokestatic指令和invokespecial指令调用的方法称为非虚方法，其余的（final修饰的除外）称为虚方法。

2.3.4 方法返回地址

一个方法的结束有两种方式，一种是正常执行完成另外一种是出现未处理的异常，非正常的退出。无论通过哪种方式退出，在方法推出后都返回到该方法被调用的位置。方法正常退出时，调用者的pc计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是要通过异常表来确定，栈帧中一般不会保存着部分信息。

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

执行引擎遇到任意一个方法返回的字节码指令（return），会有返回值传递给上层的方法调用者，简称正常完成出口；
- 一个方法在正常调用完成之后究竟需要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定。
- 在字节码指令中，返回指令包含ireturn（当返回值是boolean、byte、char、short和int类型时使用）、lreturn、freturn、dreturn以及areturn，另外还有一个return指令供声明为void的方法、实例初始化方法、类和接口的初始化方法使用。
在方法执行的过程中遇到了异常（Exception），并且这个异常没有在方法内进行处理，也就是只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出。简称异常完成出口。

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

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

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

2.3.5 一些附加信息

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

2.4 问题小结与拓展

栈溢出的情况?

栈溢出:StackOverflowError;
举个简单的例子:在main方法中调用main方法,就会不断压栈执行,直到栈溢出;
栈的大小可以是固定大小的,也可以是动态变化（动态扩展）的。
如果是固定的,可以通过-Xss设置栈的大小;
如果是动态变化的,当栈大小到达了整个内存空间不足了,就是抛出OutOfMemory异常(java.lang.OutOfMemoryError)

调整栈大小,就能保证不出现溢出吗?
不能。因为调整栈大小,只会减少出现溢出的可能,栈大小不是可以无限扩大的,所以不能保证不出现溢出
分配的栈内存越大越好吗?
不是,因为增加栈大小，会造成每个线程的栈都变的很大,使得一定的栈空间下,能创建的线程数量会变小
垃圾回收是否会设计到虚拟机栈?
不会;垃圾回收只会涉及到方法区和堆中,方法区和堆也会存在溢出的可能;程序计数器,只记录运行下一行的地址,不存在溢出和垃圾回收;虚拟机栈和本地方法栈,都是只涉及压栈和出栈,可能存在栈溢出,不存在垃圾回收。
方法中定义的局部变量是否线程安全?
具体问题具体分析,见分析代码:

/**方法中定义的局部变量是否线程安全?   具体问题具体分析
 * @author shkstart
 * @create 15:53
 */
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();

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

3. 本地方法接口与本地方法栈

一个Native Method就是一个Java调用非Java代码的接口。一个Native Method是这样一个Java方法：该方法的实现由非Java语言实现，比如C。这个特征并非Java所特有，很多其它的编程语言都有这一机制，比如在C++中，你可以用extern "C"告知C++编译器去调用一个C的函数。在定义一个native method时，并不提供实现体（有些像定义一个Java interface），因为其实现体是由非java语言在外面实现的。本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合 C/C++程序。

Java使用起来非常方便，然而有些层次的任务用Java实现起来不容易，或者我们对程序的效率很在意时，问题就来了。

与Java环境外交互
有时Java应用需要与Java外面的环境交互，这是本地方法存在的主要原因。你可以想想Java需要与一些底层系统，如操作系统或某些硬件交换信息时的情况。本地方法正是这样一种交流机制：它为我们提供了一个非常简洁的接口，而且我们无需去了解Java应用之外的繁琐的细节。
与操作系统交互
JVM支持着Java语言本身和运行时库，它是Java程序赖以生存的平台，它由一个解释器（解释字节码）和一些连接到本地代码的库组成。然而不管怎样，它毕竟不是一个完整的系统，它经常依赖于一些底层系统的支持。这些底层系统常常是强大的操作系统。通过使用本地方法，我们得以用Java实现了jre的与底层系统的交互，甚至JVM的一些部分就是用C写的。还有，如果我们要使用一些Java语言本身没有提供封装的操作系统的特性时，我们也需要使用本地方法。
Sun’s Java
Sun的解释器是用C实现的，这使得它能像一些普通的C一样与外部交互。jre大部分是用Java实现的，它也通过一些本地方法与外界交互。例如：类java.lang.Thread 的 setPriority()方法是用Java实现的，但是它实现调用的是该类里的本地方法setPriority0()。这个本地方法是用C实现的，并被植入JVM内部，在Windows 95的平台上，这个本地方法最终将调用Win32 SetPriority()API。这是一个本地方法的具体实现由JVM直接提供，更多的情况是本地方法由外部的动态链接库（external dynamic link library）提供，然后被JVM调用。

目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用Web Service等等。

Java虚拟机栈用于管理Java方法的调用，而本地方法栈用于管理本地方法的调用。
本地方法栈，也是线程私有的。
允许被实现成固定或者是可动态扩展的内存大小。（在内存溢出方面是相同的）
- 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个 StackOverflowError 异常。
- 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么Java虚拟机将会抛出一个 OutOfMemoryError 异常。
本地方法是使用C语言实现的。
它的具体做法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。
当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限
- 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区。
- 它甚至可以直接使用本地处理器中的寄存器
- 直接从本地内存的堆中分配任意数量的内存。
并不是所有的JVM都支持本地方法。因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持native方法，也可以无需实现本地方法栈。

4. 堆

4.1 核心概念

一个JVM实例只存在一个堆内存，堆事Java内存管理的核心区域。Java堆区在JVM启动的时候即被创建，其空间大小也就确定了。是JVM管理的最大的一块内存空间。堆是执行垃圾回收的重点区域。

《Java虚拟机规范》中对Java堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated )数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。从实际使用角度看,“几乎”所有的对象实例都会在这里分配内存。

 public class SimpleHeap {
    private int id;

    public SimpleHeap(int id) {
        this.id = id;
    }

    public void show() {
        System.out.println("My ID is " + id);
    }

    public static void main(String[] args) {
        SimpleHeap sl = new SimpleHeap(1);
        SimpleHeap s2 = new SimpleHeap(2);
    }
}

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

4.2 堆的内部结构

现代垃圾收集器大部分都基于分代收集理论设计，堆空间细分为：

Java 7及之前堆内存逻辑上分为三部分：新生区+养老区+永久区

Young Generation Space 新生区 Young/New
- 又被划分为Eden区和Survivor区
Tenure generation space 养老区 Old/Tenure
Permanent Space 永久区 Perm

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

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

存在JVM中的Java对象可以被划分为两类：一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常的迅速；另外一类是对象的生命周期非常的长，在某些极端的情况下还能够与JVM的生命周期保持一致。Java堆区进一步细分的话还可以划分为年轻代(YoungGen)和老年代(OldGen)。其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间(有时也叫做from区、to区)

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

4.3 如何设置堆内存大小

Java堆区用于存储Java对象实例，那么堆的大小在JVM启动的时候就已经设定好了，我们可以通过选项-Xmx和-Xms来设置。-Xms用于表示堆区的起始内存，等价于-XX:InitialHeapSize；-Xmx则用于表示堆区的最大内存，等价于-XX:MaxHeapSize。

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

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

heap默认最大值计算方式：如果物理内存少于192M,那么heap最大值为物理内存的一半。如果物理内存大于等于1G，那么heap的最大值为物理内存的1/4。heap默认最小值计算方式：最少不得少于8M，如果物理内存大于等于1G，那么默认值为物理内存的1/64，即1024/64=16M。最小堆内存在jvm启动的时候就会被初始化。

4.3.1 如何设置新生代与老年代比例

配置新生代与老年代在堆结构的占比。默认-XX:NewRatio=2表示新生代占1，老年代占2，新生代占整个堆的 1/3。可以修改-XX:NewRatio=4表示新生代占1，老年代占4，新生代占整个堆的 1/5。可以使用选项-Xmn设置新生代最大内存大小，这个参数一般使用默认值就可以。

4.3.2 如何设置Eden、幸存者区比例

在HotSpot中，Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1，当然开发人员可以通过选项“-XX:SurvivorRatio”调整这个空间比例。比如-XX:SurvivorRatio=8

4.3.3 参数设置小结

-Xms-Xmx 堆空间大小的设置,-Xms初始内存(默认为物理内存的1/64)；-Xmx最大内存(默认为物理内存的1/4)。例如:-Xms10m -Xmx10m
-Xmn设置新生代的大小(初始值及最大值)。通常默认即可
-XX:NewRatio配置新生代与老年代在堆结构的占比。赋的值即为老年代的占比，剩下的1给新生代。默认-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3。-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5
-XX:SurvivorRatioHotSpot中，Eden空间和另外两个Survivor空间缺省所占的比例是8:1,开发人员可以通过选项“-XX:SurvivorRatio”调整这个空间比例。比如-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold设置新生代垃圾的最大年龄。超过此值，仍未被回收的话，则进入老年代。默认值为15。-XX:MaxTenuringThreshold=0表示年轻代对象不经过Survivor区，直接进入老年代。对于老年代比较多的应用，可以提高效率。如果将此值设置为一个较大的值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象在年轻代的存活时间，增加在年轻代即被回收的概率
-XX:+PrintGCDetails开启详细的GC处理日志
-XX:HandlePromotionFailure在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。如果大于则此次Minor GC是安全的；如果小于，则虚拟机会查看-XX:HandlePromotionFailure设置值是否允许担保失败。如果-XX:HandlePromotionFailure=true那么会继续检查老年代对打可用连续空间是否大于历次晋升到老年代的平均大小，如果大于则尝试进行一个Minor GC，但这次Minor GC是有风险的；如果小于或者-XX:HandlePromotionFailure=false,则改为进行一次Full GC。
-XX:+PrintFlagsFinal查看所有的参数的最终值(可能会存在修改，不再是初始值)。具体查看某个参数的chillingjp是：查看当前运行中的进程；jinfo -flag SurvivorRation 进程id

4.4 对象分配金句

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

针对幸存者s0,s1区的总结是复制之后有交换，谁空谁是to;关于垃圾回收:频繁在新生区收集，很少在养老去收集，几乎不再永久区/元空间收集

4.4.1 过程剖析

new的对象先放在伊甸园区。此区有大小限制。当伊甸园的空间填满时，程序有需要创建对象，JVM的垃圾回收器将对伊甸园区进行回收，将伊甸园区中的不再被其他对象所引用的对象进行销毁。在加载新的对象放到伊甸园区。然后将伊甸园中的剩余对象移动到幸存者0区。如果再次触发垃圾回收，此时上次幸存下来的放到幸存0区，如果没有回收就会放到幸存者1区。如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。可以设置参数XX:MaxTenuringThreshold=<N> 设置对象晋升老年代的年龄阈值。在养老区相对有限。当养老去内存不足时再次出发GC: Major GC 进行养老去的内存清理。若养老区执行了Major GC之后依然无法进行对象的保存就会产生OOM异常

java.lang.OutOfMemoryError: Java heap space

内存分配策略(或对象提升规则):如果对象在Eden出生并经过第一次Major GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将对象的年龄设置为1.对象在Survivor区中每熬过一次Minor GC,年龄就增加1岁，当她的年龄增加到一定程度(默认为15岁，其实每个JVM 每个GC都有所不同)时，就会被晋升到老年代中。

针对不同年龄段对象分配原则如下：优先分配Eden,大对象直接分配到老年代，尽量避免程序中出现过来的大对象。长期存活的对象分配到老年代。

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

代码举例
-Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails

/** 测试：大对象直接进入老年代
 * -Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails
 * @author shkstart  shkstart@126.com
 * @create 2021  21:48
 */
public class YoungOldAreaTest {
    public static void main(String[] args) {
        byte[] buffer = new byte[1024 * 1024 * 20];//20m

    }
}

4.5 解释 MinorGC MajorGC FullGC

JVM在进行GC时，并非每次都对上面三个内存(新生代、老年代；方法区)区域一起回收的，大部分时候回收的都是指新生代。针对HotSpot VM的实现，它里面的GC按照回收区域又分为两大种类:一种是部分收集(Partial GC);一种是整堆收集(Full GC)

部分收集不是完整收集整个Java堆的垃圾收集。其中又分为新生代收集(Minor GC / Young GC)、老年代收集(Major GC / Old GC)和混合收集(Mixed GC)。新生代收集只是新生代(Eden\S0,S1)的垃圾收集，老年代收集只是老年代的垃圾收集。目前只有CMS GC会有单独收集老年代的行为。注意：很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。混合收集收集整个新生代以及部分老年代的垃圾收集，目前只有只有G1 GC会有这种行为。

整堆收集是收集整个java堆和方法区的垃圾收集。

4.5.1 年轻代GC(Minor GC)触发机制

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

4.5.2 老年代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了。

4.5.3 Full GC触发机制

触发Full GC执行情况有一下五种:

调用System.gc()时，系统建议执行Full GC，但是不必然执行
老年代空间不足
方法区空间不足
通过Minor GC后进入老年代的平均大小大于老年代的可用内存
由Eden区、survivor、space0(From Space)区向survivor space1(To Space)区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代。且老年代的可用内存小于该对象大小。
full gc是开发或调优中尽量要避免的。这样暂时时间会短一些。

4.6 OOM怎么解决

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

如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots 的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots 相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息，以及GC Roots 引用链的信息，就可以比较准确地定位出泄漏代码的位置。

如果不存在内存泄漏，换句话说就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xmx 与-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

4.7 堆空间分代思想

经研究，不同对象的生命周期不同。70%-99%的对象是临时对象。新生代：有Eden、两块大小相同的Survivor(又称为from/to，s0/s1)构成，to总为空。老年代：存放新生代中经历多次GC仍然存活的对象。
JDK7
JDK8

分代可以更好的优化GC性能。如果没有分代，那所有的对象都在一块，就如同把一个学校的人都关在一个教室。GC的时候要找到哪些对象没用，这样就会对堆的所有区域进行扫描。而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC 的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。

4.8 快速分配策略:TLAB

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

堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据。由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的。为了避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。所以多线程同时分配内存时，使用TLAB(Thread Local Allocation Buffer)可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量。因此我们可以将这种内存分配方式称之为快速分配策略。

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

5. 方法区

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

《Java虚拟机规范》中明确说明: “尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。” 但对于HotSpotJVM而言，方法区还有一个别名叫做Non-Heap(非堆)，目的就是要和堆分开。所以，方法区看作是一块独立于Java 堆的内存空间。

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

本质上，方法区和永久代并不等价。仅是对hotspot而言的。《Java虚拟机规范》对如何实现方法区，不做统一要求。例如：BEA JRockit/ IBM J9中不存在永久代的概念。现在来看,当年使用永久代，不是好的idea。导致Java程序更容易OOM（超过-XX:MaxPermSize上限）

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

元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存。用就打死、元空间二者并不只是名字变了，内部结构也调整了。根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OOM异常。

5.1 方法区常用的参数有哪些

方法区的大小不必是固定的,jvm可以根据应用的需要动态调整。
JDK1.7及以前:

通过-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设置为一个相对较高的值。

在JDK8 及以上版本中，设定MaxPermSize 参数， JVM在启动时并不会报错，但是会提示：
Java HotSpot 64Bit Server VM warning:
ignoring option MaxPermSize=2560m; support was removed in 8.0 。

5.2 方法区都存什么

5.2.1 类型信息

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

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

5.2.2 域(Field)信息

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

5.2.3 方法信息

JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序：方法名称;方法的返回类型;方法参数的数量和类型(按顺序);方法的修饰符(public,private,protected,static,final,synchronized,native,abstract的一个子集);方法的字节码(bytecodes)、操作数栈、局部变量表及大小(abstract和native方法除外)；异常表(abstract和native除外)。每个异常处理的开始位置、结束为止、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

5.2.4 non-final的类变量

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

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

5.2.5 运行时常量池

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

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

6. 直接内存

不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中定义的内存区域。直接内存是在Java堆外的、直接向系统申请的内存区间。来源于NIO，通过存在堆中的DirectByteBuffer操作Native内存。通常，访问直接内存的速度会优于Java堆。即读写性能高。因此出于性能考虑，读写频繁的场合可能会考虑使用直接内存。Java的NIO库允许Java程序使用直接内存，用于数据缓冲区。

直接内存大小可以通过MaxDirectMemorySize设置。如果不指定，默认与堆的最大值-Xmx参数值一致

运行时内存篇