JVM最详细知识点笔记-内存与垃圾回收篇

最新推荐文章于 2022-03-11 22:00:06 发布

Aurora & Code Is Law

最新推荐文章于 2022-03-11 22:00:06 发布

阅读量464

点赞数 1

分类专栏： java jvm 文章标签： jvm java

本文链接：https://blog.csdn.net/qq_15267283/article/details/121385689

版权

java 同时被 2 个专栏收录

7 篇文章 0 订阅

订阅专栏

jvm

3 篇文章 0 订阅

订阅专栏

内存与垃圾回收

一、JVM与JAVA体系结构

1.1 概述

JAVA虚拟机：

含义:
- Java虚拟机是一台执行Java字节码的虚拟计算机，它拥有独立的运行机制，其运行的Java字节码也未必由Java语言编译而成。
- JVM平台的各种语言可以共享Java虚拟机带来的跨平台性、优秀的垃圾回器，以及可靠的即时编译器。
- Java技术的核心就是Java虚拟机（JVM，Java virtual Machine因为所有的Java程序都运行在Java虚拟机内部。
作用:
- Java虚拟机就是二进制字节码的运行环境，负责装载字节码到其内部，解释/编译为对应平台上的机器指令执行。每一条Java指令，Java虚拟机规范中都有详细定义，如怎么取操作数，怎么处理操作数，处理结果放在哪里。
特点:
- 一次编译，到处运行
- 自动内存管理
- 自动垃圾回收功能

1.2 jvm整体结构

HotSpot结构图

简略图:

详细图:

1.3 java代码执行流程

源文件被java编译器编译成字节码文件
字节码文件在java虚拟机中被执行
1. 类加载器
2. 字节码校验器
3. 解释执行与及时编译并存
操作系统执行指令

1.4 栈的指令集和寄存器的指令集

Java编译器输入的指令流基本上是一种基于栈的指令集架构，另外一种指令集架构则是基于寄存器的指令集架构。

具体来说:这两种架构之间的区别:

基于栈式架构的特点
- 设计和实现更简单，适用于资源受限的系统;
- 避开了寄存器的分配难题:使用零地址指令方式分配。
- 指令流中的指令大部分是零地址指令，其执行过程依赖于操作栈。指令集更小,编译器容易实现。
- 不需要硬件支持，可移植性更好，更好实现跨平台
基于寄存器架构的特点
- 典型的应用是x86的二进制指令集:比如传统的Pc以及Android的Davlik虚拟机。
- 指令集架构则完全依赖硬件，可移植性差
- 性能优秀和执行更高效;
- 花费更少的指令去完成一项操作。
- 在大部分情况下，基于寄存器架构的指令集往往都以一地址指令、二地址指令和三地址指令为主，而基于栈式架构的指令集却是以零地址指令为主。

总结:

**由于跨平台性的设计，Java的指令都是根据栈来设计的。**不同平台cPU架构不同，所以不能设计为基于寄存器的。优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令。

基于栈：跨平台性、指令集小、指令多;执行性能比寄存器差

1.5 jvm生命周期

虚拟机的启动

Java虚拟机的启动是通过引导类加载器(bootstrap class loader)创建一个初始类(initial class)来完成的，这个类是由虚拟机的具体头现指疋的。

虚拟机的执行

一个运行中的Java虚拟机有着一个清晰的任务:执行Java程序。
程序开始执行时他才运行，程序结束时他就停止。
执行一个所谓的Java程序的时候，真真正正在执行的是一个叫做Java虚拟机的进程。

虚拟机的退出

程序正常执行结束
程序在执行过程中遇到了异常或错误而异常终止由于操作系统出现错误而导致Java虚拟机进程终止
某线程调用Runtime类或system类的exit方法，或 Runtime类的halt方法，并且Java安全管理器也允许这次exit或halt操作。

二、类加载子系统

2.1 类加载子系统的几个阶段

2.1.1 Loading阶段

加载:

通过一个类的全限定名获取定义此类的二进制字节流
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的java.lang.class对象，作为方法区这个类的各种数据的访问入口

2.1.2 Linking阶段

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6Tf0ngr6-1637148184497)(jvm-上篇-内存与垃圾回收.assets/image-20211101201749364.png)]

2.1.3 Initialization阶段

初始化:

初始化阶段就是执行类构造器方法()的过程。
此方法不需定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
构造器方法中指令按语句在源文件中出现的顺序执行。
()不同于类的构造器。(关联:构造器是虚拟机视角下的 ( ))·若该类具有父类，JVM会保证子类的()执行前，父类的()已经执行完毕。
虚拟机必须保证一个类的 ()方法在多线程下被同步加锁。

2.2 类加载器的分类

2.2.1 介绍

在Loading阶段使用了不同的类加载器来加载字节码文件

JVM支持两种类型的类加载器，分别为引导类加载器(BootstrapclassLoader）和自定义类加载器(User-Defined ClassLoader)。

从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类classLoader的类加载器都划分为自定义类加载器。

无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示:

下面是一段关于类加载器的测试:

说明了

我们平时自己写的类默认会被SystemClassLoader系统类加载器所加载
引导类加载器输出null是因为它是由c语言写的
String被输出的是null说明他是引导类加载器加载的 => 系统的核心类是由引导类加载器加载的

public class ClassLoaderTest {

    public static void main(String[] args) {
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);  
        //jdk.internal.loader.ClassLoaders$AppClassLoader@3fee733d

        ClassLoader extentClassLoader = systemClassLoader.getParent();
        System.out.println(extentClassLoader);
        //jdk.internal.loader.ClassLoaders$PlatformClassLoader@10f87f48

        ClassLoader bootstrapClassLoader = extentClassLoader.getParent();
        System.out.println(bootstrapClassLoader);
        //null

        ClassLoader curClassLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(curClassLoader);
        //jdk.internal.loader.ClassLoaders$AppClassLoader@3fee733d
        
        
        ClassLoader stringClassLoader = String.class.getClassLoader();
        System.out.println(stringClassLoader);
        //null
    }
}

2.2.2 类加载器

虚拟机自带的加载器

启动类加载器（引导类加载器，Bootstrap classLoader)
- 这个类加载使用C/C++语言实现的，嵌套在JVM内部。
- 它用来加载Java的核心库（JAVA_ HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
- 并不继承自java.lang.classLoader，没有父加载器。
- 加载扩展类和应用程序类加载器，并指定为他们的父类加载器。
- 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax
扩展类加载器（Extension classLoader)
- **Java语言编写，**由sun.misc.Launcher$ExtClassLoader实现。
- 派生于classLoader类
- 父类加载器为启动类加载器
- 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。
应用程序类加载器（系统类加载器，AppclassLoader)
- java语言编写，由sun.misc.Launcher$AppclassLoader实现
- 派生于classLoader类
- 父类加载器为扩展类加载器
- 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
- 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
- 通过classLoader#getsystemclassLoader ()方法可以获取到该类加载器

2.2.3 自定义类加载器

用户自定义类加载器实现步骤:

开发人员可以通过继承抽象类java.lang.classLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
在JDK1.2之前，在自定义类加载器时，总会去继承classLoader类并重写loadclass ()方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadclass ()方法，而是建议把自定义的类加载逻辑写在findclass ()方法中
在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findclass ()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

ClassLoader

ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader (不包括启动类加载器）

常用方法:

获取方法:

2.3 双亲委派机制

介绍：

Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式。

工作原理：

如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行;
如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归,请求最终将到达顶层的启动类加载器;
如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。

优势：

避免类的重复加载
保护程序安全，防止核心A斑被随意篡改
- 自定义类:java. lang.String
- 自定义类: java . lang.shkstart

沙箱安全机制:

我们自定义string类，但是在加载自定义string类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件(rt.jar包中java\lang\string.class)，报错信息说没有main方法，就是因为加载的是rt.jar包中的string类。这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

2.4 其他

判断对象是否是同一类

相同必须同时满足:

同一包名和类名
同一类加载器

对类加载器的引用

如果一个类是由用户类加载器加载的，那么JVM会将该加载器的一个引用作为类型信息放到方法区中。

类的主动使用和被动使用

主动使用，又分为七种情况:
- 创建类的实例
- 访问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射（比如:class.forName ( “com.king.Test”) )
- 初始化一个类的子类
- Java虚拟机启动时被标明为启动类的类
- JDK 7开始提供的动态语言支持:java . lang .invoke.MethodHandle实例的解析结果REF_getstatic、REF_putstatic、REF_invokestatic句柄对应的类没有初始化，则初始化
除了以上七种情况，其他使用Java类的方式都被看作是对类的被动使用，都不会导致类的初始化。

三、运行时数据区概述及线程

3.1 运行时数据区内存结构

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

不同的JVM对于内存的划分方式和管理机制存在着部分差异。

经典运行时数据区结构：

详细结构：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ULEMV6Um-1637148184510)(https://gitee.com/auroranb/cloudimage/raw/master/img/202111171916321.png)]

其中堆区和方法区是随着JVM创建和销毁，而本地方法区、程序计数器、虚拟机栈与线程一一对应。

进程：Heap、Method Area（永久代/元空间）

线程：JVM Stacks、Navtive Method Stacks、 Program Counter Register

3.2 线程说明

线程是一个程序里的运行单元。JVM允许一个应用有多个线程并行的执行。
在Hotspot JVM里，每个线程都与操作系统的本地线程直接映射。
- 当一个Java线程准备好执行以后，此时一个操作系统的本地线程也同时创建。Java线程执行终止后，本地线程也会回收。
操作系统负责所有线程的安排调度到任何一个可用的CPU上。一旦本地线程初始化成功，它就会调用Java线程中的run ()方法。

3.3 程序计数器(PC寄存器)

3.3.1 简介

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

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

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

3.3.2 使用

程序计数器实际就是存储了程序的运行位置，为了让CPU在切换线程后再次执行线程的指令是恢复到正确的位置

3.3.3 面试问题

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

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

PC寄存器为什么会被设定为线程私有?

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

3.4 虚拟机栈

3.4.1 概述

背景:

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

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

栈和堆:

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

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

栈的基本内容:

java虚拟机栈是什么

Java虚拟机栈（Java virtual Machine stack)，早期也叫Java栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧(stack Frame），对应着一次次的Java方法调用。
生命周期

与线程的生命周期一直
作用

主管Java程序的运行，它保存方法的局部变量、部分结果，并参与方法的调用和返回。
优点
- 快速有效，访问速度仅次于程序计数器
- JVM对虚拟机栈只有进栈和出站的操作，操作简单
- 不存在垃圾回收问题
栈中可能出现的异常

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

通过 -Xss 参数设置

3.4.2 存储单位-栈帧

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

在这个线程上正在执行的每个方法都各自对应一个栈帧(stack Frame) 。

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

栈的运行原理

在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的，这个栈帧被称为当前栈帧(current Frame)，与当前栈帧相对应的方法就是当前方法(currentMethod)，定义这个方法的类就是当前类(current class) 。
执行引擎运行的所有字节码指令只针对当前栈帧进行操作。
如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前帧。
不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈帧之中引用另外一个线程的栈帧。
如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧。
Java方法有两种返回函数的方式，**一种是正常的函数返回，使用return指令;另外一种是抛出异常。**不管使用哪种方试，都会导致栈帧被弹出。

栈帧的内部有如下结构：

局部变量表
操作数栈（表达式栈）
动态链接（指向运行时常量池的引用）
方法返回地址
一些附加信息

3.4.3 局部变量表

简介:

局部变量表也被称之为局部变量数组或本地变量表
定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量,这些数据类型包括各类基本数据类型、对象引用（reference)，以及returnAddress类型。
由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题
局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。

局部变量表是影响栈帧大小的主要因素:

**方法嵌套调用的次数由栈的大小决定。**一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。
**局部变量表中的变量只在当前方法调用中有效。**在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后随着方法栈帧的销毁，局部变量表也会随之销毁。

局部变量表存储了：起始的行号，作用的长度，调用的索引（第几个slot），变量名，类型描述的信息

局部变量表的基本单位(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处，其余的参数按照参数表顺序继续排列。

slot是可以被重复利用的，上图b在作用域消失后，slot空出，这时声明c会直接使用b空出的位置

赋值：

与类变量表中的变量不同，局部变量表的变量需要手动赋值，否则使用时会报错。

类变量表中的变量会经历两次赋值：在类加载子系统的Linking阶段下的preparation阶段默认赋值，在initialization阶段手动赋值（及静态代码块）

补充：

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

3.4.4 操作数栈(表达式栈)

理论知识:

每一个独立的栈帧中除了包含局部变量表以外，还包含一个后进先出(Last-In-First-out）的操作数栈，也可以称之为表达式栈(Expression stack)
操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈(push)/出栈(pop）
- 某些字节码指令将值压入操作数楼，其余的字节码指令将操作数取出栈。使用它们后再纪结果压入栈。
- 比如:执行复制、交换、求和等操作
操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间。
操作数栈就是JVM执行引繁的一个工作区，当一个方法刚开始执行的时候一个新的栈帧也会随之被创建出来,这个方法的操作数栈是空的。
每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定叉好了，保存在方法的code属性中，火max stack的值。
栈中的任何一个元素都是可以任意的Java数据类型。
- 32bit的类型占用一个栈单位深度
- 64bit的类型占用两个栈单位深度
操作数栈并非采用访问索引的方式来进行数据访问的，面是只能通过标准的入栈(push）和出栈(pop)操作来完成一次数据访问。
如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中、并更新C寄存器中下一条需要执行的字节码指令。
操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译器期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。
另外，我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。

栈顶缓存技术:

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

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

3.4.5 动态链接

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

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

3.4.8 方法的调用:解析与分派

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

方法的引用过程

静态链接:

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

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

应用过程对应的绑定机制

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

早期绑定:

早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时,即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用。

晚期绑定:

如果**被调用的方法在编译期无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，**这种绑定方式也就被称之为晚期绑定。

面向对象一般都具有早期绑定和晚期绑定

随着高级语言的横空出世，类似于Java一样的基于而向对象的编程语言如今越来越多，尽管这类编程语言在语法风格上存在一定的差别。但是它们彼此之间始终保持着一个共性，那就是都支持封装、继承和多态等而向对象特性，既然这一类的编程语言具备多态特性，那么自然也就几备早期绑定和晚期绑定两种绑定方式。

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

虚方法与非虚方法

非虚方法:

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

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

普通调用指令:
- invokestatic:调用静态方法，解析阶段确定唯一方法版本
- invokespecial:调用init方法、私有及父类方法，解析阶段确定唯一方法版本
- invokevirtual:调用所有虚方法(调用final方法和不使用 super.调用父类的方法也会执行invokevirtual，但他们都是非虚方法)
- invokeinterface:调用接口方法
动态调用指令:
- invokedynamic:动态解析出需要调用的方法，然后执行

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

invokedynamic指令

java7新增了invokedynamic指令，这是为了实现【动态类型语言】支持而做的一种改进

java8的Lambda表达式的出现使该指令在java中有了直接的生产

JAVA中方法重写的本质

Java 语言中方法重写的本质:

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

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

3．否则，按照继承关系从下往上依次对c的各个父类进行第⒉步的搜索和验证过程。4．如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。

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

虚方法表

在面向对象的编程中，会很频繁的使用到动态分派，如果在每次动态分派的过程中都要重新在类的方法元数据中搜索合适的目标的话就可能影响到执行效率。因此，为了提高性能，JVM采用在类的方法区建立一个虚方法表**(virtual method table)(非虚方法不会出现在表中)来实现。使用索引表来代替查找。**

每个类中都有一个虚方法表，表中存放着各个方法的实际入口

虚方法表会在类加载的链接阶段被创建并开始初始化，类的变量初始值准备完成之后，JVM会把该类的方法表也初始化完毕。

3.4.9 方法返回地址

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

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

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

3.5 本地方法栈

3.5.1 本地方法接口与本地方法库

本地方法接口和本地方法库都不在运行时数据区中

当java想要与操作系统打交道时需要用到c语言的一些方法，本地方法接口就对应着本定方法库中c语言的方法，java程序能通过调用本地方法接口来调用库函数

3.5.2 本地方法栈

Java虚拟机栈用于管理Java方法的调用，而本地方法栈用于管理本地方法的调用。
本地方法栈，也是线程私有的。
允许被实现成固定或者是可动态扩展的内存大小。(在内存溢出方面是相同的)
- 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个stackoverflowError异常。
- 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么Java虚拟机将会抛出一个outofMemoryError异常。
本地方法是使用c语言实现的。
它的具体做法是Native Method stack中登记natilve方法，在Execution Engine 执行时加载本地方法库。

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

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

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

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

3.6 堆

3.6.1 堆的核心概述

一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。Java堆区在JVM启动的时候即被创建，其空间大小也就确定了。是JVM管理的最大一块内存空间。
堆内存的大小是可以调节的。
《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区( Thread Local Allocation Buffer,TLAB)。
《Java虚拟机规范》中对Java堆的描述是:所有的对象实例以及数组都应当在运行时分配在堆上。(The heap is the run-time data area fromwhich memory for all class instances and arrays is allocated )>
- “几乎”所有的对象实例都在这里分配内存 —从实际使用角度看的。
数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。
在方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除。
堆，是GC ( Garbage collection，垃圾收集器）执行垃圾回收的重点区域。

堆的细分结构

JDK8将永久区替换为元空间

堆的大小实际上是新生区和养老区大小的和

3.6.2 设置堆大小与OOM

堆空间大小

Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项"-Xmx"和"-Xms"来进行设置。
- “-xms"用于表示堆区的起始内存，等价于-XX:InitialHeapsize“
- -Xmx"则用于表示堆区的最大内存，等价于-XX:MaxHeapsize
一旦堆区中的内存大小超过“-Xmx"所指定的最大内存时，将会抛出outofMemoryError异常。
通常会将-Xms和-Xmx两个参数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。
默认情况下，初始内存大小:物理电脑内存大小/ 64
最大内存大小:物理电脑内存大小/ 4

在生产环境中，通常让最大堆空间和初始堆空间一致，减少内存扩缩容操作带来的效率上的影响

如果想要查看堆区的信息，在运行程序时增加一个 -XX:+PrintGCDetails 参数

其中分别显示的是年轻代、老年代、（永久代/元空间）

OOM举例

当堆中没有内存完成实例分配,并且堆也无法再扩展是，Java虚拟机就会跑出OutOfMemoryError（OOM）

3.6.3 年轻代与老年代

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

如何配置新生代和老年代的内存占比：-XX:NewRatio=2 表示新生代占1，老年代占2，新生代占堆的1/3

在Hotspot中，Eden空间和另外两个survivor空间缺省所占的比例是8:1:1
- 当然开发人员可以通过选项 -XX :survivorRatio 调整这个空间比例。
比如-Xx :SurvivorRatio=8
几乎所有的Java对象都是在Eden区被new出来的。
- 绝大部分的Java对象的销毁都在新生代进行了。
IBM公司的专门研究表明，新生代中 80% 的对象都是“朝生夕死”的。
- 可以使用选项”-xmn"设置新生代最大内存大小

3.6.4 对象分配过程

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

new的对象先放伊甸园区。此区有大小限制。
当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区
然后将伊甸园中的剩余对象移动到幸存者0区。
如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。
如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
啥时候能去养老区呢?可以设置次数。默认是15次。

可以设置参数:-XX:MaxTenuringThreshold=进行设置阈值。

总结：

Eden区满，eden和survivor区触发垃圾回收，eden区没被回收的进入空的survivor，有数据的survivor将回收后的对象放入另一个
survivor区对象15次都没被回收就会进入老年代

eden放不下就直接放到老年代

survivor放不下也放老年代

老年代放不下就OOM

3.6.5 Minor GC、Major GC、Full GC

三种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会有这种行为
整堆收集（Full GC):收集整个java堆和方法区的垃圾收集。

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

当年轻代空间不足时，就会触发Minor GC，这里的年轻代满指的是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（但非绝对的，在ParallelScavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)
- 也就是在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC
Major GC的速度一般会比Minor GC慢10倍以上，STW的时间更长。
如果Major GC后，内存还不足，就报OOM了。

Fu1l GC触发机制:

触发Fu1l GC执行的情况有如下几种:

调用system.gc()时，系统建议执行Full GC，但是不必然执行
老年代空间不足
方法区空间不足
通过Minor GC后进入老年代的平均大小大于老年代的可用内存

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

3.6.6 堆空间的分代思想

为什么要对堆空间进行分代?

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

3.6.7 内存分配策略

针对不同年龄段的对象分配原则如下所示:

优先分配到Eden
大对象直接分配到老年代
- 尽量避免程序中出现过多的大对象
长期存活的对象分配到老年代
动态对象年龄判断
- 如果survivor区中相同年龄的所有对象大小的总和大于survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
空间分配担保 -XX:HandlePromotionFailure

3.6.8 为对象分配内存：TLAB

为什要有TLAB？

堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据
由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的
为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。

什么是TLAB？

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

TLAB说明：

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

TLAB分配过程

3.6.9 堆空间的参数配置小结

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

HandlePromotionFailure解释：

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

如果大于，则此次Minor GC是安全的
如果小于，则虚拟机会查看-xx:HandlePromotionFailure设置值是否允许
- 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。
  - 如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的;
  - 如果小于，则改为进行一次Full GC。
- 如果HandlePromotionFailure=false，则改为进行一次Full GC。

在JDK6 Update24之后(JDK7) , HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略，观察openJDK中的源码变化，虽然源码中还定义了

HandlePromotionFailure参数，但是在代码中已经不会再使用它。JDK6 Update24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。

相当于该参数一直是true

3.6.10 栈上分配

堆不是对象分配的唯一选择

在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述:
随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了

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

此外，前面提到的基于openJDK深度定制的TaoBaoVM，其中创新的GCIH (GC invisible heap）技术实现off-heap，将生命周期较长的Java对象从heap中移至heap外，并且GC不能管理GcIH内部的Java对象，以此达到降低cc的回收频率和提升GC的回收效率的目的。

逃逸分析概述:

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

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

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

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

当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
当一个对象在方法中被定义后，**对象被外部方法所引用，则认为发生逃逸。**例如作为调用参数传递到其他地方中。

参数设置:

在JDK 6u23版本之后，HotSpot中默认就已经开启了逃逸分析。.如果使用的是较早的版本，开发人员则可以通过:

选项“-XX:+DoEscapeAnalysis"显式开启逃逸分析
通过选项“-XX: +PrintEscapeAnalysis"查看逃逸分析的筛
选结果。

3.6.11 代码优化

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

一、栈上分配。

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

二、同步省略。

如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。

三、分离对象或标量替换。

有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。

栈上分配

尽量在方法内创建对象，并保证对象不会在方法外被使用

同步省略

如果一个方法内创建了一个对象被加锁了，且这个对象没有逃逸，不会被其他线程访问，那么JIT编译阶段就会自动把锁去了提升性能

分离对象或标量替换

如果对象能被分解成标量，且没有逃逸，那么这个对象在运行时会被分解成若干个标量（JAVA中指原始数据类型）

标量替换参数设置∶

参数-xx:+EliminateAllocations:开启了标量替换(默认打开)，允许将对象打散分配在栈上。

3.7 方法区

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

类型在方法区中

方法中的变量在栈的局部变量表里

对象实例在堆中

3.7.2 方法区的理解

基本理解

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

HotSpot中的方法区

在jdk7及以前，习惯上把方法区，称为永久代。jdk8开始，使用元空间取代了永久代。本质上，方法区和永久代并不等价。仅是对hotspot而言的。《Java虚拟机规范》对如何实现方法区，不做统一要求。

例如:BEA JRockit/ IBM J9中不存在永久代的概念。

现在来看，当年使用永久代，不是好的idea。导致Java程序更容易OOM（超过-xx: MaxPermsize上限)

而到了JDK 8，终于完全废弃了永久代的概念，改用与JRockit、J9一样在本地内存中实现的元空间(Metaspace）来代替
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于:
- 元空间不在虚拟机设置的内存中，而是使用本地内存。
永久代、元空间二者并不只是名字变了，内部结构也调整了。
根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OOM异常。

3.7.3 设置方法区大小

jdk7及以前:

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

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

3.7.4 方法区的内部结构

方法区的存放了什么内容

《深入理解Java虚拟机》书中对方法区（Method Area）存储内容描述如下：
它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。

类型信息

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

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

域(Field)信息

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

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

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

补充说明:全局常量: static final

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

常量池

常量池是字节码文件的一部分

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

为什么需要常量池?

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

比如:如下的代码:

虽然只有194字节，但是里面却使用了string、System、Printstream及Object等结构。这里代码量其实已经很小了。如果代码多，引用到的结构会更多!这里就需要常量池了!

常量池中存放了什么信息?

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

小结:

常量池，可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。

运行时常量池

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

3.6.5 方法区的演进细节

1.首先明确:只有Hotspot才有永久代。

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

2.Hotspot中方法区的变化:

版本	描述
<=jdk1.6	有永久代(permanent generation)，静态变量存放在永久代上
jdk1.7	有永久代，但已经逐步“去永久代”，字符串常量池、静态变量移除，保存在堆中
>=jdk1.8	无永久代，类型信息、字段、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量仍在堆

这里的静态变量指的是变量名

JDK6

JDK7

JDK8

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

为永久代设置空间大小是很难确定的。

在某些场景下，如果动态加载类过多，容易产生Perm区的oOM。比如某个实际web工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现致命错误。而元空间和永久代之间最大的区别在于:元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。
对永久代进行调优是很困难的。

为什么把StringTable放到堆空间

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

3.6.6 方法区的垃圾回收

一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前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.8 总结与常见面试题

常见面试题:

四、对象

4.1 对象的实例化

4.2 内存布局

4.3 访问定位

对象的访问定位一般分为两种方式：

直接引用（HotSpot）
- 局部变量表中的指针直接指向堆中对象实例的地址，对象头中的类型指针指向方法区中的类元信息
- 好处：寻址次数少，效率更高，占用内存少
句柄引用
- 局部变量表中的指针指向堆中维护的句柄表，句柄表包括了对象实例的地址和类元信息的地址
- 好处：在进行GC整理内存时只需要改变句柄表中对象实例的地址信息

五、直接内存

不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中定义的内存区域。

直接内存是在Java堆外的、直接向系统申请的内存区间。

来源于NIo，通过存在堆中的DirectByteBuffer操作Native内存通常，访问直接内存的速度会优于Java堆。即读写性能高。

因此出于性能考虑，读写频繁的场合可能会考虑使用直接内存。
Java的NIo库允许Java程序使用直接内存，用于数据缓冲区
直接内存也可能导致outofMemoryError异常
由于直接内存在Java堆外，因此它的大小不会直接受限于-Xmx指定的最大堆大小，但是系统内存是有限的，Java堆和直接内存的总和依然受限于操作系统能给出的最大内存。
直接内存可以通过MaxDirectMemorySize设置，如果不指定则默认和堆的最大内存 -Xmx 一致

六、执行引擎

6.1 概述

执行引擎是Java虚拟机核心的组成部分之一。
“虚拟机”是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的，而虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执行引擎的结构体系，能够执行那些不被硬件直接支持的指令集格式。

JVM的主要任务是负责装载字节码到其内部，但字节码并不能够直接运行在操作系统之上，因为字节码指令并非等价于本地机器指令，它内部包含的仅仅只是一些能够被JVM所识别的字节码指令、符号表，以及其他辅助信息。

那么，如果想要让一个Java程序运行起来，执行引擎(Execution Engine)的任务就是将字节码指令解释/编译为对应平台上的本地机器指令才可以。简单来说，JVM中的执行引擎充当了将高级语言翻译为机器语言的译者。

大概工作过程

执行引擎在执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器。
每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址。
当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息。

6.2 代码编译和执行过程

程序源码转换为物理机能执行的代码或虚拟机能执行的指令集的一般过程

JVM执行引擎执行字节码的过程

解释器与编译器

解释器:当Java虚拟机启动时会根据预定义的规范对字节码采用逐行解释的方式执行，将每条字节码文件中的内容“翻译”为对应平台的本地机器指令执行。
JIT (Just In Time Compiler)编译器:就是虚拟机将源代码直接编译成和本地机器平台相关的机器语言。

6.3 机器码、指令、汇编语言

机器码

各种用二进制编码方式表示的指令，叫做机器指令码。开始，人们就用它采编写程序，这就是机器语言。
机器语言虽然能够被计算机理解和接受，但和人们的语言差别太大，不易被人们理解和记忆，并且用它编程容易出差错。
用它编写的程序一经输入计算机，CPU直接读取运行，因此和其他语言编的程序相比，执行速度最快。
机器指令与CPU紧密相关，所以不同种类的CPU所对应的机器指令也就不同。

指令

由于机器码是有o和1组成的二进制序列，可读性实在太差，于是人们发明了指令。
指令就是把机器码中特定的o和1序列，简化成对应的指令（一般为英文简写，如mov,inc等），可读性稍好
由于不同的硬件平台，执行同一个操作，对应的机器码可能不同，所以不同的硬件平台的同一种指令（比如mov)，对应的机器码也可能不同。

指令集

不同的硬件平台，各自支持的指令，是有差别的。因此每个平台所支持的指令，称之为对应平台的指令集。
如常见的
- x86指令集，对应的是x86架构的平台ARM指令集，对应的是ARM架构的平台

汇编语言

由于指令的可读性还是太差，于是人们又发明了汇编语言。
在汇编语言中，用助记符(Mnemonics）代替机器指令的操作码，用地址符号(Symbol）或标号(Label)代替指令或操作数的地址。
在不同的硬件平台，汇编语言对应着不同的机器语言指令集，通过汇编过程转换成机器指令。
- 由于计算机只认识指令码，所以用汇编语言编写的程序还必须翻译成机器指令码，计算机才能识别和执行。

高级语言

为了使计算机用户编程序更容易些，后来就出现了各种高级计算机语言。高级语言比机器语言、汇编语言更接近人的语言
当计算机执行高级语言编写的程序时，仍然需要把程序解释和编译成机器的指令码。完成这个过程的程序就叫做解释程序或编译程序。

6.4 解释器

JVM设计者们的初衷仅仅只是单纯地为了满足Java程序实现跨平台特性，因此避免采用静态编译的方式直接生成本地机器指令，从而诞生了实现解释器在运行时采用逐行解释字节码执行程序的想法。

分类

字节码解释器
- 逐条解释
模版解释器
- 每个指令对应一个模版函数，直接生成对应的机器指码

解释器现在被认为是低效的代名词，所以出现了即时编译技术，将整个函数编译成机器码并缓存，函数执行时直接执行缓存

6.5 HotSpot的执行引擎

JVM中JIT会将热点代码通过JIT编译并缓存进方法区。

HotSpot VM是目前市面上高性能虚拟机的代表作之一。它采用解释器与即时编译器并存的架构。在Java虚拟机运行时，解释器和即时编译器能够相互协作，各自取长补短，尽力去选择最合适的方式来权衡编译本地代码的时间和直接解释执行代码的时间。
在今天，Java程序的运行性能早已脱胎换骨，已经达到了可以和C/C++程序一较高下的地步。

Hotspot使用解释器与JIT的原因

当虚拟机启动的时候，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成再执行，这样可以省去许多不必要的编译时间。并且随着程序运行时间的推移，即时编译器逐渐发挥作用，根据热点探测功能，将有价值的字节码编译为本地机器指令，以换取更高的程序执行效率。

解释器保证响应时间
JIT保证运行效率

6.6 JIT

编译器概念解释:

Java 语言的“编译期”其实是一段“不确定”的操作过程，因为它可能是指一个前端编译器（其实叫“编译器的前端”更准确一些）把.java文件转变成.class文件的过程;
也可能是指虚拟机的后端运行期编译器(JIT编译器，Just In Time Compiler)把字节码转变成机器码的过程。
·还可能是指使用静态提前编译器(AOT编译器，Ahead of Time Compiler）直接把.java文件编译成本地机器代码的过程。

热点代码探测方式：

当然是否需要启动JIT编译器将字节码直接编译为对应平台的本地机器指令，则需要根据代码被调用执行的频率而定。关于那些需要被编译为本地代码的字节码，也被称之为**“热点代码”，JIT编译器在运行时会针对那些频繁被调用的“热点代码”做出深度优化**，将其直接编译为对应平台的本地机器指令，以此提升Java程序的执行性能。

**一个被多次调用的方法，或者是一个方法体内部循环次数较多的循环体都可以被称之为“热点代码”，**因此都可以通过JIT编译器编译为本地机器指令。由于这种编译方式发生在方法的执行过程中，因此也被称之为栈上替换，或简称为oSR (On StackReplacement)编译。
一个方法究竟要被调用多少次，或者一个循环体究竟需要执行多少次循环才可以达到这个标准?必然需要一个明确的阈值，JIT编译器才会将这些“热点代码”编译为本地机器指令执行。这里主要依靠热点探测功能。
目前HotSpot VM所采用的热点探测方式是基于计数器的热点探测。
采用基于计数器的热点探测，HotSpot VM将会为每一个方法都建立2个不同类型的计数器，分别为方法调用计数器(Invocation Counter）和回边计数器(BackEdge Counter）。
- 方法调用计数器用于统计方法的调用次数
- 回边计数器则用于统计循环体执行的循环次数

方法计数器

这个计数器就用于统计方法被调用的次数，它的默认阈值在 client模式下是1500 次，在 Server模式下是10000 次。超过这个阈值，就会触发JIT编译。

这个阈值可以通过虚拟机参数**-xx: compileThreshold**来人为设定。

当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。

热度衰减

如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减(Counter Decay)，而这段时间就称为此方法统计的半衰周期(Counter Half Life Time)。

进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数**-XX:-UseCounterDecay**来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。

另外，可以使用**-XX:CounterHalfLifeTime**参数设置半衰周期的时间，单位是秒。

回边计数器

判断循环体执行次数

6.7 HotSpot设置模式

缺省情况下HotSpot VM是采用解释器与即时编译器并存的架构，当然开发人员可以根据具体的应用场景，通过命令显式地为Java虚拟机指定在运行时到底是完全采用解释器执行，还是完全采用即时编译器执行。如下所示:

-Xmixed 混合模式

-Xcomp 解释器模式

-Xint 编译模式

JIT分类

在HotSpot VM中内嵌有两个JIT编译器，分别为client Compiler和server

Compiler，但大多数情况下我们简称为c1编译器和c2编译器。开发人员可以通过如下命令显式指定Java虚拟机在运行时到底使用哪一种即时编译器，如下所示:

-client:指定Java虚拟机运行在client模式下，并使用c1编译器;
- c1编译器会对字节码进行简单和可靠的优化，耗时短。以达到更快的编译速度。
-server:指定Java虚拟机运行在server模式下，并使用c2编译器。
- C2进行耗时较长的优化，以及激进优化。但优化的代码执行效率更高。

七、StringTable

7.1 String的基本特性

string:字符串，使用一对""引起来表示。
- string sl = “atguigu” ;l/字面量的定义方式
- string s2 = new string ( “hello”) ;
string声明为final的，不可被继承
string实现了serializable接口:表示字符串是支持序列化的。实现了comparable接口:表示string可以比较大小
string在jdk8及以前内部定义了final char[ ] value用于存储字符串数据。jdk9时改为byte[]
string:代表不可变的字符序列。简称:不可变性。
- 当对字符串重新赋值时，需要重写指定内存区域赋值，不能使用原有的value进行赋值。
- 当对现有的字符串进行连接操作时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值。
- 当调用string的replace ()方法修改指定字符或字符串时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值。
通过字面量的方式（区别于new）给一个字符串赋值，此时的字符串值声明在字符串常量池中。
字符串常量池不会存储相同的字符串
- string的string Pool是一个固定大小的Hashtable，默认值大小长度是1009。如果放进string Pool的string非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了后直接会造成的影响就是当调用string.intern时性能会大幅下降。
- 使用**-XX : stringTablesize**可设置stringTable的长度
- 在jdk6中stringTable是固定的，就是1009的长度，所以如果常量池中的字符串过多就会导致效率下降很快。StringTablesize设置没有要求
- 在jdk7中，stringTable的长度默认值是60013。
- 在jdk8中，长度默认还是60013，最小值为1009否则无法运行

7.2 String的内存分配

在Java语言中有8种基本数据类型和一种比较特殊的类型string。这些类型为了使它们在运行过程中速度更快、更节省内存，都提供了一种常量池的概念。
常量池就类似一个Java系统级别提供的缓存。8种基本数据类型的常量池都是系统协调的，String类型的常量池比较特殊。它的主要使用方法有两种。
- 直接使用双引号声明出来的string对象会直接存储在常量池中。比如:string info = “atguigu.com” ;
- 如果不是用双引号声明的string对象，可以使用string提供的intern()方法。
Java6及以前，字符串常量池存放在永久代。
Java 7 中 oracle 的工程师对字符串池的逻辑做了很大的改变，即将字符串常量池的位置调整到Java堆内。
- 所有的字符串都保存在堆（Heap）中，和其他普通对象一样，这样可以让你在进行调优应用时仅需要调整堆大小就可以了。
- 字符串常量池概念原本使用得比较多，但是这个改动使得我们有足够的理由让我们重新考虑在Java 7 中使用string.intern ( ) 。
Java8元空间，字符串常量在堆

7.3 字符串拼接

1.常量与常量的拼接结果在常量池，原理是编译期优化

2.常量池中不会存在相同内容的常量。

3.**只要其中有一个是变量，结果就在堆中。**变量拼接的原理是StringBuilder

4.如果拼接的结果调用intern ()方法，则主动将常量池中还没有的字符串对象放入池中，并返回此对象地址。

如果拼接时操作符两边有变量。但是变量被final修饰了，这个值在编译时就能被确定，所以会指向常量池

final String a = "Hello";
String b = "HelloWorld";
String c = a + "Wordl";
System.out.println(c == b); // true

同时要注意如果频繁的做相同字符串的拼接，最好手动创建一个StringBuilder使用它的append方法，如果能确定最终字符串的长度，可以在创建StringBuilder对象的时候指定大小，避免了重复的扩容操作。

7.4 intern的使用

如果不是用双引号声明的string对象，可以使用string提供的intern方法: intern方法会从字符串常量池中查询当前字符串是否存在，若不存在就会将当前字符串放入常量池中。
- 比如:string myInfo = new String (“T love atguigu” ) .intern();
也就是说，如果在任意字符串上调用string.intern方法，那么其返回结果所指向的那个类实例，必须和直接以常量形式出现的字符串实例完全相同。因此，下列表达式的值必定是true:
- ( “a” + “b” + “c”) .intern () == “abc”
通俗点讲，Interned string就是确保字符串在内存里只有一份拷贝，这样可以节约内存空间，加快字符串操作任务的执行速度。注意，这个值会被存放在字符串内部池( string Intern Pool)

面试难题(运行结果在不同版本不同)

String s = new String( original: "1");
s.intern( );
String s2 = "1";
System.out.println(s == s2);//	jdk6=>false		jdk7/8=>false

String s3 = new String( original: "1") + new String( original: "1");
s3.intern();
String s4 = "11";
System.out.println(s3 == s4);//	jdk6=>false		jdk7/8=>true

jdk1.6中，将这个字符串对象尝试放入串池。
- 如果串池中有，则并不会放入。返回已有的串池中的对象的地址
- 如果没有，会把此对象复制一份，放入串池，并返回串池中的对象地址
Jdk1.7起，将这个字符串对象尝试放入串池。
- 如果串池中有，则并不会放入。返回已有的串池中的对象的地址
- 如果没有，则会把对象的引用地址复制一份，放入串池，并返回串池中的引用地址

7.5 String垃圾回收

StringTable中存的只是一个索引，索引指向堆内存（JDK1.8）中一个String对象，这些对象也会被垃圾回收‘

所以可以提高内存的利用率

7.6 G1中String的去重操作

背景:对许多Java应用(有大的也有小的）做的测试得出以下结果:
- 堆存活数据集合里面string对象占了25%
- 堆存活数据集合里面重复的string对象有13.5%
- String对象的平均长度是45
许多大规模的Java应用的瓶颈在于内存，测试表明，在这些类型的应用里面，Java堆中存活的数据集合差不多25%是string对象。更进一步这里面差不多一半string对象是重复的，重复的意思是说:
stringl.equals (string2) =true。堆上存在重复的string对象必然是一种内存的浪费。这个项目将在c1垃圾收集器中实现自动持续对重复的string对象进行去重，这样就能避免浪费内存。

八、垃圾回收

8.1 概述

8.1.1 什么是垃圾

垃圾是指在运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾。

如果不及时对内存中的垃圾进行清理，那么，这些垃圾对象所占的内存空间会一直保留到应用程序结束，被保留的空间无法被其他对象使用。甚至可能导致内存溢出。

垃圾收集，不是Java语言的伴生产物。早在1960年，第一门开始使用内存动态分配和垃圾收集技术的Lisp语言诞生。
关于垃圾收集有三个经典问题:
- 哪些内存需要回收?
- 什么时候回收?
- 如何回收?
垃圾收集机制是Java的招牌能力，极大地提高了开发效率。如今，垃圾收集几乎成为现代语言的标配，即使经过如此长时间的发展，Java的垃圾收集机制仍然在不断的演进中，不同大小的设备、不同特征的应用场景，对垃圾收集提出了新的挑战，这当然也是面试的热点。

8.1.2 为什么需要GC

对于高级语言来说，一个基本认知是如果不进行垃圾回收，内存迟早都会被消耗完，因为不断地分配内存空间而不进行回收，就好像不停地生产生活垃圾而从来不打扫—样。
除了释放没用的对象，垃圾回收也可以清除内存里的记录碎片。碎片整理将所占用的堆内存移到堆的一端，以便JVM将整理出的内存分配给新的对象。
随着应用程序所应付的业务越来越庞大、复杂，用户越来越多，没有cc就不能保证应用程序的正常进行。而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化。

8.1.3 早期垃圾回收

在早期的C/C++时代，垃圾回收基本上是手工进行的。开发人员可以使用new关键字进行内存申请，并使用delete关键字进行内存释放。

这种方式可以灵活控制内存释放的时间，但是会给开发人员带来频繁申请和释放内存的管理负担。倘若有一处内存区间由于程序员编码的问题忘记被回收，那么就会产生内存泄漏，垃圾对象永远无法被清除，随着系统运行时间的不断增长，垃圾对象所耗内存可能持续上升，直到出现内存溢出并造成应用程序崩溃。

现在，除了Java以外，C#、Python、Ruby等语言都使用了自动垃圾回收的思想，也是未来发展趋势。可以说，这种自动化的内存分配和垃圾回收的方式己经成为现代开发语言必备的标准。

8.1.4 JAVA垃圾回收机制

好处

自动内存管理，无需开发人员手动参与内存的分配与回收，这样降低内存泄漏和内存溢出的风险

没有垃圾回收器，java也会和cpp一样，各种悬垂指针，野指针，泄露问题让你头疼不已。

自动内存管理机制，将程序员从繁重的内存管理中释放出来，可以更专心地专注于业务开发

后果

对于Java开发人员而言，自动内存管理就像是一个黑匣子，如果过度依赖于“自动”，那么这将会是一场灾难，最严重的就会弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力。
此时，了解JVM的自动内存分配和内存回收原理就显得非常重要，只有在真正了解JVM是如何管理内存后，我们才能够在遇见outofMemoryError时，快速地根据错误异常日志定位问题和解决问题。
当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就必须对这些“自动化”的技术实施必要的监控和调节。

8.2 垃圾回收算法

在堆里存放着几乎所有的Java对象实例，在GC执行垃圾回收之前，首先需要区分出内存中哪些是存活对象，哪些是已经死亡的对象。只有被标记为己经死亡的对象，GC才会在执行垃圾回收时，释放掉其所占用的内存空间，因此这个过程我们可以称为垃圾标记阶段。
那么在JVM中究竟是如何标记一个死亡对象呢?简单来说，当一个对象已经不再被任何的存活对象继续引用时，就可以宣判为已经死亡。
判断对象存活一般有两种方式:引用计数算法和可达性分析算法。

8.2.1 标记阶段:引用计数算法

引用计数算法(Reference Counting)比较简单，对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。

对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1;当引用失效时，引用计数器就减1。只要对象A的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收。

优点:

实现简单，垃圾对象便于辨识;判定效率高，回收没有延迟性。

缺点:

它需要单独的字段存储计数器，这样的做法增加了存储空间的开销。
每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。
引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷导致在Java的垃圾回收器中没有使用这类算法。

8.2.2 标记阶段：可达性分析算法(根搜索算法,追踪性垃圾收集)

相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。

相较于引用计数算法，这里的可达性分析就是Java、C#选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集（ Tracing Garbagecollection) 。

基本思路

所谓"GC Roots"根集合就是一组必须活跃的引用。

基本思路:

可达性分析算法是以根对象集合(GC Roots)为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。
使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链(Reference Chain)
如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。
在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。

哪些对象可以作为GC Roots

虚拟机栈中引用的对象
- 比如:各个线程被调用的方法中使用到的参数、局部变量等。
本地方法栈内JNI(通常说的本地方法)引用的对象
方法区中类静态属性引用的对象
- 比如: Java类的引用类型静态变量
方法区中常量引用的对象
- 比如:字符串常量池（String Table）里的引用
所有被同步锁synchronized持有的对象
Java虚拟机内部的引用。
- 基本数据类型对应的Class对象，一些常驻的异常对象（如:NullPointerException、outofMemoryError)，系统类加载器。
反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。比如:分代收集和局部回收(Partial GC)
- 如果只针对Java堆中的某一块区域进行垃圾回收（比如:典型的只针对新生代），必须考虑到内存区域是虚拟机自己的实现细节，更不是孤立封闭的，这个区域的对象完全有可能被其他区域的对象所引用，这时候就需要一并将关联的区域对象也加入GC Roots集合中去考虑，才能保证可达性分析的准确性。

小技巧:

由于Root采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个Root

注意:

如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。

这点也是导致GC进行时必须**“stop The world”**的一个重要原因。即使是号称（几乎）不会发生停顿的CMS 收集器中，枚举根节点时
也是必须要停顿的。

8.2.3 对象的finalization机制

Java语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。

当垃圾回收器发现没有引用指向一个对象，即:垃圾回收此对象之前，总会先调用这个对象的finalize ()方法。

finalize()方法允许在子类中被重写，**用于在对象被回收时进行资源释放。**通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。

永远不要主动调用某个对象的finalize ()方法，应该交给垃圾回收机制调用。
括下面三点:

在finalize ()时可能会导致对象复活。
finalize ()方法的执行时间是没有保障的，它完全由cc线程决定，极端情况下，若不发生GC，则finalize ( )方法将没有执行机会。
一个糟糕的finalize()会严重影响GC的性能。

从功能上来说，finalize()方法与c++中的析构函数比较相似，但是Java采用的是基于垃圾回收器的自动内存管理机制，所以finalize()方法在本质上不同于c++中的析构函数。

由于finalize()方法的存在，虚拟机中的对象一般处于三种可能的状态。

一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它的回收就是不合理的，为此，定义虚拟机中的对象可能的三种状态。如下:
- 可触及的:从根节点开始，可以到达这个对象。
- 可复活的:对象的所有引用都被释放，但是对象有可能在finalize ()中复活。
- 不可触及的:对象的finalize ()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一次。
以上3种状态中，是由于finalize ()方法的存在，进行的区分。只有在对象不可触及时才可以被回收。

判定一个对象objA是否可回收，至少要经历两次标记过程:

1．如果对象objA到 GC Roots没有引用链，则进行第一次标记。

2．进行筛选，判断此对象是否有必要执行finalize ()方法

如果对象objA没有重写finalize()方法，或者finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA被判定为不可触及的。
如果对象objA重写了finalize()方法，且还未执行过，那么objA会被插入到F-Queue队列中，由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize()方法执行。
finalize()方法是对象逃脱死亡的最后机会，稍后cc会对F-Queue队列中的对象进行第二次标记。如果objA在finalize ()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被移出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize方法只会被调用一次。

8.2.4 清除阶段：标记-清除算法

背景:

标记–清除算法( Mark-Sweep )是一种非常基础和常见的垃圾收集算法，该算法被J.McCarthy等人在1960年提出并并应用于Lisp语言。

执行过程:

当堆中的有效内存空间(available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world)，然后进行两项工作，第一项则是标记，第二项则是清除。

标记:collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
清除:collector对堆内存从头到尾进行线性的通力，如果友现呆个对家仕其Header中没有标记为可达对象，则将其回收。

缺点:

效率不算高
在进行cc的时候，需要停止整个应用程序，导致用户体验差这种方式清理出来的空闲内存是不连续的，产生内存碎片。
需要维护一个空闲列表

8.2.5 清除阶段：复制算法

背景:

为了解决标记-清除算法在垃圾收集效率方面的缺陷，M.L.Minsky于1963年发表了著名的论文，“使用双存储区的Lisp语言垃圾收集器CALISP Garbage collector Algorithm using serial secondary Storage ) ”。M.L.Minsky在该论文中描述的算法被人们称为复制(copying）算法，它也被M.L.Minsky 本人成功地引入到了Lisp语言的一个实现版本中。

核心思想:

将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收。

优点:

没有标记和清除过程，实现简单，运行高效
复制过去以后保证空间的连续性，不会出现“碎片”问题。

缺点:

此算法的缺点也是很明显的，就是需要两倍的内存空间。
对于G1这种分拆成为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小

8.2.6 清除阶段：标记-压缩算法

背景:

复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。

标记一清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础之上进行改进压缩（Mark - compact）算法由此诞生。

1970年前后，G. L. steele .c. J. Chene 和D.s. wise 等研究者发布标记-压缩算法。在许多现代的垃圾收集器中，人们都使用了标记-压缩算法或其改进版本。

步骤:

第一阶段和标记-清除算法一样，从根节点开始标记所有被引用对象
第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。
之后，清理边界外所有的空间。

优点:

消除了标记-清除算法当中，内存区域分散的缺点，我们需要给内存时，JVM只需要持有一个内存的起始地址即可。
消除了复制算法当中，内存减半的高额代价。

缺点:

从效率上来说，标记-整理算法要低于复制算法。
移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址。
移动过程中，需要全程暂停用户应用程序。即:STW

8.2.7 小结

8.2.8 分代收集算法

前面所有这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集算法应运而生。

分代收集算法，是基于这样一个事实:不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率。

在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如: String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。

目前几乎所有的GC都是采用分代收集（Generational Collecting）算法执行垃圾回收的。

在HotSpot中，基于分代的概念，GC所使用的内存回收算法必须结合年轻代和老年代各自的特点。

年轻代(Young Gen)

年轻代特点:区域相对老年代较小，对象生命周期短、存活率低，回收频繁。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

老年代(Tenured Gen)

老年代特点:区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。

这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记-清除或者是标记-清除与标记-整理的混合实现。
Mark阶段的开销与存活对象的数量成正比。Sweep阶段的开销与所管理区域的大小成正相关。compact阶段的开销与存活对象的数据成正比。

8.2.9 增量收集算法、分区算法

增量收集算法

上述现有的算法，在垃圾回收过程中，应用软件将处于一种stop the world 的状态。在stop the world 状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，**将严重影响用户体验或者系统的稳定性。**为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集(Incremental collecting）算法的诞生。

基本思想:

如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。

总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作。

缺点:

使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

分区算法

一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。为了更好地控制cc产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。

分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间region。

每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间。

8.3 垃圾回收相关概念

8.3.1 System.gc()的理解

在默认情况下，通过System.gc()或者Runtime. getRuntime ( ) .gc ()的调用，会显式触发Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。
然而System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用。
JVM实现者可以通过system.gc ()调用来决定JVM的GC行为。而一般情况下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。在一些特殊情况下，如我们正在编写一个性能基准，我们可以在运行之间调用System.gc ( ) 。

8.3.2 内存溢出与内存泄露

内存溢出(OOM)

内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一。
由于GC一直在发展，所有一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现ooM的情况。

大多数情况下，GC会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的Full GC操作，这时候会回收大量的内存，供应用程序继续使用。

javadoc中对outofMemoryError的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。

原因

(1) Java虚拟机的堆内存设置不够。
比如:可能存在内存泄漏问题;也很有可能就是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显式指定JVM堆大小或者指定数值偏小。我们可以迪过参数-Xms. -Xmx来调整。

(2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用)

对于老版本的oracle JDK，因为永久代的大小是有限的，并且JVM对永久代垃圾回收(如，常量池回收、卸载不再需要的类型）非常不积极，所以当我们不断添加新类型的时候，永久代出现outOfMemoryError也非常多见，尤其是在运行时存在大量动态类型生成的场合;类似intern字符串缓存占用太多空间，也会导致ooM问题。对应的异常信息，会标记出来和永久代相关:“java.lang.OutOfMemoryError: PermGen space"。

随着元数据区的引入，方法区内存已经不再那么窘迫，所以相应的ooM有所改观，出现OOM，异常信息则变成了:“java.lang.OutOfMemoryError: Metaspace"。直接内存不足，也会导致OOM。

内存泄露

也称作“存储渗漏”。严格来说，只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏。.
但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致OOM，也可以叫做宽泛意义上的“内存泄漏”。

尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现outOfMemory异常,导致程序崩溃。

注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。

举例:

1、单例模式

单例的生命周期和应用程序是一样长的，所以单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。

2、一些提供close的资源未关闭导致内存泄漏

数据库连接（ dataSourse.getconnection()），网络连接(socket)和io连接必须手动close，否则是不能被回收的。

8.3.3 Stop The World

stop-the-world ，简称sTw，指的是cc事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为STw。
- 可达性分析算法中枚举根节点(GC Roots）会导致所有Java执行线程停顿。
  - √分析工作必须在一个能确保一致性的快照中进行
  - √一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
  - √如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证
被STW中断的应用程序线程会在完成GC之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以我们需要减少STW的发生。
STW事件和采用哪款GC无关，所有的GC都有这个事件。
哪怕是G1也不能完全避免stop-the-world情况发生，只能说垃圾回收器越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间。
STW是JVM在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。
开发中不要用system.gc();会导致stop-the-world的发生。

8.3.4 垃圾回收的并行与并发

程序中的并发

在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理器上运行。

并发不是真正意义上的“同时进行”，只是CP把一个时间段划分成几个时间片段(时间区间)，然后在这几个时间区间之间来回切换，由于CPU处理的速度非常快，只要时间间隔处理得当，即可让用户感觉是多个应用程序同时在进行。

程序中的并行

当系统有一个以上cPU时，当一个cPu执行一个进程时，另一个cPU可以执行另一个进程，两个进程互不抢占CPU资源，可以同时进行，我们称之为并行(Parallel)。
其实决定并行的因素不是cPU的数量，而是cPU的核心数量，比如一个cPU多个核也可以并行。
适合科学计算，后台处理等弱交互场景

垃圾回收中的并发与并行

并发和并行，在谈论垃圾收集器的上下文语境中，它们可以解释如下:

并行(Parallel):指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
- 如ParNew、Parallel scavenge、Parallel old;
·串行(Serial)
- 相较于并行的概念，单线程执行。
- 如果内存不够，则程序暂停，启动JVM垃圾回收器进行垃圾回收。回收完，再启动
  程序的线程。

并发(Concurrent):指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行)，垃圾回收线程在执行时不会停顿用户程序的运行。

用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上;
如:CMS、G1

8.3.5 安全点与安全区域

安全点

程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置称为“安全点(Safepoint) ”。

Safe Point的选择很重要，如果太少可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。比如:选择一些执行时间较长的指令作为Safe Point，如方法调用、循环跳转和异常跳转等。

如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢?

抢先式中断:（目前没有虚拟机采用了)
- 首先中断所有线程。如果还有线程不在安全点，就恢复线程，让线程跑到安全点。
主动式中断:
- 设置一个中断标志，各个线程运行到safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。

安全区域

Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的 Safepoint 。但是，程序“不执行”的时候呢?例如线程处于Sleep 状态或Blocked 状态，这时候线程无法响应JVM的中断请求，“走”到安全点去中断挂起，JVM也不太可能等待线程被唤醒。对于这种情况，就需要安全区域( Safe Region）来解决。

安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。我们也可以把safe Region看做是被扩展了的safepoint。

实际执行时:

1、当线程运行到safe Region的代码时，首先标识已经进入了Safe Region,如果这段时间内发生Gc，JVM会忽略标识为Safe Region状态的线程;

2、当线程即将离开safe Region时，会检查JVM是否已经完成Gc，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开safe Region的信号为止;

8.3.6 引用概述

在JDK 1.2版之后，Java对引用的概念进行了扩充，将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用（weak Reference）和虚引用(Phantom Reference）4种，这4种引用强度依次逐渐减弱。

强、软、弱、虚

强引用(StrongReference):最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“object obj=new 0bject()”这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。

软引用(SoftReference）:在系统将要发生内存溢出之前，将会把这些对象列入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出异常

弱引用（WeakReference）:被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象。

虚引用（PhantomReference） :一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

8.3.6 强引用

在]ava程序中，最常见的引用类型是强引用（普通系统99%以上都是强引用)，也就是我们最常见的普通对象引用，也是默认的引用类型。

当在Java语言中使用new操作符创建一个新的对象，并将其赋值给一个变量的时候，这个变量就成为指向该对象的一个强引用。

强引用的对象是可触及的，垃圾收集器就永远不会回收掉被引用的对象。

对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显式地将相应（强）引用赋值为null，就是可以当做垃圾被收集了，当然具体回收时机还是要看垃圾收集策略。

相对的，软引用、弱引用和虚引用的对象是软可触及、弱可触及和虚可触及的，在定条件下，都是可以被回收的。所以，强引用是造成Java内存泄漏的主要原因之一。

特点：

强引用可以直接访问目标对象。
强引用所指向的对象在任何时候都不会被系统回收，虚拟机宁愿抛出OOM异常，也不会回收强引用所指向对象。
强引用可能导致内存泄漏。

8.3.7 软引用

SoftReference

软引用是用来描述一些还有用，但非必需的对象。只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。

软引用通常用来实现内存敏感的缓存。比如:高速缓存就有用到软引用。如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。

垃圾回收器在某个时刻决定回收软可达的对象的时候，会清理软引用，并可选地把引用存放到一个引用队列（Reference Queue) 。

类似弱引用，只不过Java虚拟机会尽量让软引用的存活时间长一些，迫不得己才清理。

8.3.8 弱引用

WeakReference

弱引用也是用来描述那些非必需对象，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。

但是，由于垃圾回收器的线程通常优先级很低，因此，并不一定能很快地发现持有弱引用的对象。在这种情况下，弱引用对象可以存在较长的时间。

弱引用和软引用一样，在构造弱引用时，也可以指定一个引用队列，当弱引用对象被回收时，就会加入指定的引用队列，通过这个队列可以跟踪对象的回收情况。

**软引用、弱引用都非常适合来保存那些可有可无的缓存数据。**如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。

WeakHashMap中Entry的实现继承了WeakReference，这样可以在内存不足的时候删除map中的数据

8.3.9 虚引用

PhantomReference

虚引用必须和引用队列一起使用。虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时，如果发现它’有成引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程对象的回收情况。

由于虚引用可以跟踪对象的回收时间，因此，也可以将一些资源释放操作放置在虚引用中执行和记录。

在JDK 1.2版之后提供了PhantomReference类来实现虚引用。

8.4 垃圾回收器

8.4.1 GC分类与性能指标

垃圾收集器没有在规范中进行过多的规定，可以由不同的厂商、不同版本的JVM来实现。
由于JDK的版本处于高速迭代过程中，因此Java发展至今已经衍生了众多的GC版本。
从不同角度分析垃圾收集器，可以将GC分为不同的类型。

指标:

吞吐量:运行用户代码的时间占总运行时间的比例（总运行时间:程序的运行时间＋内存回收的时间)

垃圾收集开销:吞吐量的补数，垃圾收集所用时间与总运行时间的比例。

暂停时间:执行垃圾收集时，程序的工作线程被暂停的时间。

收集频率:相对于应用程序的执行，收集操作发生的频率。

内存占用:Java堆区所占的内存大小。

快速:一个对象从诞生到被回收所经历的时间。

吞吐量、暂停时间、内存占用构成一个“不可能三角”，最多只能满足其中两者

吞吐量优先、暂停时间优先

吞吐量优先代表，单次暂停时间可能会长一些，保证单位时间内暂停时间最短即可,需要降低回收的频率。

吞吐量优先代表，单次暂停时间短，回收频率高，吞吐量更小

当前标准：在最大吞吐量优先的情况下，尽量降低暂停时间

8.4.2 不同垃圾回收器概述

新生代收集器: Serial、ParNew、Parallel scavenge;
老年代收集器: Serial old、Parallel old、CMS;
整堆收集器:G1;

红线：在jdk8中过时，jdk移除

绿线：jdk14移除

青线：jdk9过时,jdk14移除

在jdk9时G1作为默认回收器

在jdk8时Parallel作为默认回收器

如何查看默认垃圾回收器

-XX :+PrintCommandLineFlags:查看命令行相关参数（包含使用的垃圾收集器)

使用命令行指令: jinfo -flag 相关垃圾回收器参数进程ID

8.4.3 Seria回收器:串行回收

Serial收集器是最基本、历史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的选择。
Serial收集器作为HotSpot中client模式下的默认新生代垃圾收集器。
Serial收集器采用复制算法、串行回收和"stop-the-world"机制的方式执行内存回收。
除了年轻代之外，Serial收集器还提供用于执行老年代垃圾收集的serial old收集器。Serial old 收集器同样也采用了串行回收和"stop the world"机制，只不过内存回收算法使用的是标记-压缩算法。
- Serial old是运行在client模式下默认的老年代的垃圾回收器
- Serial old在server模式下主要有两个用途:①与新生代的ParallelScavenge配合使用②作为老年代CMs收集器的后备垃圾收集方案

这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPu或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束(stop The world)

**优势:**简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。运行在client模式下的虚拟机是个不错的选择。

在HotSpot虚拟机中，使用**-XX:+UseSerialGC**参数可以指定年轻代和老年代都使用串行收集器。等价于新生代用serial GC，且老年代用serial old GC

8.4.4 ParNew回收器:并行回收

如果说serial cc是年轻代中的单线程垃圾收集器，那么ParNew收集器则是serial收集器的多线程版本。

Par是Parallel的缩写，New:只能处理的是新生代

ParNew收集器除了采用并行回收的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。ParNew收集器在年轻代中同样也是采用复制算法、"stop-the-world"机制。

ParNew是很多JVM运行在server模式下新生代的默认垃圾收集器。

在单个CPU的环境下，ParNew收集器不比Serial收集器更高效。虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销。

在程序中，开发人员可以通过选项"-XX:+UseParNewGC"手动指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代。

-XX: ParallelGCThreads 限制线程数量，默认开启和cPU数据相同的线程数。

8.4.5 Parallel Scavenge回收器:吞吐量优先

HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外，Parallel Scavenge收集器同样也采用了复制算法、并行回收和"Stopthe world"机制。
那么Parallel收集器的出现是否多此一举?
- 和ParNew收集器不同，Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)，它也被称为吞吐量优先的垃圾收集器。
- 自适应调节策略也是Parallel scavenge与ParNew一个重要区别。

高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此，常见在服务器环境中使用。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序。

Parallel收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel old收集器，用来代替老年代的serial old收集器。

Parallel old收集器采用了标记-压缩算法，但同样也是基于并行回收和"Stop-the-world"机制。

参数:

-XX:+UseParallelGC手动指定年轻代使用Parallel并行收集器执行内存回收任务。
-XX:+UseParallelOldGC手动指定老年代都是使用并行回收收集器。分别适用于新生代和老年代。默认jdk8是开启的。上面两个参数，默认开启一个，另一个也会被开启。（互相激活)
-XX : ParallelGCThreads设置年轻代并行收集器的线程数。一般地，最好与cPu数量相等，以避免过多的线程数影响垃圾收集性能。
- 在默认情况下，当CPU数量小于8个，ParallelGcThreads 的值等于cPU数量。
- 当CPU数量大于8个，ParallelGcThreads 的值等于3+[5*CPU_count]/8]。
-XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间(即sTw的时间)。单位是毫秒。
- 为了尽可能地把停顿时间控制在MaxGCPauseMills以内，收集器在工作时会调整Java堆大小或者其他一些参数。
- 对于用户来讲，停顿时间越短体验越好。但是在服务器端，我们注重高并发，整体的吞吐量。所以服务器端适合Parallel，进行控制。
-XX:GCTimeRatio 垃圾收集时间占总时间的比例(= 1 / (N + 1))。用于衡量吞吐量的大小。
- 取值范围（0,100）。默认值99，也就是垃圾回收时间不超过1%
- 与前一个-XX:MaxGCPauseMillis参数有一定矛盾性。暂停时间越长，Radio参数就容易超过设定的比例。
-XX:+UseAdaptivesizePolicy设置Parallel Scavenge收集器具有自适应调节策略
- 在这种模式下，年轻代的大小、Eden和survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、合吐里和行以时间之间的平衡点。

8.4.6 CMS回收器:低延迟

在JDK 1.5 时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器:CMS (concurrent-Mark-Sweep)收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。
CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。
- 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMs收集器就非常符合这类应用的需求。
CMS的垃圾收集算法采用标记-清除算法，并且也会"Stop-the-world”

不幸的是，CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel scavenge 配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者serial收集器中的一个。

在G1出现之前，CMS使用还是非常广泛的。

优缺点分析

优点:

低延迟
并发收集

缺点:

会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发Full GC。
CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿,为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。
CMS收集器无法处理浮动垃圾。可能出现“concurrent Mode railure"失败而导致另一次 Full Gc 的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMs将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行Gc时释放这些之前未被回收的内存空间。

8.4.7 G1回收器:区域化分代式

为什么要使用G1

应用程序所应对的业务越来越庞大、复杂，用户越来越多，就不能保证应用程序正常进行，而经常造成sTw的cc又跟不上实际的需求，所以才会不断地尝试对cc进行优化。G1 (Garbage-First）垃圾回收器是在Java7 update 4之后引入的一个新的垃圾回收器，是当今收集器技术发展的最前沿成果之一。

与此同时，为了适应现在不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间(pause time)，同时兼顾良好的吞吐量。

官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以才担当起“全功能收集器”的重任与期望。

为什么命名为G1

因为G1是一个并行回收器，它把堆内存分割为很多不相关的区域(Region)不连续的）。使用不同的Region来表示Eden、幸存者o区，幸存者1区，老年代等。
G1GC有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个 Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值)，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。
由于这种方式的侧重点在于回收垃圾最大量的区间（Region)，所以我们给G1一个名字:垃圾优先（Garbage First）。

G1简介

G1 (Garbage-First）是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器，以极高概率满足GC停顿时间的同时,具高吞吐量的性能特征。

在JDK1.7版本正式启用，移除了Experimental的标识，是JDK 9以后的默认垃圾回收器，取代了CMS回收器以及Parallel + Parallel old组合。被oracle官方称为“全功能的垃圾收集器”。

与此同时，CMS已经在JDK 9中被标记为废弃（deprecated)。在jdk8中还不是默认的垃圾回收器，需要使用-XX:+UseG1GC来启用。

优势特点

并行与并发
- 并行性: G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。此时用户线程STW
- 并发性: G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况
分代收集
- 从分代上看，G1依然属于分代型垃圾回收器，它会区分年轻代和老年代，年轻代依然有Eden区和survivor区。但从堆的结构上有，它不要求整个Eden区、年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量。
- 将堆空间分为若干个区域(Region)，这些区域中包含了逻辑上的年轻代和老年代
- 和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器,作在年轻代，或者工作在老年代;
空间整合
- CMS:“标记-清除”算法、内存碎片、若干次GC后进行一次碎片整理
- G1将内存划分为一个个的region。内存的回收是以region作为基本单位的。Region之间是复制算法，但整体上实际可看作是标记-压缩（Mark-Compact)算法，两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配
  大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当Java堆非常大的时候，G1的优势更加明显。
**可预测的停顿时间模型（即:软实时soft real-time)
这是G1相对于CMs 的另一大优势，G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M笔秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。
由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。
G1跟踪各个 Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值)，在后台维护一个优先列表，每次根据运行的收集时间，优先回收价值最大的Region。保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。
相比于CMS GC，G1未必能做到CMS在最好情况下的延时停顿，但是最差情况要
好很多。

缺点

相较于CMS，G1还不具备全方位、压倒性优势。比如在用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用(Footprint）还是程序运行时的额外执行负载（overload）都要比CMS要高。

从经验上来说，在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。

G1适用场景

面向服务端应用，针对具有大内存、多处理器的机器。(在普通大小的堆里表现并不惊喜)

最主要的应用是需要低GC延迟，并具有大堆的应用程序提供解决方案;

如:在堆大小约6GB或更大时，可预测的暂停时间可以低于0.5秒;(G1通过每次只清理一部分而不是全部的Region的增量式清理来保证每次GC停顿时间不会过长)。

用来替换掉丁JDK1.5中的CMS收集器;

在下面的情况时，使用G1可能比CMS好:

超过50%的Java堆被活动数据占用;
对象分配频率或年代提升频率变化很大;
GC停顿时间过长（长于e.5至1秒)

HotSpot垃圾收集器里，除了G1以外，其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作，而G1 GC可以采用应用线程承担后台运行的Gc工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。

分区region

使用G1收集器时，它将整个Java堆划分成约2048个大小相同的独立Region块，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的N次幂，即1MB，2MB，4MB,8MB,16MB,32MB。可以通过-XX:GlHeapRegionsize设定。所有的Region大小相同，且在JVM生命周期内不会被改变。

虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region(不需要连续）的集合。通过Region的动态分配方式实现逻辑上的连续。

一个region有可能属于Eden，survivor或者 old/Tenured 内存区域。但是一个region只可能属于一个角色。图中的E表示该region属于Eden内存区域，s表示属于survivor内存区域，o表示属于old内存区域。图中空白的表示未使用的内存空间。
G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的 H块。主要用于存储大对象，如果超过0.5个region，就放到 H。

设置H的原因:

对于堆中的大对象，默认直接会被分配到老年代，但是如果它是一个短期存在的大对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放大对象。**如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储。**为了能找到连续的H区，有时候不得不启动Full Gc。G1的大多数行为都把H区作为老年代的一部分来看待。

G1垃圾回收过程

G1 GC的垃圾回收过程主要包括如下三个环节:

年轻代Gc(Young GC)
老年代并发标记过程(Concurrent Marking)
混合回收（Mixed GC)
(如果需要，单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收。)

相关概念

Remember Set

一个对象被不同区域引用的问题
一个Region不可能是孤立的，一个Region中的对象可能被其他任意Region中对象引用，判断对象存活时，是否需要扫描整个Java堆才能保证准确?
在其他的分代收集器，也存在这样的问题（而G1更突出)回收新生代也不得不同时扫描老年代?
这样的话会降低Minor GC的效率;

解决方案:

无论G1还是其他分代收集器，JVM都是使用Remembered Set来避免全局扫描:
每个Region都有一个对应的Remembered Set;
每次Reference类型数据写操作时，都会产生一个Write Barrier暂时中断操作
然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region(其他收集器:检查老年代对象是否引用了新生代对象）如果不同，通过CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中;
当进行垃圾收集时，在Gc根节点的枚举范围加入Remembered Set;就可以保证不进行全局扫描，也不会有遗漏。

8.4.8 垃圾回收器总结

7款经典垃圾回收器

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EqGHiNXx-1637148184541)(jvm-%E4%B8%8A%E7%AF%87-%E5%86%85%E5%AD%98%E4%B8%8E%E5%9E%83%E5%9C%BE%E5%9B%9E%E6%94%B6.assets/image-20211116140610740.png)]

8.4.9 GC日志分析

-XX :+PrintGC 输出GC日志。类似:-verbose:gc

-XX:+PrintGCDetails 输出GC详细日志

-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式)

-XX:+PrintGCDateStamps 输出Gc的时间戳（以日期的形式，如2013-0504T21:53:59.234+0800)

-XX;+PrintHeapAtGC 在进行Gc的前后打印出堆的信息

-Xloggc: …/ logs/gc.log 日志文件的输出路径

导出的日志可以使用工具来看

8.4.10 垃圾回收器的新发展

GC仍然处于飞速发展之中，目前的默认选项G1 Gc在不断的进行改进，很多我们原来认为的缺点，例如串行的Full Gc、card Table扫描的低效等，都已经被大幅改进，例如，JDK 10以后，Full GC已经是并行运行，在很多场景下，其表现还略优于Parallel Gc的并行Full GC实现。

即使是Serial GC，虽然比较古老，但是简单的设计和实现未必就是过时的，它本身的开销，不管是Gc相关数据结构的开销，还是线程的开销，都是非常小的，所以随着云计算的兴起，在Serverless等新的应用场景下，Serial GC找到了新的舞台。

比较不幸的是CMS GC，因为其算法的理论缺陷等原因，虽然现在还有非常大的用户群体，但在JDK9中已经被标记为废弃，并在JDK14版本中移除。

ZGC

ZGC与shenandoah目标高度相似，在尽可能对吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟。
《深入理解Java虚拟机》一书中这样定义ZGC: ZGC收集器是一款基Region内存布局的，（暂时）不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-压缩算法的，以低延迟为首要目标的一款垃圾收集器。

ZGC的工作过程可以分为4个阶段:并发标记-并发预备重分配-并发重分配-并发重映射等。

ZGC几乎在所有地方并发执行的，除了初始标记的是STW的。所以停顿时间几乎就耗费在初始标记上，这部分的实际时间是非常少的。