详解JVM虚拟机
上篇：内存与垃圾回收篇
第一章 JVM和Java体系架构
1.jvm前言
作为Java工程师的你曾被伤害过吗？你是否也遇到过这些问题？
-
运行着的线上系统突然卡死，系统无法访问，甚至直接OOM！
-
想解决线上JVM GC问题，但却无从下手。
-
新项目上线，对各种JVM参数设置一脸茫然，直接默认吧然后就GG了
-
每次面试之前都要重新背一遍JVM的一些原理概念性的东西，然而面试官却经常问你在实际项目中如何调优VM参数，如何解决GC、OOM等问题，一脸懵逼。
2.开发人员的病态
- 大部分Java开发人员，除了会在项目中使用到与Java平台相关的各种高精尖技术，对于Java技术的核心Java虚拟机了解甚少。
- 一些有一定工作经验的开发人员，打心眼儿里觉得SSM、微服务等上层技术才是重点，基础技术并不重要，这其实是一种本末倒置的“病态”。如果我们把核心类库的API比做数学公式的话，那么Java虚拟机的知识就好比公式的推导过程。
- 计算机系统体系对我们来说越来越远，在不了解底层实现方式的前提下，通过高级语言很容易编写程序代码。但事实上计算机并不认识高级语言
3.架构师在想什么
架构师每天都在思考什么？
- 应该如何让我的系统更快？
- 如何避免系统出现瓶颈？
知乎上有条帖子：应该如何看招聘信息，直通年薪50万+？
- 参与现有系统的性能优化，重构，保证平台性能和稳定性
- 根据业务场景和需求，决定技术方向，做技术选型
- 能够独立架构和设计海量数据下高并发分布式解决方案，满足功能和非功能需求
- 解决各类潜在系统风险，核心功能的架构与代码编写
- 分析系统瓶颈，解决各种疑难杂症，性能调优等
4.为什么学习jvm
- 面试的需要（BATJ、TMD，PKQ等面试都爱问）
- 中高级程序员必备技能：项目管理、调优的需求
- 追求极客的精神，比如：垃圾回收算法、JIT（即时编译器）、底层原理
5.Java VS C++
- 垃圾收集机制为我们打理了很多繁琐的工作，大大提高了开发的效率，但是，垃圾收集也不是万能的，懂得JVM内部的内存结构、工作机制，是设计高扩展性应用和诊断运行时问题的基础，也是Java工程师进阶的必备能力。
- C语言需要自己来分配内存和回收内存，Java全部交给JVM进行分配和回收。
6.TIOBE 排行榜
TIOBE 排行榜：https://www.tiobe.com/tiobe-index/
7.Java 生态圈
Java是目前应用最为广泛的软件开发平台之一。随着Java以及Java社区的不断壮大Java 也早已不再是简简单单的一门计算机语言了，它更是一个平台、一种文化、一个社区。
- 作为一个平台，Java虚拟机扮演着举足轻重的作用
- Groovy、Scala、JRuby、Kotlin等都是Java平台的一部分
- 作为一种文化，Java几乎成为了"开源"的代名词。
- 第三方开源软件和框架。如Tomcat、Struts，MyBatis，Spring等。
- 就连JDK和JVM自身也有不少开源的实现，如openJDK、Harmony。
- 作为一个社区，Java拥有全世界最多的技术拥护者和开源社区支持，有数不清的论坛和资料。从桌面应用软件、嵌入式开发到企业级应用、后台服务器、中间件，都可以看到Java的身影。其应用形式之复杂、参与人数之众多也令人咋舌。
8.Java的跨平台性
- 每个语言都需要转换成字节码文件，最后转换的字节码文件都能通过Java虚拟机进行运行和处理
- 随着Java7的正式发布，Java虚拟机的设计者们通过JSR-292规范基本实现在Java虚拟机平台上运行非Java语言编写的程序。
- Java虚拟机根本不关心运行在其内部的程序到底是使用何种编程语言编写的，它只关心“字节码”文件。也就是说Java虚拟机拥有语言无关性，并不会单纯地与Java语言“终身绑定”，只要其他编程语言的编译结果满足并包含Java虚拟机的内部指令集、符号表以及其他的辅助信息，它就是一个有效的字节码文件，就能够被虚拟机所识别并装载运行。
9.字节码
- 我们平时说的java字节码，指的是用java语言编译成的字节码。准确的说任何能在jvm平台上执行的字节码格式都是一样的。所以应该统称为：
jvm字节码。 - 不同的编译器，可以编译出相同的字节码文件，字节码文件也可以在不同的JVM上运行。
- Java虚拟机与Java语言并没有必然的联系，它只与特定的二进制文件格式——Class文件格式所关联，Class文件中包含了Java虚拟机指令集（或者称为字节码、Bytecodes）和符号表，还有一些其他辅助信息。
10.多语言混合编程
Java平台上的多语言混合编程正成为主流，通过特定领域的语言去解决特定领域的问题是当前软件开发应对日趋复杂的项目需求的一个方向。- 试想一下，在一个项目之中，并行处理用Clojure语言编写，展示层使用JRuby/Rails，中间层则是Java，每个应用层都将使用不同的编程语言来完成，而且，接口对每一层的开发者都是透明的，
各种语言之间的交互不存在任何困难，就像使用自己语言的原生API一样方便，因为它们最终都运行在一个虚拟机之上。 - 对这些运行于Java虚拟机之上、Java之外的语言，来自系统级的、底层的支持正在迅速增强，以JSR-292为核心的一系列项目和功能改进（如DaVinci Machine项目、Nashorn引擎、InvokeDynamic指令、java.lang.invoke包等），
推动Java虚拟机从"Java语言的虚拟机"向"多语言虚拟机"的方向发展。
11.自己写个jvm
- Java虚拟机非常复杂，要想真正理解它的工作原理，最好的方式就是自己动手编写一个！
- 自己动手写一个Java虚拟机，难吗？
- 天下事有难易乎？为之，则难者亦易矣；不为，则易者亦难矣
12.Java的重大事件
- 1990年，在Sun计算机公司中，由Patrick Naughton、MikeSheridan及James Gosling领导的小组Green Team，开发出的新的程序语言，命名为Oak，后期命名为Java
- 1995年，Sun正式发布Java和HotJava产品，Java首次公开亮相。
- 1996年1月23日Sun Microsystems发布了JDK 1.0。
- 1998年，JDK1.2版本发布。同时，Sun发布了JSP/Servlet、EJB规范，以及将Java分成了J2EE、J2SE和J2ME。这表明了Java开始向企业、桌面应用和移动设备应用3大领域挺进。
- 2000年，JDK1.3发布，Java HotSpot Virtual Machine正式发布，成为Java的默认虚拟机。
- 2002年，JDK1.4发布，古老的Classic虚拟机退出历史舞台。
- 2003年年底，Java平台的scala正式发布，同年Groovy也加入了Java阵营。
- 2004年，JDK1.5发布。同时JDK1.5改名为JavaSE5.0。
- 2006年，JDK6发布。
- 同年，==Java开源并建立了OpenJDK。==顺理成章，Hotspot虚拟机也成为了OpenJDK中的默认虚拟机。
- 2007年，Java平台迎来了新伙伴Clojure。
- 2008年，oracle收购了BEA，得到了JRockit虚拟机。
- 2009年，Twitter宣布把后台大部分程序从Ruby迁移到Scala，这是Java平台的又一次大规模应用。
- 2010年，Oracle收购了Sun，获得Java商标和最真价值的HotSpot虚拟机。 此时，Oracle拥有市场占用率最高的两款虚拟机HotSpot和JRockit，并计划在未来对它们进行整合：HotRockit
- 2011年，JDK7发布。在JDK1.7u4中，正式启用了新的垃圾回收器G1。
- 2017年，JDK9发布。将G1设置为默认GC，替代CMS
- 同年，IBM的J9开源，形成了现在的Open J9社区
- 2018年，Android的Java侵权案判决，Google赔偿Oracle计88亿美元
- 同年，Oracle宣告JavagE成为历史名词JDBC、JMS、Servlet赠予Eclipse基金会
- 同年，JDK11发布，LTS版本的JDK，发布革命性的ZGC，调整JDK授权许可
- 2019年，JDK12发布，加入RedHat领导开发的Shenandoah GC
13.虚拟机介绍
13.1 虚拟机概念
所谓虚拟机（Virtual Machine），就是一台虚拟的计算机。它是一款软件，用来执行一系列虚拟计算机指令。大体上，虚拟机可以分为系统虚拟机和程序虚拟机。
- 大名鼎鼎的Virtual Box，VMware就属于系统虚拟机，它们完全是对物理计算机的仿真，提供了一个可运行完整操作系统的软件平台。
- 程序虚拟机的典型代表就是
Java虚拟机，它专门为执行单个计算机程序而设计，在Java虚拟机中执行的指令我们称为Java字节码指令。 - 无论是系统虚拟机还是程序虚拟机，在上面运行的软件都被限制于虚拟机提供的资源中。
13.2 Java虚拟机
- Java虚拟机是一台执行Java字节码的虚拟计算机，它拥有独立的运行机制，其运行的Java字节码也未必由Java语言编译而成。
- JVM平台的各种语言可以共享Java虚拟机带来的跨平台性、优秀的垃圾回器，以及可靠的即时编译器。
Java技术的核心就是Java虚拟机（JVM，Java Virtual Machine），因为所有的Java程序都运行在Java虚拟机内部。- Java虚拟机就是二进制字节码的运行环境，负责装载字节码到其内部，解释/编译为对应平台上的机器指令执行。每一条Java指令，Java虚拟机规范中都有详细定义，如怎么取操作数，怎么处理操作数，处理结果放在哪里。
特点
一次编译，到处运行自动内存管理自动垃圾回收功能
14.jvm的位置
JVM是运行在操作系统之上的，它与硬件没有直接的交互
JVM是运行在操作系统之上的，它与硬件没有直接的交换。
Java的体系结构
15.jvm的整体结构
HotSpot VM是目前市面上高性能虚拟机的代表作之一。- 它采用解释器与即时编译器并存的架构。
- 在今天，Java程序的运行性能早已脱胎换骨，已经达到了可以和C/C++程序一较高下的地步。
- 执行引擎包含三部分：
解释器，即时编译器，垃圾回收器
多个线程共享 方法区 和堆
每个线程都有独有一份的栈和程序计数器和本地方法栈
16.Java代码执行流程
17.JVM架构模型
Java编译器输入的指令流基本上是一种基于栈的指令集架构，另外一种指令集架构则是基于寄存器的指令集架构。具体来说：这两种架构之间的区别：
- 基于栈式架构的特点
- 设计和实现更简单，适用于资源受限的系统
- 避开了寄存器的分配难题：使用零地址指令方式分配
- 指令流中的指令大部分是零地址指令，其执行过程依赖于
操作栈。指令集更小，编译器容易实现 - 不需要硬件支持，可移植性更好，更好
实现跨平台
- 基于寄存器架构的特点
- 典型的应用是x86的二进制指令集：比如传统的PC以及Android的Davlik虚拟机。
- 指令集架构则
完全依赖硬件，与硬件的耦合度高，`可移植性差 性能优秀和执行更高效- 花费更少的指令去完成一项操作
- 在大部分情况下，
基于寄存器架构的指令集往往都以一地址指令、二地址指令和三地址指令为主，而基于栈式架构的指令集却是以零地址指令为主
17.1 两种架构的举例
同样执行2+3这种逻辑操作，其指令分别如下：
-
基于栈的计算流程（以Java虚拟机为例）
iconst_2 //常量2入栈
istore_1
iconst_3 // 常量3入栈
istore_2
iload_1
iload_2
iadd //常量2/3出栈，执行相加
istore_0 // 结果5入栈
-
基于寄存器的计算流程
mov eax,2 //将eax寄存器的值设为1
add eax,3 //使eax寄存器的值加3
17.2 反编译字节码文件
反编译使用指令
javap -v StackStruTest.class
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=4, args_size=1
0: iconst_2 // 将常量 2 压入栈中
1: istore_1 // 将常量 2 保存至变量 i 中
2: iconst_3 // 将常量 3 压入栈中
3: istore_2 // 将常量 3 保存至变量 j 中
4: iload_1 // 加载变量 i
5: iload_2 // 加载变量 j
6: iadd // 执行累加操作
7: istore_3 // 加法结果保存在变量 k 中
8: return
LineNumberTable:
line 10: 0
line 11: 2
line 12: 4
line 13: 8
LocalVariableTable:
Start Length Slot Name Signature
0 9 0 args [Ljava/lang/String;
2 7 1 i I
4 5 2 j I
8 1 3 k I
}
17.3 总结
- 由于跨平台性的设计，Java的指令都是根据栈来设计的。 不同平台CPU架构不同，所以不能设计为基于寄存器的。优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令
- 时至今日，尽管嵌入式平台已经不是Java程序的主流运行平台了（准确来说应该是HotSpot VM的宿主环境已经不局限于嵌入式平台了），那么为什么不将架构更换为基于寄存器的架构呢？
- 因为基于栈的架构跨平台性好、指令集小，虽然相对于基于寄存器的架构来说，基于栈的架构编译得到的指令更多，执行性能也不如基于寄存器的架构好，但考虑到其跨平台性与移植性，我们还是选用栈的架构
栈：跨平台性、指令集小、指令多；执行性能比寄存器差
18.jvm生命周期
- 虚拟机的启动
- Java虚拟机的启动是通过
引导类加载器（bootstrap class loader）创建一个初始类（initial class）来完成的，这个类是由虚拟机的具体实现指定的。
- Java虚拟机的启动是通过
- 虚拟机的执行
- 一个运行中的Java虚拟机有着一个清晰的任务：执行Java程序
- 程序开始执行时他才运行，程序结束时他就停止
执行一个所谓的Java程序的时候，真真正正在执行的是一个叫做Java虚拟机的进程
- 虚拟机的退出
- 程序正常执行结束
- 程序在执行过程中遇到了异常或错误而异常终止
- 由于操作系统用现错误而导致Java虚拟机进程终止
- 某线程调用Runtime类或
System类的exit( )方法，或Runtime类的halt( )方法，并且Java安全管理器也允许这次exit( )或halt( )操作。 - 除此之外，JNI（Java Native Interface）规范描述了用JNI Invocation API来加载或卸载 Java虚拟机时，Java虚拟机的退出情况。
19.理解执行引擎
第二章 - 类加载器子系统
1.内存结构概述
假设我们想自己手写一个Java虚拟机的话，必须考虑哪些结构
- 类加载器
- 执行引擎
2.类加载子系统
2.1 类加载器子系统的作用
类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。- ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。
载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）
2.2 类加载器ClassLoader角色
- class file存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
- class file加载到JVM中，被称为DNA元数据模板，放在方法区。
- 在==.class文件== –> JVM –> 最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader），扮演一个快递员的角色。
2.3 类的加载过程
/**
* @author Jc
* @create 2021-11-21 10:12 上午
*/
public class HelloLoader {
public static void main(String[] args) {
System.out.println("谢谢ClassLoader加载我....");
System.out.println("你的大恩大德，我下辈子再报！");
}
}
它的加载过程是怎么样的呢?
- 执行 main( ) 方法（静态方法）就需要先加载承载类 HelloLoader
- 加载成功，则进行链接、初始化等操作，完成后调用 HelloLoader 类中的静态方法 main
- 加载失败则抛出异常
- 完整的流程图如下所示：
加载 --> 链接（验证 --> 准备 --> 解析） --> 初始化(这一整条流程都是加载)
2.3.1 加载(Loading)阶段
加载
- 通过一个类的全限定名获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
加载
.class文件的方式
- 从本地系统中直接加载
- 通过网络获取，典型场景：Web Applet
- 从zip压缩包中读取，成为日后
jar、war格式的基础 - 运行时计算生成，使用最多的是：
动态代理技术 - 由其他文件生成，典型场景：JSP应用从专有数据库中提取
.class文件，比较少见 - 从加密文件中获取，典型的
防Class文件被反编译的保护措施
2.3.2 链接(Linking)阶段
链接分为三个子阶段：
验证 --> 准备 --> 解析
验证(Verify)
- 目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全
- 主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。
- 使用
BinaryViewer查看字节码文件，其开头均为CA FE BA BE，如果出现不合法的字节码文件，那么将会验证不通过
准备(Prepare)
- 为类变量分配内存并且设置该类变量的
默认初始值，即零值 这里不包含用final修饰的static，因为final在编译的时候就会分配好了默认值，准备阶段会显式初始化- 注意：
这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中
举例：
变量a在准备阶段会赋初始值，但不是1，而是0，在初始化阶段会被赋值为 1
public class HelloApp {
private static int a = 1; //prepare：a = 0 ---> initial : a = 1
public static void main(String[] args) {
System.out.println(a);
}
}
解析(Resolve)
- 将常量池内的符号引用转换为直接引用的过程
- 事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行
- 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄
- 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info等
符号引用
- 反编译 class 文件后可以查看符号引用
2.3.3 初始化(Initialization)阶段
- 初始化阶段就是执行类构造器方法()的过程
- 此方法不需定义，是
javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。也就是说，当我们代码中包含static变量的时候，就会有( )方法；如果当前类不存在static变量，那么它的字节码文件是不会存在( ) - ()方法中的指令按语句在源文件中出现的顺序执行
- ()不同于类的构造器。（关联：构造器是虚拟机视角下的()）
- 若该类具有父类，JVM会保证子类的()执行前，父类的()已经执行完毕
- 虚拟机必须保证一个类的()方法在多线程下被同步加锁
IDEA安装 JClassLib 插件
显示前记得运行下 （先生成.class文件）
也可以重新运行
当我们代码中包含static变量的时候，就会有clinit方法
/**
* @Description:
* @author: JC
* @date: 2021/11/21 9:49
*/
public class ClassInitTest {
private static int num = 1;
static {
num = 3;
number = 20;
System.out.println(num);
//System.out.println(number); 报错： 非法的前项引用。
}
private static int number = 10 ; // linking之prepare：number = 0-->initial:20-->10
public static void main(String[] args) {
System.out.println(ClassInitTest.class);
System.out.println(number);
}
}
- 静态变量 number 的值变化过程如下
- 准备阶段时：默认初始化 0
- 执行静态代码块：20
- 执行静态变量初始化：10
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NmTk1BnJ-1684071932747)(JVM.assets/image-20211121100510055.png)]
如果当前类不存在static变量，那么它的字节码文件是不会存在
<clinit>( )
public class ClinitTest {
// 任何一个类声明以后，内部至少存在一个类的构造器
// 对应过来就是一个<init>
private int a = 1;
public static void main(String[] args) {
int b = 2;
}
}
若该类具有父类，JVM会保证子类的
<clinit>()执行前，父类的<clinit>()已经执行完毕
public class ClinitTest1 {
static class Father{
public static int A = 1;
static{
A = 2;
}
}
static class Son extends Father{
public static int B = A;
}
public static void main(String[] args) {
//加载Father类，其次加载Son类。
System.out.println(Son.B); //2
}
}
- 如上代码，加载流程如下：
- 首先，执行 main( ) 方法需要加载 ClinitTest1 类
- 获取 Son.B 静态变量，需要加载 Son 类
- Son 类的父类是 Father 类，所以需要先执行 Father 类的加载，再执行 Son 类的加载
虚拟机必须保证一个类的
<clinit>()方法在多线程下被同步加锁
public class DeadThreadTest {
public static void main(String[] args) {
Runnable r = () -> {
System.out.println(Thread.currentThread().getName() + "开始");
DeadThread dead = new DeadThread();
System.out.println(Thread.currentThread().getName() + "结束");
};
Thread t1 = new Thread(r, "线程1");
Thread t2 = new Thread(r, "线程2");
t1.start();
t2.start();
}
}
class DeadThread {
static {
if (true) {
System.out.println(Thread.currentThread().getName() + "初始化当前类");
while (true) {
}
}
}
}
- 程序卡死，分析原因：
- 两个线程同时去加载 DeadThread 类，而 DeadThread 类中静态代码块中有一处死循环
- 先加载 DeadThread 类的线程抢到了同步锁，然后在类的静态代码块中执行死循环，而另一个线程在等待同步锁的释放
- 所以无论哪个线程先执行 DeadThread 类的加载，另外一个类也不会继续执行
3.类加载器的分类
- JVM支持两种类型的类加载器 。分别为
引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader） - 从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将
所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器 - 无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tMRg22VZ-1684071932748)(JVM.assets/image-20211121103717673.png)]
为什么 ExtClassLoader 和 AppClassLoader 都属于自定义加载器
- 规范定义：所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
- ExtClassLoader 继承树
- AppClassLoader 继承树
/**
* 注意：getParent() 只是获取上层的加载器，并不是继承关系
*/
public class ClassLoaderTest {
public static void main(String[] args) {
//获取系统类加载器
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(systemClassLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2
//获取其上层：扩展类加载器
ClassLoader extClassLoader = systemClassLoader.getParent();
System.out.println(extClassLoader); //sun.misc.Launcher$ExtClassLoader@61bbe9ba
//获取其上层：获取不到引导类加载器
ClassLoader bootstrapClassLoader = extClassLoader.getParent();
System.out.println(bootstrapClassLoader); //null
//对于用户自定义类来说：默认使用系统类加载器进行加载
ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
System.out.println(classLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2
//String类使用引导类加载器进行加载的。--> Java的核心类库都是使用引导类加载器进行加载的。
ClassLoader classLoader1 = String.class.getClassLoader();
System.out.println(classLoader1); //null
}
}
- 我们尝试获取引导类加载器，获取到的值为
null，这并不代表引导类加载器不存在，因为引导类加载器是由 C/C++ 语言构成的，所以我们是获取不到 - 两次获取
系统类加载器的值都相同：sun.misc.Launcher$AppClassLoader@18b4aac2 ，这说明系统类加载器是全局唯一的
3.1 虚拟机自带的加载器
3.1.1 启动类加载器(引导类加载器)
启动类加载器（ 引导类加载器，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、sun等开头的类
3.1.2 扩展类加载器
扩展类加载器（Extension ClassLoader）
Java语言编写，由sun.misc.Launcher$ExtClassLoader实现- 派生于
ClassLoader类 - 父类加载器为启动类加载器
- 从
java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的 jre / lib / ext子目录（扩展目录）下加载类库。如果用户创建的 JAR 放在此目录下，也会自动由扩展类加载器加载
3.1.3 系统类加载器
应用程序类加载器（系统类加载器，AppClassLoader）
Java语言编写，由sun.misc.LaunchersAppClassLoader实现- 派生于ClassLoader类
- 父类加载器为扩展类加载器
- 它负责加载环境变量
classpath或系统属性java.class.path指定路径下的类库 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载的- 通过
classLoader.getSystemclassLoader( )方法可以获取到该类加载器
代码说明
public class ClassLoaderTest1 {
public static void main(String[] args) {
System.out.println("**********启动类加载器**************");
//获取BootstrapClassLoader能够加载的api的路径
URL[] urLs = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (URL element : urLs) {
System.out.println(element.toExternalForm());
}
//从上面的路径中随意选择一个类,来看看他的类加载器是什么:引导类加载器
ClassLoader classLoader = Provider.class.getClassLoader();
System.out.println(classLoader); //null
System.out.println("***********扩展类加载器*************");
String extDirs = System.getProperty("java.ext.dirs");
for (String path : extDirs.split(";")) {
System.out.println(path);
}
//从上面的路径中随意选择一个类,来看看他的类加载器是什么:扩展类加载器
ClassLoader classLoader1 = CurveDB.class.getClassLoader();
System.out.println(classLoader1);//sun.misc.Launcher$ExtClassLoader@1540e19d
}
}
System.out.println(classLoader); //null 再次证明我们无法获取到启动类加载器
加载器的执行流程图
3.2 用户自定义类加载器
在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。
为什么需要自定义类加载器？
- 那为什么还需要自定义类加载器？
- 隔离加载类
- 修改类加载的方式
- 扩展加载源
- 防止源码泄露
如何自定义类加载器？
- 开发人员可以通过
继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求 - 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass( )方法，从而实现自定义的类加载类，但是在JDK1.2之后已
不再建议用户去覆盖loadClass( )方法，而是建议把自定义的类加载逻辑写在findclass( )方法中 - 在编写自定义类加载器时，如果没有太过于复杂的需求，可以
直接继承URIClassLoader类，这样就可以避免自己去编写findclass( )方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。
代码举例：
/**
* 自定义用户类加载器
*/
public class CustomClassLoader extends ClassLoader {
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] result = getClassFromCustomPath(name);
if (result == null) {
throw new FileNotFoundException();
} else {
return defineClass(name, result, 0, result.length);
}
} catch (FileNotFoundException e) {
e.printStackTrace();
}
throw new ClassNotFoundException(name);
}
private byte[] getClassFromCustomPath(String name) {
//从自定义路径中加载指定类:细节略
//如果指定路径的字节码文件进行了加密，则需要在此方法中进行解密操作。
return null;
}
public static void main(String[] args) {
CustomClassLoader customClassLoader = new CustomClassLoader();
try {
Class<?> clazz = Class.forName("One", true, customClassLoader);
Object obj = clazz.newInstance();
System.out.println(obj.getClass().getClassLoader());
} catch (Exception e) {
e.printStackTrace();
}
}
}
3.3 关于 ClassLoader
- ClassLoader类，它是一个
抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）
| 方法名称 | 描述 |
|---|---|
| getParent( ) | 返回该类加载器的超类加载器 |
| loadClass(String name) | 加载名称为name的类，返回结果为java.lang.Class类的实例 |
| findClass(String name) | 查找名称为name的类，返回结果为java.lang.Class类的实例 |
| findLoadedClass(String name) | 查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例 |
| defineClass(String name,byte[ ] b,int len) | 把字节数组b中的内容转换为一个Java类，返回结果为java.lang.Class类的实例 |
| resolveClass(Class<?> c) | 连接指定的一个Java类 |
- sun.misc.Launcher 它是一个java虚拟机的入口应用
3.3.1 获取 ClassLoader 的途径
| 方式一：获取当前类的ClassLoader |
|---|
| classzz.getClassLoader（） |
| 方式二：获取当前线程上下文的ClassLoader |
| Thread.currentThread（）.getContextClassLoader() |
| 方式三：获取系统的ClassLoader |
| ClassLoader.getSystemClassLoader（） |
| 方式四：获取调用者的ClassLoader |
| DriverManager.getCallerClassLoader（） |
public class ClassLoaderTest2 {
public static void main(String[] args) {
try {
//1.Class.forName().getClassLoader()
ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
System.out.println(classLoader); // String 类由启动类加载器加载，我们无法获取
//2.Thread.currentThread().getContextClassLoader()
ClassLoader classLoader1 = Thread.currentThread().getContextClassLoader();
System.out.println(classLoader1); //sun.misc.Launcher$AppClassLoader@18b4aac2
//3.ClassLoader.getSystemClassLoader().getParent()
ClassLoader classLoader2 = ClassLoader.getSystemClassLoader().getParent();
System.out.println(classLoader2); //sun.misc.Launcher$ExtClassLoader@1540e19d
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
4.双亲委派机制(面试常问)
4.1 双亲委派机制原理
- Java虚拟机对 class 文件采用的是
按需加载的方式，也就是说当需要使用该类时才会将它的 class 文件加载到内存中生成 class 对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式- 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个
请求委托给父类的加载器去执行； - 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达
顶层的启动类加载器。 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式- 父类加载器一层一层往下分配任务，如果子类加载器能加载，则加载此类，如果将加载任务分配至系统类加载器也无法加载此类，则抛出异常
- 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个
4.2 双亲委派机制代码示例
⭐️ 举例一：
我们自己定义一个java.lang包，在其下面定义一个String类，里面声明了静态代码块
/**
* @Description:
* @author: JC
* @date: 2021/11/21 13:04
*/
public class StringTest {
public static void main(String[] args) {
String str = new String();
System.out.println("hell,xiaoxin.com");
}
}
在一个测试类中加载String类，看看加载的String类是JDK自带的，还是我们自己编写的
public class StringTest {
public static void main(String[] args) {
String str = new String();
System.out.println("hell,xiaoxin.com");
}
}
结果：程序并没有输出我们静态代码块中的内容，可见仍然加载的是 JDK 自带的 String 类
结论: 因为双亲委派机制，每级加载器会先往上级加载器看它是否能处理（当上级无法处理就自己处理），往上委托， 最终交给引导类加载器，又因在java包引导类加载器刚好可以处理 ，所以还是原本的String，只有用系统类加载器 加载才是我们自己创建的String
⭐️举例二：
在我们自己定义的 String 类中整个 main( ) 方法
public class String {
static {
System.out.println("我是自定义的String类的静态代码块");
}
//错误: 在类 java.lang.String 中找不到 main 方法
public static void main(String[] args) {
System.out.println("hello,String");
}
}
原因：由于双亲委派机制，我们的String类是由引导类加载器加载的，而引导类加载器并没有main方法，所以会报错
举例三：
SPI接口是由引导类加载器加载的，接口具体的实现类是由线程上下文类加载器加载的，而线程上下文类加载器就是系统类加载器，所以我们在加载的时候，会先进行双亲委派，在引导类加载器加载SPI核心类，然后加载SPI接口，最后在反向委托，通过系统类加载器进行实现类 jdbc.jar 的加载
举例四：
package java.lang;
/**
* @author Jc
* @create 2020-11-21 13:36 下午
*/
public class ShkStart {
public static void main(String[] args) {
System.out.println("hello!");
}
}
出于保护机制，java.lang 包下不允许我们自定义类
4.3 双亲委派机制的优势
- 避免类的重复加载
- 保护程序安全，防止核心API被随意篡改
- 自定义类：java.lang.String 没有调用
- 自定义类：java.lang.ShkStart（报错：阻止创建 java.lang开头的类）
5.沙箱安全机制
- 自定义String类时：在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java.lang.String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的String类。
- 这样可以保证对java核心源代码的保护，这就是
沙箱安全机制。
6.其他
如何判断两个class对象是否相同？
- 在JVM中表示两个class对象是否为同一个类存在两个必要条件：
- 类的完整类名必须一致，包括
包名 - 加载这个类的
ClassLoader（指ClassLoader实例对象）必须相同
- 类的完整类名必须一致，包括
- 换句话说，在JVM中，即使这两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的 ClassLoader 实例对象不同，那么这两个类对象也是不相等的
对类加载器的引用
- JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的
- 如果一个类型是由用户类加载器加载的，那么
JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中 - 当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的
类的主动使用和被动使用
Java程序对类的使用方式分为：主动使用 和 被动使用。
- 主动使用，又分为七种情况：
- 创建类的实例
- 访问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射（ 比如：Class.forName(“cn.sxt.Test”) )
- 初始化一个类的子类
- Java虚拟机启动时被标明为启动类的类
- JDK7开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果REF_getStatic、REF putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化
- 除了以上七种情况，其他使用Java类的方式都被看作是对类的
被动使用，都不会导致类的初始化，即不会执行初始化阶段（不会调用 clinit( ) 方法和 init( ) 方法）
第三章 - 运行时数据区概述及线程
1.前言
本节主要讲的是
运行时数据区，也就是下图这部分，它是在类加载完成后的阶段
当我们通过前面的：类的加载 --> 验证 --> 准备 --> 解析 --> 初始化，这几个阶段完成后，就会用到执行引擎对我们的类进行使用，同时执行引擎将会使用到我们的运行时数据区
比如大厨做饭，我们把大厨后面的东西（
切好的菜，刀，调料），比作是运行时数据区。而厨师可以类比于执行引擎，将通过准备的东西制作成精美的菜品
2.运行时数据区结构
2.1 运行时数据区与内存
内存
- 内存是非常重要的系统资源，是硬盘和CPU的中间仓库及桥梁，承载着操作系统和应用程序的实时运行。JVM内存布局规定了Java在运行过程中
内存申请、分配、管理的策略，保证了JVM的高效稳定运行。 不同的JVM对于内存的划分方式和管理机制存在着部分差异。结合JVM虚拟机规范，来探讨一下经典的JVM内存布局。- 我们通过磁盘或者网络IO得到的数据，都需要先加载到内存中，然后CPU从内存中获取数据进行读取，也就是说内存充当了CPU和磁盘之间的桥梁
运行时数据区的完整图
说明：方法区在JVM规范中是一个逻辑概念，由虚拟机自己进行具体实现，jdk7和以前的版本使用的是堆上的永久代实现的方法区，而在jdk8及以后使用的是元数据区实现方法区
2.2 线程的内存空间
Java虚拟机定义了若干种程序运行期间会使用到的运行时数据区，其中有一些会随着虚拟机启动而创建，随着虚拟机的退出而销毁。另外一些则是与线程一一对应的，这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。
灰色的为单独线程私有的，红色的为多个线程共享的。即：
- 线程独有：独立包括
程序计数器、栈、本地方法栈 - 线程间共享：
堆、堆外内存（永久代或元空间、代码缓存）
关于线程间共享的说明
每个JVM只有一个Runtime实例。即为运行时环境，相当于内存结构的中间的那个框框：运行时环境。
3.线程
3.1 JVM线程
- 线程是一个程序里的运行单元。
JVM允许一个应用有多个线程并行的执行 在Hotspot JVM里，每个线程都与操作系统的本地线程直接映射- 当一个Java线程准备好执行以后，此时一个操作系统的本地线程也同时创建。Java线程执行终止后，本地线程也会回收
- 操作系统负责将线程安排调度到任何一个可用的CPU上。
一旦本地线程初始化成功，它就会调用Java线程中的run( )方法 - 如果一个线程抛异常，并且该线程是进程中最后一个是守护线程，那么进程将停止
3.2 JVM系统线程
- 如果你使用 jconsole 或者是任何一个调试工具，都能看到在后台有许多线程在运行。
这些后台线程不包括调用public static void main(String [ ])的main线程以及所有由这个main方法自己创建的线程。- 这些主要的后台系统线程在Hotspot JVM里主要是以下几个：
- 虚拟机线程：这种线程的操作是需要JVM达到安全点才会出现。这些操作必须在不同的线程中发生的原因是他们都需要JVM达到安全点，这样堆才不会变化。这种线程的执行类型括"stop-the-world"的垃圾收集，线程栈收集，线程挂起以及偏向锁撤销
- 周期任务线程：这种线程是时间周期事件的体现（比如中断），他们一般用于周期性操作的调度执行
- GC线程：这种线程对在JVM里不同种类的垃圾收集行为提供了支持（重点）
- 编译线程：这种线程在运行时会将字节码编译成 本地代码
- 信号调度线程：这种线程接收信号并发送给JVM，在它内部通过调用适当的方法进行处理
第四章 - 程序计数器 （PC寄存器）
1.PC 寄存器介绍
- JVM中的程序计数寄存器（Program Counter Register），Register的命名源于CPU的寄存器，寄存器存储指令相关的现场信息。CPU只有把数据装载到寄存器才能够运行。
- 这里，并非是广义上所指的物理寄存器，或许将其翻译为PC计数器（或指令计数器）会更加贴切（也称为程序钩子），并且也不容易引起一些不必要的误会。
JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟。
2.PC 寄存器的作用
PC寄存器用来存储指向下一条指令的地址，也就是即将要执行的指令代码。由执行引擎读取下一条指令，并执行该指令。
- 它是一块很小的内存空间，几乎可以忽略不记。也是运行速度最快的存储区域。
在JVM规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的生命周期保持一致。- 任何时间一个线程都只有一个方法在执行，也就是所谓的
当前方法。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址；或者，如果是在执行native方法，则是未指定值（undefined）。
- 它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成
- 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
- 它是唯一一个在Java虚拟机规范中没有规定任何
OutofMemoryError情况的区域。
3.代码示例
public class PCRegisterTest {
public static void main(String[] args) {
int i = 10;
int j = 20;
int k = i + j;
String s = "abc";
System.out.println(i);
System.out.println(k);
}
}
使用反编译：javap -v PCRegisterTest.class
左边的数字代表指令地址 (偏移地址)，即 PC 寄存器中可能存储的值，然后执行引擎读取 PC 寄存器中的值，并执行该指令
4.两个常见面试题
使用 PC寄存器 存储字节码指令地址有什么用呢？ 或者问
为什么使用 PC寄存器 来记录当前线程的执行地址呢？
- 因为线程是一个个的顺序执行流，CPU需要不停的切换各个线程，这时候切换回来以后，就得知道接着从哪开始继续执行
- JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令
PC寄存器为什么被设定为私有的？
- 我们都知道所谓的多线程在一个特定的时间段内只会执行其中某一个线程的方法，CPU会不停地做任务切换，这样必然导致经常中断或恢复，如何保证分毫无差呢？
为了能够准确地记录各个线程正在执行的当前字节码指令地址，最好的办法自然是为每一个线程都分配一个PC寄存器，这样一来各个线程之间便可以进行独立计算，从而不会出现相互干扰的情况。- 由于CPU时间片轮限制，众多线程在并发执行过程中，任何一个确定的时刻，一个处理器或者多核处理器中的一个内核，只会执行某个线程中的一条指令。
- 这样必然导致经常中断或恢复，如何保证分毫无差呢？每个线程在创建后，都会产生自己的程序计数器和栈帧，程序计数器在各个线程之间互不影响。
5.CPU时间片
- CPU时间片即CPU分配给各个程序的时间，每个线程被分配一个时间段，称作它的时间片。
- 在宏观上：我们可以同时打开多个应用程序，每个程序并行不悖，同时运行。
- 但在微观上：由于只有一个CPU，一次只能处理程序要求的一部分，如何处理公平，一种方法就是引入时间片，每个程序轮流执行。
简单一句话：宏观并行，微观并发
第五章 - 虚拟机栈
1.虚拟机栈概述
1.1 虚拟机栈出现的背景
- 由于跨平台性的设计，Java的指令都是根据栈来设计的。不同平台CPU架构不同，所以不能设计为基于寄存器的。
优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令。
1.2 内存中的栈与堆
首先栈是运行时的单位，而堆是存储的单位
栈解决程序的运行问题，即程序如何执行，或者说如何处理数据。堆解决的是数据存储的问题，即数据怎么放，放哪里
1.3 虚拟机栈的基本内容
Java虚拟机栈是什么？
Java虚拟机栈（Java Virtual Machine Stack），早期也叫Java栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应着一次次的Java方法调用
- 栈是线程私有的
- 一个方法对应一个栈帧的入栈和出栈
举例：
/**
* @author JC
* @create 2021-11-21 15:16 下午
*/
public class StackTest {
public static void main(String[] args) {
StackTest test = new StackTest();
test.methodA();
}
public void methodA() {
int i = 10;
int j = 20;
methodB();
}
public void methodB() {
int k = 30;
int m = 40;
}
}
声明周期
生命周期和线程一致，也就是线程结束了，该虚拟机栈也销毁了
作用
主管Java程序的运行，它保存方法的局部变量（8 种基本数据类型、对象的引用地址）、部分结果，并参与方法的调用和返回。
- 局部变量 VS 成员变量（属性）
- 基本数据类型变量 VS 引用类型变量（类、数组、接口）
1.3.1 虚拟机栈的特点
栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器。
- JVM直接对Java栈的操作只有两个：
- 每个方法执行，伴随着进栈（入栈、压栈）
- 执行结束后的出栈工作
- 对于栈来说不存在垃圾回收 (GC) 问题（栈 存在溢出的情况）
1.3.2 虚拟机栈的异常
面试题：栈中可能出现的异常
- Java 虚拟机规范允许
Java栈的大小是动态的或者是固定不变的。- 如果采用固定大小的Java虚拟机栈，那每一个线程的Java虚拟机栈容量可以在线程创建的时候独立选定。
- 如果线程请求分配的栈容量超过Java虚拟机栈允许的最大容量，Java虚拟机将会抛出一个
StackoverflowError 异常。简称：栈溢出 - 如果Java虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那Java虚拟机将会抛出一个
OutOfMemoryError 异常。
栈异常演示
/**
* @Description:演示栈中的异常：StackOverflowError
* @author jC
* @create 2021-11-21 15:10 下午
*/
public class StackError {
public static void main(String[] args) {
main(args);
}
}
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AJo1d0ox-1684071932752)(JVM.assets/image-20211121160509788.png)]
1.3.3 设置栈内存大小
- 我们可以使用参数
-Xss选项来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度。
-Xss1024m // 栈内存为 1024MBS
-Xss1024k // 栈内存为 1024KB
- 设置线程的最大栈空间：256KB
/**
* 演示栈中的异常：StackOverflowError
*
* 默认情况下：count = 11416
* 设置栈的大小：-Xss256k count = 2467
* @author: JC
* @date: 2021/11/21 16:06
*/
public class StackError {
private static int count = 1;
public static void main(String[] args) {
System.out.println(count);
count++;
main(args);
}
}
说明：可以看到，没有设置栈内存大小的时候，程序可以递归11416次
当我们缩小栈内存大小，设置为256k时，程序递归2467次
2.栈的存储单位
栈中存储什么？
- 每个线程都有自己的栈，栈中的数据都是以
栈帧（Stack Frame）为基本单位存储的 - 在这个线程上正在执行的每个方法都各自对应一个栈帧（Stack Frame）。
一个方法的执行对应一个栈帧的入栈，一个方法的执行结束对应一个栈帧的出栈
- 栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息。
2.1 栈的运行原理
- JVM直接对Java栈的操作只有两个，就是对栈帧的
压栈和出栈，遵循先进后出（后进先出）原则 - 在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的，这个栈帧被称为
当前栈帧（Current Frame）- 与当前栈帧相对应的方法就是
当前方法（Current Method） - 定义这个方法的类就是
当前类（Current Class）
- 与当前栈帧相对应的方法就是
- 执行引擎运行的所有字节码指令只针对当前栈帧进行操作。
- 如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为
新的当前帧。
代码举例
/**
* @author Jc
* @create 2021-11-21 16:12 下午
*/
public class StackFrameTest {
public static void main(String[] args) {
StackFrameTest test = new StackFrameTest();
test.method1();
}
public void method1() {
System.out.println("method1()开始执行...");
method2();
System.out.println("method1()执行结束...");
}
public int method2() {
System.out.println("method2()开始执行...");
int i = 10;
int m = (int)method3();
System.out.println("method2()即将结束...");
return i + m;
}
public double method3() {
System.out.println("method3()开始执行...");
double j = 20.0;
System.out.println("method3()即将结束...");
return j;
}
}
method1()开始执行...
method2()开始执行...
method3()开始执行...
method3()即将结束...
method2()即将结束...
method1()执行结束...
-
不同线程中所包含的栈帧是
不允许存在相互引用的，即不可能在一个栈帧之中引用另外一个线程的栈帧。 -
如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧。
-
Java方法有两种返回函数的方式，但不管使用哪种方式，都会导致栈帧被弹出
一种是正常的函数返回，使用 return 指令另外一种是抛出异常
2.2 栈帧的内部结构
每个栈帧中存储着：
局部变量表（Local Variables）操作数栈（Operand Stack）（或表达式栈）- 动态链接（Dynamic Linking）（或指向运行时常量池的方法引用）
- 6方法返回地址（Return Address）（或方法正常退出或者异常退出的定义）
- 一些附加信息
每个线程下的栈都是私有的，因此每个线程都有自己各自的栈，并且每个栈里面都有很多栈帧，栈帧的大小主要由
局部变量表和操作数栈决定的
3.局部变量表
3.1 局部变量表介绍
- 局部变量表：Local Variables，也被称之为
局部变量数组或本地变量表 定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型、对象引用（reference），以及returnAddress(返回值) 类型。- 由于局部变量表是建立在线程的栈上，是线程的私有数据，因此
不存在数据安全问题 局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的Code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。- 对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。
- 进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。
局部变量表中的变量只在当前方法调用中有效。- 在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。
当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。
举例说明：
局部变量表所需的容量大小是在编译期确定下来的
public class LocalVariablesTest {
private int count = 0;
public static void main(String[] args) {
LocalVariablesTest test = new LocalVariablesTest();
int num = 10;
test.test1();
}
public void test1() {
Date date = new Date();
String name1 = "baidu.com";
String info = test2(date, name1);
System.out.println(date + name1);
}
public String test2(Date dateP, String name2) {
dateP = null;
name2 = "xiexu";
double weight = 185.5;//占据两个slot
char gender = '男';
return dateP + name2;
}
}
反编译后，可得结论：
- 在编译期间，局部变量的个数、每个局部变量的大小都已经被记录下来
- 所以局部变量表所需的容量大小是在编译期确定下来的
- 利用 JClassLib 也可以查看局部变量的个数
JClassLib
参数详解
3.2 关于 Slot 的理解
- 参数值的存放总是从局部变量数组索引 0 的位置开始，到数组长度-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处，其余的参数按照参数表顺序继续排列。
在构造器以及实例方法中，
对象引用this都会存放在索引为0的位置
//构造器
public LocalVariablesTest() {
this.count = 1;
}
//实例方法
public void test1() {
Date date = new Date();
String name1 = "baidu.com";
test2(date, name1);
System.out.println(date + name1);
}
64位的类型（long和double）占用两个slot
public String test2(Date dateP, String name2) {
dateP = null;
name2 = "xiexu";
double weight = 185.5; //占据两个slot
char gender = '男';
return dateP + name2;
}
可以看到，weight为double类型，索引从3直接跳到5，说明double占据两个slot
static方法无法调用this
public static void testStatic() {
LocalVariablesTest test = new LocalVariablesTest();
Date date = new Date();
int count = 10;
System.out.println(count);
// 因为this变量不存在于该静态方法的局部变量表中！！！
// System.out.println(this.count);
}
3.3 Slot 的重复利用
栈帧中的局部变量表中的槽位是可以重用的，如果一个局部变量出了其作用域，那么在其作用域之后声明新的局部变量就很有可能会复用过期局部变量的槽位，从而达到节省资源的目的。
public void test4() {
int a = 0;
{
int b = 0;
b = a + 1;
}
//变量c使用 之前已经销毁的变量b占据的slot的位置
int c = a + 1;
}
可以看到，局部变量c 重用了 局部变量b 的slot位置
复习
类变量和实例变量的区别:
补充说明
- 在栈帧中，与性能调优关系最为密切的部分就是前面提到的局部变量表。在方法执行时，虚拟机使用局部变量表完成方法的传递。
局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。
4.操作数栈(Operand Stack)
4.1 操作数栈的特点
- 每一个独立的栈帧除了包含局部变量表以外，还包含一个
后进先出（Last - In - First -Out）的 操作数栈，也可以称之为表达式栈（Expression Stack） 操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈（push）和 出栈（pop）- 某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈，比如：执行复制、交换、求和等操作
代码举例
public void testAddOperation(){
byte i = 15;
int j = 8;
int k = i + j;
}
字节码指令信息：
public void testAddOperation();
Code:
0: bipush 15
2: istore_1 // 加入到局部变量表中索引为1的位置
3: bipush 8
5: istore_2 // 加入到局部变量表中索引为2的位置
6: iload_1
7: iload_2
8: iadd
9: istore_3
10: return
4.2 操作数栈的作用
- 操作数栈，
主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间。 - 操作数栈就是JVM执行引擎的一个工作区，当一个方法
刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个时候方法的操作数栈是空的（这个时候数组是创建好并且是长度固定的，但数组的内容为空） - 每一个操作数栈都会拥有一个明确的栈深度用于存储数值，
其所需的最大深度在编译期就定义好了，保存在方法的Code属性中，为maxstack的值。
- 栈中的任何一个元素都是可以任意的Java数据类型
32bit的类型占用一个栈单位深度64bit的类型占用两个栈单位深度
- 操作数栈
并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈和出栈操作来完成一次数据访问 如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。- 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译器期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。
- 另外，我们说Java虚拟机的
解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。
4.3 代码追踪
public void testAddOperation() {
//byte、short、char、boolean：都以int型来保存
byte i = 15;
int j = 8;
int k = i + j;
}
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
程序执行流程
- 首先执行第一条语句，PC寄存器指向的是0，也就是指令地址为0，然后使用bipush让操作数15入操作数栈。
- bipush后面带数字的所以占用了两条指令
- 执行完后，让PC寄存器 + 2（占用两条指令，不然就是+1），指向下一行代码，下一行代码就是将操作数栈的元素存储到局部变量表索引1的位置，我们可以看到局部变量表的已经增加了一个元素
- 解释
为什么局部变量表索引从 1 开始，因为该方法为实例方法，局部变量表索引为 0 的位置存放的是 this
- 然后PC寄存器+1，指向的是下一行。让操作数8也入栈，同时执行 istore 操作，存入局部变量表中、
- 然后从局部变量表中，依次将数据取出放在操作数栈中，等待执行 add 操作
- 将操作数栈的两个元素出栈，执行iadd操作
- 这里的 iadd 操作具体是：执行引擎将字节码指令翻译成机器指令，然后被CPU进行运算，得出结果，重新放入操作数栈中
- 然后执行 istore 操作，将操作数23 存储到局部变量表索引为3的位置
关于 int j =8; 的说明
- 我们反编译得到的字节码指令如下
- 因为 8 可以存放在 byte 类型中，所以压入操作数栈的类型为 byte ，而不是 int ，所以执行的字节码指令为 bipush 8
- 然后将数值 8 转换为int类型存储在局部变量表中：istore_2
如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中
public int getSum() {
int m = 10;
int n = 20;
int k = m + n;
return k;
}
public void testGetSum() {
//获取上一个栈桢返回的结果，并保存在操作数栈中
int i = getSum();
int j = 10;
}
面试题：i++ 和 ++i 的区别
//程序员面试过程中，常见的 i++ 和 ++i 的区别，放到字节码篇章时再介绍。
public void add(){
//第1类问题：
int i1 = 10;
i1++;
int i2 = 10;
++i2;
//第2类问题：
int i3 = 10;
int i4 = i3++;
int i5 = 10;
int i6 = ++i5;
//第3类问题：
int i7 = 10;
i7 = i7++;
int i8 = 10;
i8 = ++i8;
//第4类问题：
int i9 = 10;
int i10 = i9++ + ++i9;
}
反编译后的字节码指令
0 bipush 10
2 istore_1
3 iinc 1 by 1 索引为1 加 + 1
6 bipush 10
8 istore_2
9 iinc 2 by 1 索引为2 加 + 1
12 bipush 10
14 istore_3
15 iload_3
16 iinc 3 by 1
19 istore 4
21 bipush 10
23 istore 5
25 iinc 5 by 1
28 iload 5
30 istore 6
32 bipush 10
34 istore 7
36 iload 7
38 iinc 7 by 1
41 istore 7
43 bipush 10
45 istore 8
47 iinc 8 by 1
50 iload 8
52 istore 8
54 bipush 10
56 istore 9
58 iload 9
60 iinc 9 by 1
63 iinc 9 by 1
66 iload 9
68 iadd
69 istore 10
71 return
4.4栈顶缓存技术(Top Of Stack Cashing)
- 前面提过，基于栈式架构的虚拟机所使用的
零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派（instruction dispatch）次数和内存读/写次数。 - 由于操作数是存储在内存中的，因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题，HotSpot JVM的设计者们提出了栈顶缓存（Tos，Top-of-Stack Cashing）技术，
将栈顶元素全部缓存在物理CPU的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率。 - 寄存器的主要优点：指令更少，执行速度快
5.动态链接(Dynamic Linking)
动态链接（或指向运行时常量池的方法引用)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u3QjGrDZ-1684071932753)(JVM.assets/image-20211122165129851.png)]
- 每一个栈帧内部都包含一个指向
运行时常量池中该栈帧所属方法的引用 - 包含这个引用的目的就是为了支持当前方法的代码能够实现
动态链接（Dynamic Linking），比如：invokedynamic指令 - 在Java源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Reference）保存在class文件的常量池里
- 比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么
动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用
在Java源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Reference）保存在class文件的常量池里
public class DynamicLinkingTest {
int num = 10;
public void methodA(){
System.out.println("methodA().....");
}
public void methodB(){
System.out.println("methodB()....");
methodA();
num ++;
}
}
- 在字节码指令中，methodB( ) 方法中通过
invokevirtual #7指令调用了方法 A - 那么
#7是什么呢？
public void methodB();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=3, locals=1, args_size=1
0: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #6 // String methodB()....
5: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: aload_0
9: invokevirtual #7 // Method methodA:()V
12: aload_0
13: dup
14: getfield #2 // Field num:I
17: iconst_1
18: iadd
19: putfield #2 // Field num:I
22: return
LineNumberTable:
line 12: 0
line 13: 8
line 14: 12
line 15: 22
LocalVariableTable:
Start Length Slot Name Signature
0 23 0 this Lcn/sxt/java1/DynamicLinkingTest;
-
往上面翻，找到
常量池的定义：#7 = Methodref #8.#31- 先找
#8：#8 = Class #32：去找#32#32 = Utf8 cn/sxt/java1/DynamicLinkingTest- 结论：通过
#8我们找到了DynamicLinkingTest这个类
- 再来找
#31：#31 = NameAndType #19:#13：去找#19和#13#19 = Utf8 methodA：方法名为 methodA#13 = Utf8 ()V：方法没有形参，返回值为 void
- 先找
-
结论：通过
#7我们就能找到需要调用的methodA( ) 方法，并进行调用
Constant pool:
#1 = Methodref #9.#23 // java/lang/Object."<init>":()V
#2 = Fieldref #8.#24 // cn/sxt/java1/DynamicLinkingTest.num:I
#3 = Fieldref #25.#26 // java/lang/System.out:Ljava/io/PrintStream;
#4 = String #27 // methodA()....
#5 = Methodref #28.#29 // java/io/PrintStream.println:(Ljava/lang/String;)V
#6 = String #30 // methodB()....
#7 = Methodref #8.#31 // cn/sxt/java1/DynamicLinkingTest.methodA:()V
#8 = Class #32 // cn/sxt/java1/DynamicLinkingTest
#9 = Class #33 // java/lang/Object
#10 = Utf8 num
#11 = Utf8 I
#12 = Utf8 <init>
#13 = Utf8 ()V
#14 = Utf8 Code
#15 = Utf8 LineNumberTable
#16 = Utf8 LocalVariableTable
#17 = Utf8 this
#18 = Utf8 Lcn/sxt/java1/DynamicLinkingTest;
#19 = Utf8 methodA
#20 = Utf8 methodB
#21 = Utf8 SourceFile
#22 = Utf8 DynamicLinkingTest.java
#23 = NameAndType #12:#13 // "<init>":()V
#24 = NameAndType #10:#11 // num:I
#25 = Class #34 // java/lang/System
#26 = NameAndType #35:#36 // out:Ljava/io/PrintStream;
#27 = Utf8 methodA()....
#28 = Class #37 // java/io/PrintStream
#29 = NameAndType #38:#39 // println:(Ljava/lang/String;)V
#30 = Utf8 methodB()....
#31 = NameAndType #19:#13 // methodA:()V
#32 = Utf8 cn/sxt/java1/DynamicLinkingTest
#33 = Utf8 java/lang/Object
#34 = Utf8 java/lang/System
#35 = Utf8 out
#36 = Utf8 Ljava/io/PrintStream;
#37 = Utf8 java/io/PrintStream
#38 = Utf8 println
#39 = Utf8 (Ljava/lang/String;)V
为什么要用常量池呢？
- 因为在不同的方法，都可能调用常量或者方法，所以
只需要存储一份即可，然后记录其引用即可，节省了空间 - 常量池的作用：就是为了提供一些符号和常量，便于指令的识别
6.方法的调用：解析和分派
6.1 静态链接与动态链接
在JVM中，将符号引用转换为调用方法的直接引用与方法的绑定机制相关
静态链接：- 当一个字节码文件被装载进JVM内部时，如果被调用的目标方法
在编译期确定，且运行期保持不变时，这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接
- 当一个字节码文件被装载进JVM内部时，如果被调用的目标方法
动态链接：- 如果
被调用的方法在编译期无法被确定下来，也就是说，只能够在程序运行期将调用的方法的符号转换为直接引用，由于这种引用转换过程具备动态性，因此也被称之为动态链接。
- 如果
6.2 方法的绑定机制
静态链接和动态链接对应的方法的绑定机制为：早期绑定（Early Binding）和晚期绑定（Late Binding）。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程，这仅仅发生一次。
早期绑定- 早期绑定就是指被调用的
目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用。
- 早期绑定就是指被调用的
晚期绑定- 如果被调用的方法
在编译期无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式也就被称之为晚期绑定。
- 如果被调用的方法
- 随着高级语言的横空出世，类似于Java一样的基于面向对象的编程语言如今越来越多，尽管这类编程语言在语法风格上存在一定的差别，但是它们彼此之间始终保持着一个共性，那就是都支持封装、继承和多态等面向对象特性，既然
这一类的编程语言具备多态特性，那么自然也就具备早期绑定和晚期绑定两种绑定方式。 - Java中任何一个普通的方法其实都具备虚函数的特征，它们相当于C++语言中的虚函数（C++中则需要使用关键字virtual来显式定义）。如果在Java程序中不希望某个方法拥有虚函数的特征时，则可以使用关键字final来标记这个方法。
代码举例
/**
* @Description: 说明早期绑定和晚期绑定的例子
* @author: JC
* @date: 2021/11/22 18:44
*/
class Animal {
public void eat() {
System.out.println("动物进食");
}
}
interface Huntable {
void hunt();
}
class Dog extends Animal implements Huntable {
@Override
public void eat() {
System.out.println("狗吃骨头");
}
@Override
public void hunt() {
System.out.println("捕食耗子，多管闲事");
}
}
class Cat extends Animal implements Huntable {
public Cat() {
super(); //表现为：早期绑定
}
public Cat(String name) {
this(); //表现为：早期绑定
}
@Override
public void eat() {
super.eat(); //表现为：早期绑定
System.out.println("猫吃鱼");
}
@Override
public void hunt() {
System.out.println("捕食耗子，天经地义");
}
}
public class AnimalTest {
public void showAnimal(Animal animal) {
animal.eat(); //表现为：晚期绑定
}
public void showHunt(Huntable h) {
h.hunt(); //表现为：晚期绑定
}
}
6.3 虚方法和非虚方法
-
如果方法在编译期就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为
非虚方法。 -
静态方法、私有方法、final 方法、实例构造器、父类方法都是非虚方法。 -
其他方法称为虚方法。
子类对象的多态性的使用前提
- 类的继承关系
- 方法的重写
虚拟机中调用方法的指令
-
普通调用指令：
invokestatic：调用静态方法，解析阶段确定唯一方法版本invokespecial：调用<init>方法、私有及父类方法，解析阶段确定唯一方法版本invokevirtual：调用所有虚方法 (声明final不算)invokeinterface：调用接口方法
-
动态调用指令
invokedynamic：动态解析出需要调用的方法，然后执行
-
区别 前四条指令固化在虚拟机内部，方法的调用执行不可人为干预
- 而invokedynamic指令则支持由用户确定方法版本
其中invokestatic指令和invokespecial指令调用的方法称为非虚方法，其余的（final修饰的除外）称为虚方法。
代码举例
/**
* 解析调用中非虚方法、虚方法的测试
*
* invokestatic指令和invokespecial指令调用的方法称为非虚方法
*/
class Father {
public Father() {
System.out.println("father的构造器");
}
public static void showStatic(String str) {
System.out.println("father " + str);
}
public final void showFinal() {
System.out.println("father show final");
}
public void showCommon() {
System.out.println("father 普通方法");
}
}
public class Son extends Father {
public Son() {
//invokespecial 非虚方法
super();
}
public Son(int age) {
//invokespecial 非虚方法
this();
}
//不是重写的父类的静态方法，因为静态方法不能被重写！
public static void showStatic(String str) {
System.out.println("son " + str);
}
private void showPrivate(String str) {
System.out.println("son private" + str);
}
public void show() {
//invokestatic 非虚方法
showStatic("baidu.com");
//invokestatic 非虚方法
super.showStatic("good!");
//invokespecial 非虚方法
showPrivate("hello!");
//invokevirtual
//虽然字节码指令中显示为invokevirtual，但因为此方法声明有final，不能被子类重写，所以也认为此方法是非虚方法。
showFinal();
//invokespecial 非虚方法
super.showCommon();
//invokevirtual 虚方法
//有可能子类会重写父类的showCommon()方法
showCommon();
//invokevirtual 虚方法
//info()是普通方法，有可能被重写，所以是虚方法
info();
MethodInterface in = null;
//invokeinterface 虚方法
in.methodA();
}
public void info() {
}
public void display(Father f) {
f.showCommon();
}
public static void main(String[] args) {
Son so = new Son();
so.show();
}
}
interface MethodInterface {
void methodA();
}
6.4 关于 invokedynamic 指令
- JVM字节码指令集一直比较稳定，一直到Java7中才增加了一个invokedynamic指令，
这是Java为了实现【动态类型语言】支持而做的一种改进。 - 但是在Java7中并没有提供直接生成invokedynamic指令的方法，需要借助ASM这种底层字节码工具来产生invokedynamic指令。
直到Java8的 Lambda表达式 的出现，invokedynamic指令的生成，在Java中才有了直接的生成方式。 - Java7中增加的动态语言类型支持的本质是对Java虚拟机规范的修改，而不是对Java语言规则的修改，这一块相对来讲比较复杂，增加了虚拟机中的方法调用，最直接的受益者就是运行在Java平台的动态语言的编译器。
动态类型语言和静态类型语言
- 动态类型语言和静态类型语言两者的区别就在于对类型的检查是在编译期还是在运行期，满足前者就是静态类型语言，反之是动态类型语言。
- 说的再直白一点就是，静态类型语言是判断变量自身的类型信息；动态类型语言是判断变量值的类型信息，变量没有类型信息，变量值才有类型信息，这是动态语言的一个重要特征。
Java语言：String info = "mogu blog"; (Java是静态类型语言的，会先编译再进行类型检查)
JS语言：var name = "shkstart"; var name = 10; （运行时才进行检查）
Python语言：info = 130.5; （动态类型语言）
代码举例
/**
* 体会invokedynamic 指令
*/
@FunctionalInterface
interface Func {
public boolean func(String str);
}
public class Lambda {
public void lambda(Func func) {
return;
}
public static void main(String[] args) {
Lambda lambda = new Lambda();
Func func = s -> {
return true;
};
lambda.lambda(func);
lambda.lambda(s -> {
return true;
});
}
}
6.5 方法重写的本质
Java 语言中方法重写的本质：
- 找到操作数栈顶的第一个元素所执行的对象的实际类型，记作C。
- 如果在类型C中找到与常量中的描述符合简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束，如果不通过，则返回
java.lang.IllegalAccessError 异常 - 否则，按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程。
- 如果始终没有找到合适的方法，则抛出
java.lang.AbstractMethodError异常。
IllegalAccessError介绍
- 程序试图访问或修改一个属性或调用一个方法，这个属性或方法，你没有权限访问。
- 一般的，这个会引起编译器异常。这个错误如果发生在运行时，就说明一个类发生了不兼容的改变。
- 比如，你把应该有的jar包放从工程中拿走了，或者Maven中存在jar包冲突
6.6 虚方法表
- 在面向对象的编程中，会很频繁的使用到动态分派，如果在每次动态分派的过程中都要重新在类的方法元数据中搜索合适的目标的话就可能影响到执行效率。
- 因此，为了提高性能，
JVM采用在类的方法区建立一个虚方法表（virtual method table）来实现，非虚方法不会出现在表中。使用索引表来代替查找。 - 每个类中都有一个虚方法表，表中存放着各个方法的实际入口。
虚方法表是什么时候被创建的呢？虚方法表会在类加载的链接阶段被创建并开始初始化，类的变量初始值准备完成之后，JVM会把该类的虚方法表也初始化完毕。- 如图所示：如果类中重写了方法，那么调用的时候，就会直接在该类的虚方法表中查找
回顾解析阶段
- 解析阶段就是将常量池内的符号引用转换为直接引用的过程
- 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info等
虚方法表举
public class VirtualMethodTable {
}
interface Friendly {
void sayHello();
void sayGoodbye();
}
class Dog {
public void sayHello() {
}
@Override
public String toString() {
return "Dog";
}
}
class Cat implements Friendly {
public void eat() {
}
public void sayHello() {
}
public void sayGoodbye() {
}
protected void finalize() {
}
public String toString() {
return "Cat";
}
}
class CockerSpaniel extends Dog implements Friendly {
public void sayHello() {
super.sayHello();
}
public void sayGoodbye() {
}
}
7.方法返回地址(return address)
-
存放
调用该方法的pc寄存器的值。 -
一个方法的结束，有两种方式：
- 正常执行完成
- 出现未处理的异常，非正常退出
-
无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，
调用者的pc计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是要通过异常表来确定，栈帧中一般不会保存这部分信息。 -
本质上，方法的退出就是当前栈帧出栈的过程。此时，需要恢复上层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等，让调用者方法继续执行下去。
-
正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值。
方法退出的两种方式
当一个方法开始执行后，只有两种方式可以退出这个方法：
- 执行引擎遇到任意一个方法返回的字节码指令（return），会有返回值传递给上层的方法调用者，简称
正常完成出口- 一个方法在正常调用完成之后，究竟需要使用哪一个返回指令，还需要根据方法返回值的实际数据类型而定。
- 在字节码指令中，返回指令包含：
- ireturn：当返回值是
boolean，byte，char，short和int类型时使用 - lreturn：Long类型
- freturn：Float类型
- dreturn：Double类型
- areturn：引用类型
- return：返回值类型为void的方法、构造器、类和接口的初始化方法
- ireturn：当返回值是
- 在方法执行过程中遇到异常（Exception），并且这个异常没有在方法内进行处理，也就是只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，简称
异常完成出口。- 方法执行过程中，抛出异常时的异常处理，存储在一个异常处理表，方便在发生异常的时候找到处理异常的代码
异常处理表
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5rgtsa1c-1684071932754)(JVM.assets/image-20211122204030702.png)]
- 反编译字节码文件，可得到 Exception table
- from ：字节码指令起始地址
- to ：字节码指令结束地址
- target ：出现异常跳转至地址为 11 的指令执行
- type ：捕获异常的类型
代码举例
public class ReturnAddressTest {
public boolean methodBoolean() {
return false;
}
public byte methodByte() {
return 0;
}
public short methodShort() {
return 0;
}
public char methodChar() {
return 'a';
}
public int methodInt() {
return 0;
}
public long methodLong() {
return 0L;
}
public float methodFloat() {
return 0.0f;
}
public double methodDouble() {
return 0.0;
}
public String methodString() {
return null;
}
public Date methodDate() {
return null;
}
public void methodVoid() {
}
static {
int i = 10;
}
public void method2() {
methodVoid();
try {
method1();
} catch (IOException e) {
e.printStackTrace();
}
}
public void method1() throws IOException {
FileReader fis = new FileReader("atguigu.txt");
char[] cBuffer = new char[1024];
int len;
while ((len = fis.read(cBuffer)) != -1) {
String str = new String(cBuffer, 0, len);
System.out.println(str);
}
fis.close();
}
}
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YYPMYBzc-1684071932755)(JVM.assets/image-20211122204133271.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IF72gerL-1684071932755)(JVM.assets/image-20211122204141690.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eWNLBd3I-1684071932755)(JVM.assets/image-20211122204152193.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tHotIOdA-1684071932755)(JVM.assets/image-20211122204201718.png)]
8.一些附加信息
栈帧中还允许携带与Java虚拟机实现相关的一些附加信息。例如：对程序调试提供支持的信息。
9.栈的相关面试题
举例栈溢出的情况？（StackOverflowError）
- 通过 -Xss 设置栈的大小
- 递归很容易出现栈溢出
调整栈大小，就能保证不出现溢出么？
- 不能保证不出现溢出，只能让栈溢出出现的时间晚一点，不可能不出现
分配的栈内存越大越好么？
- 不是，一定时间内降低了
栈溢出的概率，但是会挤占其它的线程空间，因为整个虚拟机的内存空间是有限的
垃圾回收是否涉及到虚拟机栈？
- 不涉及
方法中定义的局部变量是否线程安全？
何为线程安全？
- 如果只有一个线程才可以操作此数据，则必是线程安全的。
- 如果有多个线程操作此数据，则此数据是共享数据。如果不考虑同步机制的话，会存在线程安全问题。
具体问题具体分析：
- 如果对象是在内部产生，并在内部消亡，没有返回到外部，那么它就是线程安全的，反之则是线程不安全的。
/**
* 面试题：
* 方法中定义的局部变量是否线程安全？具体情况具体分析
*
* 何为线程安全？
* 如果只有一个线程才可以操作此数据，则必是线程安全的。
* 如果有多个线程操作此数据，则此数据是共享数据。如果不考虑同步机制的话，会存在线程安全问题。
*/
public class StringBuilderTest {
//s1的声明方式是线程安全的，因为s1只在方法内部操作，属于局部变量
public static void method1(){
//StringBuilder:线程不安全
StringBuilder s1 = new StringBuilder();
s1.append("a");
s1.append("b");
//...
}
//sBuilder通过参数传递方法内，存在线程不安全的问题
public static void method2(StringBuilder sBuilder){
sBuilder.append("a");
sBuilder.append("b");
//...
}
//操作s1之后，将s1作为返回值返回，这样可能被其他线程所调用，所以存在线程不安全的问题
public static StringBuilder method3(){
StringBuilder s1 = new StringBuilder();
s1.append("a");
s1.append("b");
return s1;
}
//s1的操作：是线程安全的，因为String是线程安全的
public static String method4(){
StringBuilder s1 = new StringBuilder();
s1.append("a");
s1.append("b");
return s1.toString();
}
public static void main(String[] args) {
StringBuilder s = new StringBuilder();
new Thread(() -> {
s.append("a");
s.append("b");
}).start();
method2(s);
}
}
10.运行时数据区会出现Error和GC的地方
✅ : 表示有 ❌ : 表示没有
| Error | GC | |
|---|---|---|
| 程序计数器 | ❌ | ❌ |
| 虚拟机栈 | ✅ | ❌ |
| 本地方法栈 | ✅ | ❌ |
| 堆 | ✅ | ✅ |
| 方法区 | ✅ | ✅ |
第六章 - 本地方法接口
1.本地方法
- 简单地讲，一个Native Method是一个Java调用非Java代码的接囗
- 一个Native Method是这样一个Java方法：该方法的实现由非Java语言实现，比如C。
- 这个特征并非Java所特有，很多其它的编程语言都有这一机制，比如在C++中，你可以用
extern "C"告知C++编译器去调用一个C的函数。 - “A native method is a Java method whose implementation is provided by non-java code.”（本地方法是一个Java的方法，它的具体实现是通过非Java代码的实现）
- 在定义一个native method时，并不提供实现体（有些像定义一个Java interface），因为其实现体是由非java语言在外面实现的。
- 本地接口的作用是融合不同的编程语言为Java所用，它的初衷是
融合C/C++程序。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FDr1BASX-1684071932756)(JVM.assets/image-20211123144128254.png)]
2.native 方法举例
Object类的getClass( )方法
public final native Class<?> getClass();
Thread类的start( )方法
public synchronized void start() {
/**
* This method is not invoked for the main method thread or "system"
* group threads created/set up by the VM. Any new functionality added
* to this method in the future may have to also be added to the VM.
*
* A zero status value corresponds to state "NEW".
*/
if (threadStatus != 0)
throw new IllegalThreadStateException();
/* Notify the group that this thread is about to be started
* so that it can be added to the group's list of threads
* and the group's unstarted count can be decremented. */
group.add(this);
boolean started = false;
try {
start0();
started = true;
} finally {
try {
if (!started) {
group.threadStartFailed(this);
}
} catch (Throwable ignore) {
/* do nothing. If start0 threw a Throwable then
it will be passed up the call stack */
}
}
}
private native void start0();
自定义Native方法
public class IHaveNatives {
public native void Native1(int x);
public native static long Native2();
private native synchronized float Native3(Object o);
native void Native4(int[] ary) throws Exception;
}
注意：标识符native可以与其他java标识符连用，但是不能与
abstract连用
3.为什么要使用Native Method？
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等等，不多做介绍。
第七章 - 本地方法栈
1.本地方法栈
Java虚拟机栈用于管理Java方法的调用，而本地方法栈用于管理本地方法的调用。本地方法栈，也是线程私有的。- 允许被实现成固定或者是可动态扩展的内存大小（在内存溢出方面和虚拟机栈相同）
- 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个StackoverflowError 异常。
- 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么Java虚拟机将会抛出一个OutofMemoryError异常。
- 本地方法一般是使用C语言实现的。
- 它的具体做法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。
2.注意事项
当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。- 本地方法可以通过本地方法接口来
访问虚拟机内部的运行时数据区 - 它甚至可以直接使用
本地处理器中的寄存器 - 直接从本地内存的堆中分配任意数量的内存
- 本地方法可以通过本地方法接口来
- 并不是所有的JVM都支持本地方法。因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持native方法，也可以无需实现本地方法栈。
- 在Hotspot JVM中，直接将本地方法栈和虚拟机栈合二为一。
第八章 - 堆
1.堆的核心概述
1.1 认识堆内存
堆与进程、线程
- 一个进程对应一个JVM实例
- 一个JVM实例对应一个堆空间
- 进程包含多个线程，所以线程之间共享同一个堆空间
对堆的认识
-
一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。
-
Java堆区在JVM启动的时候即被创建，其空间大小也就确定了，
堆是JVM管理的最大一块内存空间。- 堆内存的大小是可以调节的。
-
《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
-
所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区（Thread Local Allocation Buffer，TLAB）。
-
《Java虚拟机规范》中对Java堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated）
-
从实际使用角度看的：“几乎”所有的对象实例都在这里分配内存。因为还有一些对象是在栈上分配的（逃逸分析，标量替换）
-
数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。
-
在方法结束后，
堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除。- 也就是触发了GC的时候，才会进行回收
- 如果堆中对象马上被回收，那么用户线程就会收到影响，因为有 stop the word
-
堆，是GC（Garbage Collection，垃圾收集器）执行垃圾回收的重点区域。
当栈帧结束，局部变量表中的引用也取消了，堆中对象没有引用，此时并不会直接被Gc垃圾回收，只有等新生区空间满了，再执行GC时，发现该对象没有其他指针引用，再来回收，
为什么不再局部变量表中取消引用就执行GC
因为每执行一次GC就会影响用户线程，让用户线程进行等待 ， 如果每取消一次引用，就调用GC ，很影响性能，这样也算程序的优化
代码示例
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);
int[] arr = new int[10];
Object[] arr1 = new Object[10];
}
}
- 字节码指令
一个JVM实例只存在一个堆内存，并且堆内存的大小是可以调节的
public class HeapDemo {
public static void main(String[] args) {
System.out.println("start...");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("end...");
}
}
public class HeapDemo1 {
public static void main(String[] args) {
System.out.println("start...");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("end...");
}
}
如何设置堆内存大小
- 进程1
-Xms10m -Xmx10m
- 进程2
-Xms20m -Xmx20m
1.2 查看堆内存
在jdk–>bin–>jvisualvm.exe 就可以查看
最后重启下软件就会显示了
进程1：堆内存为10M
进程2：堆内存为20M
1.3 堆内存分区(重要)
现代垃圾收集器大部分都基于分代收集理论设计，堆空间细分为：
- Java 7及之前堆内存逻辑上分为三部分：
新生区 + 养老区 + 永久区- Young Generation Space 新生区 Young/New
- 新生区又被划分为
Eden区和Survivor区
- 新生区又被划分为
- Tenure generation space 养老区 Old/Tenure
- Permanent Space永久区 Perm
- Young Generation Space 新生区 Young/New
- **Java 8及之后堆内存逻辑上分为三部分：
新生区 + 养老区 + 元空间**- Young/New Generation Space 新生区，又被划分为Eden区和Survivor区
- Old/Tenure generation space 养老区
- Meta Space 元空间 Meta
- 约定：
新生区 = 新生代 = 年轻代、养老区 = 老年区 = 老年代、永久区 = 永久代 - 堆空间内部结构，JDK1.8之前从
永久代替换成元空间 - 堆空间逻辑上包括
永久代/元空间，实际上控制不到
2.设置堆内存大小与OOM
2.1 设置堆空间大小
- Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项"-Xms"和"-Xmx"来进行设置。
- -Xms 用于表示堆区的初始内存，等价于 -XX:InitialHeapSize
- -Xmx 则用于表示堆区的最大内存，等价于 -XX:MaxHeapSize
- 一旦堆区中的内存大小超过“-Xmx”所指定的最大内存时，将会抛出OutofMemoryError异常。
- 通常会将-Xms和-Xmx两个参数配置相同的值，其目的是为了能够在Java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。
- 默认情况下:
- 初始内存大小：
物理电脑内存大小/64 - 最大内存大小：
物理电脑内存大小/4
- 初始内存大小：
代码示例
/**
* 1. 设置堆空间大小的参数
* -Xms 用来设置堆空间（年轻代+老年代）的初始内存大小
* -X 是jvm的运行参数
* ms 是memory start
* -Xmx 用来设置堆空间（年轻代+老年代）的最大内存大小
*
* 2. 默认堆空间的大小
* 初始内存大小：物理电脑内存大小 / 64
* 最大内存大小：物理电脑内存大小 / 4
*
* 3. 手动设置：-Xms600m -Xmx600m
* 开发中建议将初始堆内存和最大的堆内存设置成相同的值。
* 原因： 堆空间不够后，需要扩容，不用的时候又会将不用的空间进行释放 ，频凡的释放和扩容对系统造成不必要的压力，所以设置成一样的值
* 4. 查看设置的参数：方式一： jps / jstat -gc 进程id
* 方式二：-XX:+PrintGCDetails
*/
public class HeapSpaceInitial {
public static void main(String[] args) {
//返回Java虚拟机中的堆内存总量
long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
//返回Java虚拟机试图使用的最大堆内存量
long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;
System.out.println("-Xms : " + initialMemory + "M");
System.out.println("-Xmx : " + maxMemory + "M");
}
}
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GTgwx9X0-1684071932756)(JVM.assets/image-20211123185721975.png)]
- 两种查看堆内存的方式
- 方式一：命令行依次执行如下两个指令
- jps
- jstat -gc 进程id （查看进程使用的情况）
- 方式二：设置虚拟机参数 -XX:+PrintGCDetails
- 方式一：命令行依次执行如下两个指令
- 为什么设置 600MB ，算出来只有 575MB 呢？
- from区和to区只能有一个区存放对象，所以相加的时候只能加上一个区的大小
- 可以看到新生区的大小 = 伊甸园区大小 + 幸存者 from/to 区大小
- 即 179200KB = 153600KB + 25600KB
2.2 OOM举例
/**
* @author: JC
* @date: 2021/11/25 10:00
* -Xms600m -Xmx600m
*/
public class OOMTest {
public static void main(String[] args) {
ArrayList<Picture> list = new ArrayList<>();
while(true){
try {
Thread.sleep(20);
} catch (InterruptedException e) {
e.printStackTrace();
}
list.add(new Picture(new Random().nextInt(1024 * 1024)));
}
}
}
class Picture {
private byte[] pixels;
public Picture(int length) {
this.pixels = new byte[length];
}
}
- 设置虚拟机参数
-Xms600m -Xmx600m
- 监控堆内存变化：Old 区域一点一点在变大，直到最后一次垃圾回收器无法回收垃圾时，堆内存被撑爆，抛出 OutOfMemoryError 错误
- 堆内存变化图
- 分析原因：大对象导致堆内存溢出
3.年轻代与老年代
3.1 Java 对象分类
- 存储在JVM中的Java对象可以被划分为两类：
- 一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速
- 另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期保持一致
- Java堆区进一步细分的话，可以划分为年轻代（YoungGen）和老年代（oldGen）
- 其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间（有时也叫做from区、to区）
3.2 配置新老比例
配置新生代与老年代的比例
配置新生代与老年代在堆结构的占比（下面这些参数在开发中一般不会调）
- 默认**-XX:NewRatio**=2，表示新生代占1，老年代占2，新生代占整个堆的1/3 (1:2)
- 可以修改**-XX:NewRatio**=4，表示新生代占1，老年代占4，新生代占整个堆的1/5 (1:4)
- 当发现在整个项目中，生命周期长的对象偏多，那么就可以通过调整老年代的大小，来进行调优
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EXJCyRcu-1684071932757)(JVM.assets/image-20211125102943340.png)]
新生区中的比例
- 在HotSpot中，Eden空间和另外两个survivor空间缺省所占的比例是8 : 1 : 1
- 当然开发人员可以通过选项**-XX:SurvivorRatio**调整这个空间比例。比如-XX:SurvivorRatio=8
几乎所有的Java对象都是在Eden区被new出来的。- 绝大部分的Java对象的销毁都在新生代进行了（有些大的对象在Eden区无法存储时候，将直接进入老年代）
- IBM公司的专门研究表明，新生代中80%的对象都是“朝生夕死”的。
- 可以使用选项"-Xmn"设置新生代最大内存大小，但这个参数一般使用默认值就可以了。
- 新生区的对象默认生命周期超过 15 ，将进入老年代
代码示例
/**
* -Xms600m -Xmx600m
*
* -XX:NewRatio ： 设置新生代与老年代的比例。默认值是2.
* -XX:SurvivorRatio ：设置新生代中Eden区与Survivor区的比例。默认值是8
* -XX:-UseAdaptiveSizePolicy ：关闭自适应的内存分配策略 （暂时用不到）
* -Xmn:设置新生代的空间的大小。 （一般不设置）
*/
public class EdenSurvivorTest {
public static void main(String[] args) {
System.out.println("我只是来 打个酱油~");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
-
通过命令行查看各种比例
-
查看新生代与老年代的比例
-
jps jinfo -flag NewRatios 进程id -
查看新生区中伊甸园区与幸存者区的比例
-
jps jinfo -flag SurvivorRatio 进程id
-
-
设置 JVM 参数
-Xms600m -Xmx600m -XX:NewRatio=2 -XX:SurvivorRatio=8
- 新生区中：伊甸园区 : 幸存者 0 区 : 幸存者 1 区 = 8 : 1 : 1
- 新生区 : 老年区 = 1 : 2
4.图解对象分配过程
4.1 对象分配过程
为新对象分配内存是一件非常严谨和复杂的任务，JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。
-
new的对象先放伊甸园区。此区有大小限制。
-
当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收（MinorGC），将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区。
-
然后将伊甸园中的剩余对象移动到幸存者0区。
-
如果再次触发垃圾回收，此时将伊甸园区和幸存者0区进行垃圾回收，剩下的对象就会放到幸存者1区。
-
如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
-
啥时候能去养老区呢？可以设置次数。默认是15次。可以设置新生区进入养老区的年龄限制，设置 JVM 参数：-XX:MaxTenuringThreshold=N 进行设置
-
在养老区，相对悠闲。当养老区内存不足时，再次触发GC：Major GC，进行养老区的内存清理
-
若养老区执行了Major GC之后，发现依然无法进行对象的保存，就会产生OOM异常。
4.2 图解对象分配(重要)
- 我们创建的对象，一般都是存放在Eden区的，当我们的Eden区满了后，就会触发GC操作，一般被称为
YGC / Minor GC操作
- 当我们进行一次垃圾收集后，红色的对象将会被回收，而绿色的独享还被占用着，存放在S0(Survivor From)区。同时我们给每个对象设置了一个年龄计数器，经过一次回收后还存在的对象，将其年龄加 1。
- 同时Eden区继续存放对象，当Eden区再次存满的时候，又会触发一个MinorGC操作，此时GC将会把 Eden和Survivor From中的对象进行一次垃圾收集，把存活的对象放到 Survivor To区，同时让存活的对象年龄 + 1
- 我们继续不断的进行对象生成和垃圾回收，当Survivor中的对象的年龄达到15的时候，将会触发一次
Promotion 晋升的操作，也就是将年轻代中的对象晋升到老年代中
代码示例
/**
* -Xms600m -Xmx600m
*/
public class HeapInstanceTest {
byte[] buffer = new byte[new Random().nextInt(1024 * 200)];
public static void main(String[] args) {
ArrayList<HeapInstanceTest> list = new ArrayList<HeapInstanceTest>();
while (true) {
list.add(new HeapInstanceTest());
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
- 注意【伊甸园区、幸存者区、老年区】的内存变化趋势
总结:
针对幸存者s0，s1区的总结：复制之后有交换，谁空谁是to。
关于垃圾回收：频繁再新生区收集，很少再养老区收集，几乎不在永久区/元空间收集
新生代采用复制算法的目的：是为了减少内碎片
4.3 特殊情况说明
思考：幸存区满了咋办？
- 特别注意，在Eden区满了的时候，才会触发MinorGC，而幸存者区满了后，不会触发MinorGC操作
- 如果Survivor区满了后，将会触发一些特殊的规则，也就是可能直接晋升老年代
对象分配的特殊情况
-
如果来了一个新对象，先看看 Eden 是否放的下？
- 如果 Eden 放得下，则直接放到 Eden 区
- 如果 Eden 放不下，则触发 YGC ，执行垃圾回收，看看还能不能放下？放得下最好当然最好咯~~ ~
-
将对象放到老年区又有两种情况：
- 如果 Eden 执行了 YGC 还是无法放不下该对象，那没得办法，只能说明是超大对象，只能直接怼到老年代
- 那万一老年代都放不下，则先触发重 GC ，再看看能不能放下，放得下最好，但如果还是放不下，那只能报 OOM 啦~~ ~
-
如果 Eden 区满了，将对象往幸存区拷贝时，发现幸存区放不下啦，那只能便宜了某些新对象，让他们直接晋升至老年区
4.4 常用调优工具
常用的 JVM 调优工具
- JDK命令行
- Eclipse：Memory Analyzer Tool
- Jconsole
- Visual VM（实时监控 推荐~）
- Jprofiler（推荐~）
- Java Flight Recorder（实时监控）
- GCViewer
- GCEasy
Jprofiler 基本使用
- 在 IDEA 中启动 Jprofiler
- 点击 Instrumentation
- 选择默认配置即可，点击【OK】启动
5.GC垃圾回收器
5.1 分代收集思想(面试必问)
Minor GC、Major GC、Full GC
我们都知道，JVM调优的一个环节，也就是垃圾收集，我们需要尽量的避免垃圾回收，因为在垃圾回收的过程中，容易出现STW（Stop the World）的问题，而 Major GC 和 Full GC出现STW的时间，是Minor GC的10倍以上
JVM在进行GC时，并非每次都对上面三个内存( 新生代、老年代；方法区 )区域一起回收的，大部分时候回收的都是指新生代。针对Hotspot VM的实现，它里面的GC按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（FullGC）
- 部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：
- 新生代收集（ Minor GC/Young GC ）：只是新生代( Eden、S0/S1 )的垃圾收集
- 老年代收集（ Major GC/Old GC ）：只是老年代的垃圾收集。
- 目前，
只有CMS GC会有单独收集老年代的行为。 - 注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。
- 目前，
- 混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集。
- 目前，只有G1 GC会有这种行为
- 整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集。
5.2 Young/Minor GC
年轻代 GC（Minor GC）触发机制
-
当年轻代空间不足时，就会触发Minor GC，这里的年轻代满指的是
Eden区满，Survivor区满不会触发GC。（每次Minor GC会清理年轻代的内存） -
因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。
-
Minor GC会引发
STW，暂停其它用户的线程，等待垃圾回收线程结束，用户线程才恢复运行
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zUKYVUFw-1684071932759)(JVM.assets/image-20211125132425202.png)]
5.3 Major GC
老年代 GC（MajorGC/Full GC）触发机制
- 指发生在老年代的GC，对象从老年代消失时，我们说 “Major Gc” 或 “Full GC” 发生了
- 出现了MajorGc，经常会伴随至少一次的Minor GC
- 但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程
- 也就是在老年代空间不足时，会先尝试触发Minor GC，如果之后空间还不足，则触发Major GC
- Major GC的速度一般会比Minor GC慢10倍以上，STW的时间更长
- 如果Major GC后，内存还不足，就报OOM了
5.4 Full GC
Full GC 触发机制（后面细讲）
触发Full GC执行的情况有如下五种：
- 调用System.gc( )时，系统建议执行Full GC，但是不必然执行
- 老年代空间不足
- 方法区空间不足
- 通过Minor GC后进入老年代的平均大小 大于 老年代的可用内存
- 由Eden区、survivor space0（From Space）区 向survivor space1（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存 小于 该对象大小。
说明：Full GC 是开发或调优中尽量要避免的。这样STW时间会短一些
5.5 GC 日志分析
/**
* @author: JC
* @date: 2021/11/25 13:56
* 测试MinorGC、MajorGC、FullGC
* -Xms9m -Xmx9m -XX:+PrintGCDetails
*/
public class GCTest {
public static void main(String[] args) {
int i = 0;
try {
List<String> list = new ArrayList<>();
String a = "atguigu.com";
while (true) {
list.add(a);
a = a + a;
i++;
}
} catch (Throwable t) {
t.printStackTrace();
System.out.println("遍历次数为：" + i);
}
}
}
- JVM 参数
-Xms9m -Xmx9m -XX:+PrintGCDetails
- GC 日志：在 OOM 之前，一定会触发一次 Full GC ，因为只有在老年代空间不足且进行垃圾回收后仍然空间不足的时候，才会爆出OOM异常
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lRqjZGN5-1684071932759)(JVM.assets/image-20211125140836696.png)]
[Full GC (Ergonomics) [PSYoungGen: 1319K->0K(2560K)]
[ParOldGen: 6782K->4864K(7168K)]
8102K->4864K(9728K)
[Metaspace: 3452K->3452K(1056768K)], 0.0050464 secs]
[Times: user=0.00 sys=0.00, real=0.01 secs]
- [PSYoungGen: 1319K->0K(2560K)] ：年轻代总空间为 2560K ，当前占用 1319K ，经过垃圾回收后占用 0K
- [ParOldGen: 6782K->4864K(7168K)] ：老年代总空间为 7168K ，当前占用 6782K ，经过垃圾回收后占用 4864K
- 8102K->4864K(9728K)：堆内存总空间为 9728K ，当前占用 8102K ，经过垃圾回收后占用 4864K
- [Metaspace: 3452K->3452K(1056768K)] ：元空间总空间为 1056768K ，当前占用 3452K ，经过垃圾回收后占用 3452K
- 0.0050464 secs ：垃圾回收用时 0.0050464 secs
6.堆空间分配思想
为什么要把Java堆分代？不分代就不能正常工作了吗？
-
经研究，不同对象的生命周期不同。70%-99%的对象是临时对象。
- 新生代：有Eden、两块大小相同的Survivor（又称为from/to，s0/s1）构成，to总为空。
- 老年代：存放新生代中经历多次GC之后仍然存活的对象。
-
其实不分代完全可以，分代的唯一理由就是优化GC性能。
- 如果没有分代，那所有的对象都在一块，就如同把一个学校的人都关在一个教室。GC的时候要找到哪些对象没用，这样就会对堆的所有区域进行扫描。
- 而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WpW22Obq-1684071932759)(JVM.assets/image-20211125142859576.png)]
7.内存分配策略
内存分配策略或对象提升（Promotion）规则
- 如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将对象年龄设为1。
- 对象在Survivor区中每熬过一次MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，其实每个JVM、每个GC都有所不同）时，就会被晋升到老年代
- 对象晋升老年代的年龄阀值，可以通过选项**-XX:MaxTenuringThreshold**来设置
针对不同年龄段的对象分配原则如下所示：
- 优先分配到Eden
- 大对象直接分配到老年代：
- 尽量避免程序中出现过多的大对象
- 长期存活的对象分配到老年代
- 动态对象年龄判断：
- 如果Survivor区中相同年龄的所有对象大小的总和
大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
- 如果Survivor区中相同年龄的所有对象大小的总和
- 空间分配担保：
- -XX:HandlePromotionFailure ，也就是经过Minor GC后，所有的对象都存活，因为Survivor比较小，所以就需要将Survivor无法容纳的对象，存放到老年代中。
代码示例
/**
* @author: JC
* @date: 2021/11/25 14:33
* 测试：大对象直接进入老年代
* -Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails
*/
public class YoungOldAreaTest {
public static void main(String[] args) {
byte[] buffer = new byte[1024 * 1024 * 20]; //20m
}
}
-Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails
8.为对象分配内存: TLAB
8.1 为什么有 TLAB
问题：堆空间都是共享的么？
不一定，因为还有TLAB这个概念，在堆中划分出一块区域，为每个线程所独占
为什么有TLAB（Thread Local Allocation Buffer）？
- TLAB：Thread Local Allocation Buffer，也就是为每个线程单独分配了一个缓冲区
- 堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据
- 由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的
- 为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。
8.2 什么是 TLAB
- 从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分，JVM为每个线程分配了一个私有缓存区域，它包含在Eden空间内。
- 多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略。
- 据我所知所有OpenJDK衍生出来的JVM都提供了TLAB的设计。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gkTY8AIv-1684071932759)(JVM.assets/image-20211125144051322.png)]
8.3 TLAB 分配过程
-
尽管不是所有的对象实例都能够在TLAB中成功分配内存，但JVM确实是将TLAB作为内存分配的首选。
-
在程序中，开发人员可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间。
-
默认情况下，TLAB空间的内存非常小，
仅占有整个Eden空间的1%，当然我们可以通过选项“-XX:TLABWasteTargetPercent”设置TLAB空间所占用Eden空间的百分比大小。 -
一旦对象在TLAB空间分配内存失败时，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LMvCQMLT-1684071932760)(JVM.assets/image-20211125144137515.png)]
代码示例
/**
* @author: JC
* @date: 2021/11/25 14:58
* 测试-XX:UseTLAB参数是否开启的情况:默认情况是开启的
*/
public class TLABArgsTest {
public static void main(String[] args) {
System.out.println("我只是来打个酱油~");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
- 查看 UseTLAB 标志位的状态
C:\Users\JC>jps
C:\Users\JC>jinfo -flag UseTLAB 2772
- 我并没有设置任何 JVM 参数，通过命令行查看 TLAB 是否开启：结论是默认开启 TLAB的
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NDNFSjM9-1684071932760)(JVM.assets/image-20211125150125619.png)]
9.堆空间参数设置
9.1 常用参数设置
官方文档
常用参数设置
- -XX:+PrintFlagsInitial：查看所有的参数的默认初始值
- -XX:+PrintFlagsFinal：查看所有的参数的最终值（可能会存在修改，不再是初始值）
- -Xms：初始堆空间内存（默认为物理内存的1/64）
- -Xmx：最大堆空间内存（默认为物理内存的1/4）
- -Xmn：设置新生代的大小（初始值及最大值）
- -XX:NewRatio：配置新生代与老年代在堆结构的占比
- -XX:SurvivorRatio：设置新生代中Eden和S0/S1空间的比例
- -XX:MaxTenuringThreshold：设置新生代垃圾的最大年龄
- -XX:+PrintGCDetails：输出详细的GC处理日志
- -XX:+PrintGC 或 -verbose:gc ：打印gc简要信息
- -XX:HandlePromotionFalilure：是否设置空间分配担保
9.2 空间分配担保
在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。
- 如果大于，则此次Minor GC是安全的
- 如果小于，则虚拟机会查看**-XX:HandlePromotionFailure**设置值是否允许担保失败。
- 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小
- 如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；
- 如果小于，则进行一次Full GC。
- 如果HandlePromotionFailure=false，则进行一次Full GC。
- 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小
历史版本
- 在JDK6 Update 24之后 (JDK 7)，HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略，观察openJDK中的源码变化，虽然源码中还定义了HandlePromotionFailure参数，但是在代码中已经不会再使用它。
- JDK6 Update 24之后的规则变为只要老年代的连续空间
大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。即 HandlePromotionFailure=true
代码示例
/**
* 测试堆空间常用的jvm参数：
* -XX:+PrintFlagsInitial : 查看所有的参数的默认初始值
* -XX:+PrintFlagsFinal ：查看所有的参数的最终值（可能会存在修改，不再是初始值）
* 具体查看某个参数的指令：
* jps：查看当前运行中的进程
* jinfo -flag SurvivorRatio 进程id
* -Xms：初始堆空间内存 （默认为物理内存的1/64）
* -Xmx：最大堆空间内存（默认为物理内存的1/4）
* -Xmn：设置新生代的大小。(初始值及最大值)
* -XX:NewRatio：配置新生代与老年代在堆结构的占比
* -XX:SurvivorRatio：设置新生代中Eden和S0/S1空间的比例
* -XX:MaxTenuringThreshold：设置新生代垃圾的最大年龄
* -XX:+PrintGCDetails：输出详细的GC处理日志
* 打印gc简要信息：① -XX:+PrintGC ② -verbose:gc
* -XX:HandlePromotionFailure：是否设置空间分配担保
*/
public class HeapArgsTest {
public static void main(String[] args) {
}
}
10.致命面试题
堆是分配对象存储的唯一选择吗？
在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述：
-
随着JIT(即时编译器)编译期的发展与
逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。 -
在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是
如果经过逃逸分析（Escape Analysis）后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。 -
此外，前面提到的基于OpenJDK深度定制的TaoBao VM( 淘宝虚拟机 )，其中创新的GCIH（GC invisible heap）技术实现off-heap，将生命周期较长的Java对象从heap中移至heap外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。
10.1 逃逸分析
如何将堆上的对象分配到栈，需要使用逃逸分析手段。
-
这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。
-
通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。
-
逃逸分析的基本行为就是分析对象动态作用域：
- 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
- 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。
举例
- 没有发生逃逸的对象，则可以分配到栈上，随着方法执行的结束，栈空间就被移除
public void my_method() {
V v = new V();
// use v
// ....
v = null;
}
- 下面代码中的 StringBuffer sb 发生了逃逸(不能使用栈上分配)
public static StringBuffer createStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb;
}
- 如果想要StringBuffer sb不发生逃逸，可以这样写 （返回值改为String）
public static String createStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb.toString();
}
- 逃逸分析的举例
/**
* 逃逸分析
*
* 如何快速的判断是否发生了逃逸分析，大家就看new的对象实体是否有可能在方法外被调用。
*/
public class EscapeAnalysis {
public EscapeAnalysis obj;
/*
方法返回EscapeAnalysis对象，发生逃逸
*/
public EscapeAnalysis getInstance(){
return obj == null? new EscapeAnalysis() : obj;
}
/*
为成员属性赋值，发生逃逸
*/
public void setObj(){
this.obj = new EscapeAnalysis();
}
//思考：如果当前的obj引用声明为static的？ 仍然会发生逃逸。
/*
对象的作用域仅在当前方法中有效，没有发生逃逸
*/
public void useEscapeAnalysis(){
EscapeAnalysis e = new EscapeAnalysis();
}
/*
引用成员变量的值，发生逃逸
*/
public void useEscapeAnalysis1(){
EscapeAnalysis e = getInstance(); //这个e对象，本身就是从外面的方法逃逸进来的
//getInstance().xxx()同样会发生逃逸
}
}
逃逸分析参数设置
-
在JDK 1.7 版本之后，HotSpot中默认就已经开启了逃逸分析
-
如果使用的是较早的版本，开发人员则可以通过：
- 选项“-XX:+DoEscapeAnalysis"显式开启逃逸分析
- 通过选项“-XX:+PrintEscapeAnalysis"查看逃逸分析的筛选结果
结论
开发中能使用局部变量的，就不要使用在方法外定义。
逃逸分析之代码优化
使用逃逸分析，编译器可以对代码做如下优化：
- 栈上分配：将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会发生逃逸，对象可能是栈上分配的候选，而不是堆上分配
- 同步省略：如果一个对象被发现只有一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
- 分离对象或标量替换：有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。
10.2 栈上分配
-
JIT编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。
-
分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了。
-
常见的栈上分配的场景：
- 在逃逸分析中，已经说明了，分别是给成员变量赋值、方法返回值、实例引用传递。
代码举例
/**
* 栈上分配测试
* -Xmx256m -Xms256m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
*/
public class StackAllocation {
public static void main(String[] args) {
long start = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
alloc();
}
// 查看执行时间
long end = System.currentTimeMillis();
System.out.println("花费的时间为： " + (end - start) + " ms");
// 为了方便查看堆内存中对象个数，线程sleep
try {
Thread.sleep(1000000);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
private static void alloc() {
User user = new User(); //未发生逃逸
}
static class User {
}
}
未开启逃逸分析的情况
- JVM 参数设置
-Xmx256m -Xms256m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
- 日志打印：发生了 GC ，耗时 49ms
[GC (Allocation Failure) [PSYoungGen: 65536K->808K(76288K)] 65536K->816K(251392K), 0.0022640 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 66344K->792K(76288K)] 66352K->800K(251392K), 0.0006668 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
花费的时间为： 49 ms
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MSkR1HWc-1684071932761)(JVM.assets/image-20211125161656706.png)]
开启逃逸分析的情况
- JVM 参数设置
-Xmx256m -Xms256m -XX:+DoEscapeAnalysis -XX:+PrintGCDetails
- 日志打印：并没有发生 GC ，耗时 3ms ，栈上分配是真的快啊
花费的时间为： 3 ms
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9M4pTE5b-1684071932761)(JVM.assets/image-20211125161934897.png)]
10.3 同步省略
-
线程同步的代价是相当高的，同步的后果是降低并发性和性能。
-
在动态编译同步块的时候，JIT编译器可以借助
逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。 -
如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。
-
例如下面的智障代码，根本起不到锁的作用
public void f() {
Object hellis = new Object();
synchronized(hellis) {
System.out.println(hellis);
}
}
- 代码中对hellis这个对象加锁，但是hellis对象的生命周期只在f( )方法中，并不会被其他线程所访问到，所以在JIT编译阶段就会被优化掉，优化成：
public void f() {
Object hellis = new Object();
System.out.println(hellis);
}
字节码分析
/**
* 同步省略说明
* @author xiexu
* @create 2020-11-27 7:01 下午
*/
public class SynchronizedTest {
public void f() {
Object hellis = new Object();
synchronized(hellis) {
System.out.println(hellis);
}
}
}
- 注意：字节码文件中并没有进行优化，可以看到加锁和释放锁的操作依然存在，同步省略操作是在解释运行时发生的
10.4 分离对象或标量替换
-
标量（scalar）是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。
-
相对的，那些还可以分解的数据叫做聚合量（Aggregate），Java中的对象就是聚合量，因为他可以分解成其他聚合量和标量。
-
在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。
标量替换举例
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);
}
结论：
- 可以看到，Point这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个聚合量了。
- 那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。
- 标量替换为栈上分配提供了很好的基础。
标量替换参数设置
参数 -XX:+ElimilnateAllocations：开启了标量替换（默认打开），允许将对象打散分配在栈上。
代码举例
/**
* 标量替换测试
* -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations
*/
public class ScalarReplace {
public static class User {
public int id;
public String name;
}
public static void alloc() {
User u = new User(); //未发生逃逸
u.id = 5;
u.name = "www.baidu.com";
}
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");
}
}
未开启标量替换
- JVM 参数
-Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations
- 日志分析：伴随着 GC 的垃圾回收，用时 84ms
[GC (Allocation Failure) 25600K->536K(98304K), 0.0021681 secs]
[GC (Allocation Failure) 26136K->536K(98304K), 0.0019547 secs]
[GC (Allocation Failure) 26136K->472K(98304K), 0.0016708 secs]
[GC (Allocation Failure) 26072K->536K(98304K), 0.0016899 secs]
[GC (Allocation Failure) 26136K->584K(98304K), 0.0018258 secs]
[GC (Allocation Failure) 26184K->568K(101376K), 0.0015689 secs]
[GC (Allocation Failure) 32312K->461K(101376K), 0.0015208 secs]
[GC (Allocation Failure) 32205K->461K(101376K), 0.0010466 secs]
花费的时间为： 84 ms
开启标量替换
- JVM 参数
-Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations
- 日志分析：无垃圾回收，用时 5ms
花费的时间为： 5 ms
逃逸分析参数设置总结
- 上述代码在主函数中调用了1亿次alloc( )方法，进行对象创建
- 由于User对象实例需要占据约16字节的空间，因此累计分配空间达到将近1.5GB。
- 如果堆空间小于这个值，就必然会发生GC。使用如下参数运行上述代码：
-server -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations
这里设置参数如下：
- 参数 -server：启动Server模式，因为在server模式下，才可以启用逃逸分析。
- 参数 -XX:+DoEscapeAnalysis：启用逃逸分析
- 参数 -Xmx10m：指定了堆空间最大为10MB
- 参数 -XX:+PrintGC：将打印GC日志。
- 参数 -XX:+EliminateAllocations：开启了标量替换（默认打开），允许将对象打散分配在栈上，比如对象拥有id和name两个字段，那么这两个字段将会被视为两个独立的局部变量进行分配
逃逸分析的不足
- 关于逃逸分析的论文在1999年就已经发表了，但直到JDK1.6才有实现，而且这项技术到如今也并不是十分成熟的。
- 其根本原因就是
无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。 - 虽然这项技术并不十分成熟，
但是它也是即时编译器优化技术中一个十分重要的手段。注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。 - 据我所知，Oracle Hotspot JVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。
- Oracle Hotspot JVM是通过标量替换实现逃逸分析的
- 目前很多书籍还是基于JDK7以前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：
对象实例都是分配在堆上。
11.堆小结
- 年轻代是对象的诞生、成长、消亡的区域，一个对象在这里产生、应用，最后被垃圾回收器收集、结束生命。
- 老年代放置长生命周期的对象，通常都是从Survivor区域筛选拷贝过来的Java对象。
- 当然，也有特殊情况，我们知道普通的对象可能会被分配在TLAB上
- 如果对象较大，无法分配在 TLAB 上，则JVM会试图直接分配在Eden其他位置上
- 如果对象太大，完全无法在新生代找到足够长的连续空闲空间，JVM就会直接分配到老年代
- 当GC只发生在年轻代中，回收年轻代对象的行为被称为Minor GC
- 当GC发生在老年代时则被称为Major GC或者Full GC
- 一般的，Minor GC的发生频率要比Major GC高很多，即老年代中垃圾回收发生的频率将大大低于年轻代
第九章 - 方法区
1.栈、堆、方法区的交互关系
从内存结构看
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AjWDrFnr-1684071932761)(JVM.assets/image-20211125185151054.png)]
从线程共享与否的角度看
ThreadLocal：如何保证多个线程在并发环境下的安全性？典型应用就是数据库连接管理，以及独立会话管理
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QV4sTfl9-1684071932762)(JVM.assets/image-20211125190034968.png)]
栈、堆、方法区的交互关系
- Person 类的 .class 信息存放在方法区中
- person 变量存放在 Java 栈的局部变量表中
- 真正的 person 对象存放在 Java 堆中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Xviqjqfb-1684071932762)(JVM.assets/image-20211125190109565.png)]
- 在 person 对象中，有个指针指向方法区中的 person 类型数据，表明这个 person 对象是用方法区中的 Person 类 new 出来的
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OoEMlxKz-1684071932762)(JVM.assets/image-20211125190130229.png)]
2.方法区的理解
官方文档
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RaJGOgeX-1684071932763)(JVM.assets/image-20211125190530289.png)]
2.1 方法区的位置
-
《Java虚拟机规范》中明确说明：尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。
-
但对于HotSpotJVM而言，方法区还有一个别名叫做Non-Heap（非堆），目的就是要和堆分开。
-
所以，方法区可以看作是一块独立于Java堆的内存空间。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TKGy911L-1684071932763)(JVM.assets/image-20211125191648316.png)]
2.2 方法区的理解
方法区主要存放的是 Class，而堆中主要存放的是实例化的对象
- 方法区（Method Area）与Java堆一样，是各个线程共享的内存区域
- 多个线程同时加载统一个类时，只能有一个线程能加载该类，其他线程只能等等待该线程加载完毕，然后直接使用该类，即类只能加载一次。
- 方法区在JVM启动的时候被创建，并且它的实际物理内存空间和Java堆区一样都可以是不连续的。
- 方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。
- 方法区是接口，元空间或者永久代是方法区的实现
- 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误：
- java.lang.OutofMemoryError:PermGen space（JDK7之前）
- 或者
- java.lang.OutOfMemoryError:Metaspace（JDK8之后）
- 举例说明方法区 OOM
- 加载大量的第三方的jar包
- Tomcat部署的工程过多（30~50个）
- 大量动态的生成反射类
- 关闭JVM就会释放这个区域的内存。
代码示例
/**
* -Xms600m -Xmx600m
*/
public class EdenSurvivorTest {
public static void main(String[] args) {
System.out.println("我只是来打个酱油~");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
- 简单的程序，加载了好多类
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Z0pCDd30-1684071932763)(JVM.assets/image-20211125192728144.png)]
2.3 Hotspot中方法区的演进过程
-
在 JDK7 及以前，习惯上把方法区，称为永久代。JDK8开始，使用元空间取代了永久代。JDK 1.8之后，元空间存放在堆外内存中
-
我们可以将方法区类比为Java中的接口，将永久代或元空间类比为Java中具体的实现类
-
本质上，方法区和永久代并不等价。仅是对Hotspot而言的可以看作等价。《Java虚拟机规范》对如何实现方法区，不做统一要求。例如：BEAJRockit / IBM J9 中不存在永久代的概念。
-
现在来看，当年使用永久代，不是好的idea。导致Java程序更容易OOm（超过-XX:MaxPermsize上限）
-
而到了JDK8，终于完全废弃了永久代的概念，改用与JRockit、J9一样在本地内存中实现的元空间（Metaspace）来代替
-
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存
-
永久代、元空间二者并不只是名字变了，内部结构也调整了
-
根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OOM异常
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ty7xBLXo-1684071932764)(JVM.assets/image-20211125193534990.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YqFH4P56-1684071932764)(JVM.assets/image-20211125193550433.png)]
3.设置方法区大小与OOM
方法区的大小不必是固定的，JVM可以根据应用的需要动态调整
3.1 JDK7 永久代
- 通过-XX:Permsize来设置永久代初始分配空间。默认值是20.75M
- -XX:MaxPermsize来设定永久代最大可分配空间。32位机器默认是64M，64位机器模式是82M
- 当JVM加载的类信息容量超过了这个值，会报异常OutofMemoryError:PermGen space。
3.2 JDK8 元空间
- 元数据区大小可以使用参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 指定
- 默认值依赖于平台，Windows下，-XX:MetaspaceSize 约为21M，-XX:MaxMetaspaceSize的值是-1，即没有限制。
- 与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存。如果元数据区发生溢出，虚拟机一样会抛出异常OutOfMemoryError:Metaspace
- -XX:MetaspaceSize：设置初始的元空间大小。对于一个 64位 的服务器端 JVM 来说，其默认的 -XX:MetaspaceSize值为21MB。这就是初始的高水位线，一旦触及这个水位线，Full GC将会被触发并卸载没用的类（即这些类对应的类加载器不再存活），然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间。
- 如果释放的空间不足，那么在不超过MaxMetaspaceSize时，适当提高该值。
- 如果释放空间过多，则适当降低该值。
- 如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次。通过垃圾回收器的日志可以观察到Full GC多次调用。为了避免频繁地GC，建议将-XX:MetaspaceSize设置为一个相对较高的值。
配置元空间大小示例
/**
* 测试设置方法区大小参数的默认值
*
* jdk7及以前：
* -XX:PermSize=100m -XX:MaxPermSize=100m
*
* jdk8及以后：
* -XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m
*/
public class MethodAreaDemo {
public static void main(String[] args) {
System.out.println("start...");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("end...");
}
}
- JVM参数
-XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m
- 终端命令查看设置的元空间大小
C:\Users\JC>jps
C:\Users\JC>jinfo -flag MetaspaceSize 4860
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dgQA2KzN-1684071932764)(JVM.assets/image-20211126195859074.png)]
3.3 方法区OOM
- OOMTest 类继承 ClassLoader 类，获得 defineClass() 方法，可自己进行类的加载
/**
* jdk6/7中：
* -XX:PermSize=10m -XX:MaxPermSize=10m
*
* jdk8中：
* -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
*/
public class OOMTest extends ClassLoader {
public static void main(String[] args) {
int j = 0;
try {
OOMTest test = new OOMTest();
for (int i = 0; i < 10000; i++) {
//创建ClassWriter对象，用于生成类的二进制字节码
ClassWriter classWriter = new ClassWriter(0);
//指明版本号，修饰符，类名，包名，父类，接口
classWriter.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
//返回byte[]
byte[] code = classWriter.toByteArray();
//类的加载
test.defineClass("Class" + i, code, 0, code.length); //Class对象
j++;
}
} finally {
System.out.println(j);
}
}
}
不设置元空间的上限
- 使用默认的 JVM 参数，元空间不设置上限
10000
设置元空间的上限
- JVM 参数
-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
- 元空间出现 OOM
8531
Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
at com.atguigu.java.OOMTest.main(OOMTest.java:29)
3.4 如何解决OOM？
- 要解决OOM异常或heap space的异常，一般的手段是首先通过内存映像分析工具（如Eclipse Memory Analyzer）对dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）
- 内存泄漏就是有大量的引用指向某些对象，但是这些对象以后不会使用了，但是因为它们还和GC ROOT有关联，所以导致以后这些对象也不会被回收，这就是内存泄漏的问题
- 如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息，以及GC Roots引用链的信息，就可以比较准确地定位出泄漏代码的位置。
- 如果不存在内存泄漏，换句话说就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xmx与-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。
4.方法区的内部结构
4.1 方法区结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zgapKHsE-1684071932764)(JVM.assets/image-20211126201036665.png)]
《深入理解Java虚拟机》书中对方法区（Method Area）存储内容描述如下：它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cdict1Lv-1684071932765)(JVM.assets/image-20211126201054200.png)]
4.1.1 类型信息
对每个加载的类型（类class、接口interface、枚举enum、注解annotation），JVM必须在方法区中存储以下类型信息：
- 这个类型的完整有效名称（全类名=包名.类名）
- 这个类型直接父类的完整有效名（对于interface或是java.lang.Object，都没有父类）
- 这个类型的修饰符（public，abstract，final的某个子集）
- 这个类型直接接口的一个有序列表
4.1.2 域（Field）信息
- JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
域信息通俗来讲是类的成员变量- 域的相关信息包括：
- 域名称
- 域类型
- 域修饰符（public，private，protected，static，final，volatile，transient的某个子集）
4.1.3 方法（Method）信息
JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序：
- 方法名称
- 方法的返回类型（包括 void 返回类型），void 在 Java 中对应的类为 void.class
- 方法参数的数量和类型（按顺序）
- 方法的修饰符（public，private，protected，static，final，synchronized，native，abstract的一个子集）
- 方法的字节码（bytecodes）、操作数栈、局部变量表及大小（abstract和native方法除外）
- 异常表（abstract和native方法除外），异常表记录每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
代码示例
/**
* 测试方法区的内部构成
*/
public class MethodInnerStrucTest extends Object implements Comparable<String>, Serializable {
//属性
public int num = 10;
private static String str = "测试方法的内部结构";
//构造器没写
//方法
public void test1() {
int count = 20;
System.out.println("count = " + count);
}
public static int test2(int cal) {
int result = 0;
try {
int value = 30;
result = value / cal;
} catch (Exception e) {
e.printStackTrace();
}
return result;
}
@Override
public int compareTo(String o) {
return 0;
}
}
- 反编译字节码文件，并输出到文本文件中，便于查看
- 参数 -p 确保能查看 private 权限类型的字段或方法
javap -v -p MethodInnerStrucTest.class > Text.txt
类型信息
- 在运行时方法区中，类信息中记录了哪个加载器加载了该类，同时类加载器也记录了它加载了哪些类
- 从反编译文件可以看出，字节码文件记录了 MethodInnerStrucTest 继承了哪些类，实现了哪些方法
//类型信息
public class com.atguigu.java.MethodInnerStrucTest extends java.lang.Object
implements java.lang.Comparable<java.lang.String>, java.io.Serializable
域信息
- descriptor: I 表示字段类型为 Integer
- flags: ACC_PUBLIC 表示字段权限修饰符为 public
//域信息
public int num;
descriptor: I
flags: ACC_PUBLIC
private static java.lang.String str;
descriptor: Ljava/lang/String;
flags: ACC_PRIVATE, ACC_STATIC
方法信息
- descriptor: ( )V 表示方法返回值类型为 void
- flags: ACC_PUBLIC 表示方法权限修饰符为 public
- stack=3 表示操作数栈深度为 3
- locals=2 表示局部变量个数为 2 个（实力方法包含 this）
- test1( ) 方法虽然没有参数，但是其 args_size=1 ，这是因为将 this 作为了参数
public void test1();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=3, locals=2, args_size=1
0: bipush 20
2: istore_1
3: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
6: new #4 // class java/lang/StringBuilder
9: dup
10: invokespecial #5 // Method java/lang/StringBuilder."<init>":()V
13: ldc #6 // String count =
15: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
18: iload_1
19: invokevirtual #8 // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
22: invokevirtual #9 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
25: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
28: return
LineNumberTable:
line 17: 0
line 18: 3
line 19: 28
LocalVariableTable:
Start Length Slot Name Signature
0 29 0 this Lcn/sxt/java/MethodInnerStrucTest;
3 26 1 count I
4.2 域信息特殊情况
non-final 类型的类变量
- 静态变量和类关联在一起，随着类的加载而加载，他们成为类数据在逻辑上的一部分
- 类变量被类的所有实例共享，即使没有类实例时，你也可以访问它
代码示例
- 如下代码所示，即使我们把order设置为null，也不会出现空指针异常
- 这更加表明了 static 类型的字段和方法随着类的加载而加载，并不属于特定的类实例
/**
* non-final的类变量
*/
public class MethodAreaTest {
public static void main(String[] args) {
Order order = null;
order.hello();
System.out.println(order.count);
}
}
class Order {
public static int count = 1;
public static final int number = 2;
public static void hello() {
System.out.println("hello!");
}
}
程序运行结果
hello!
1
全局常量：static final
- 全局常量就是使用 static final 进行修饰
- 被声明为final的类变量的处理方法则不同，每个全局常量在编译的时候就会被分配了。
代码示例
class Order {
public static int count = 1;
public static final int number = 2;
public static void hello() {
System.out.println("hello!");
}
}
- 反编译，查看字节码指令，可以发现 number 的值已经写死在字节码文件中了
public static int count;
descriptor: I
flags: ACC_PUBLIC, ACC_STATIC
public static final int number;
descriptor: I
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
ConstantValue: int 2
4.3 运行时常量池
运行时常量池 VS 常量池
- 方法区，内部包含了运行时常量池
- 字节码文件，内部包含了常量池
- 要弄清楚方法区，需要理解清楚ClassFile，因为加载类的信息都在方法区。
- 要弄清楚方法区的运行时常量池，需要理解清楚ClassFile中的常量池。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Qa3aRw2R-1684071932765)(JVM.assets/image-20211126205259937.png)]
常量池
- 一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述符信息外
- 还包含一项信息就是常量池表（Constant Pool Table），包括各种字面量和对类型、域和方法的符号引用
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZaiT3WTJ-1684071932765)(JVM.assets/image-20211126205440354.png)]
为什么需要常量池？
- 一个java源文件中的类、接口，编译后产生一个字节码文件。而Java中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池
- 这个字节码包含了指向常量池的引用。在动态链接的时候会用到运行时常量池，之前有介绍
- 比如：如下的代码：
public class SimpleClass {
public void sayHello() {
System.out.println("hello");
}
}
- 虽然上述代码只有194字节，但是里面却使用了String、System、PrintStream及Object等结构。
- 如果不使用常量池，就需要将用到的类信息、方法信息等记录在当前的字节码文件中，造成文件臃肿
- 所以我们将所需用到的结构信息记录在常量池中，并通过引用的方式，来加载、调用所需的结构
- 这里的代码量其实很少了，如果代码多的话，引用的结构将会更多，这里就需要用到常量池了。
常量池中有什么？
- 数量值
- 字符串值
- 类引用
- 字段引用
- 方法引用
常量池代码举例
/**
* 测试方法区的内部构成
*/
public class MethodInnerStrucTest extends Object implements Comparable<String>, Serializable {
//属性
public int num = 10;
private static String str = "测试方法的内部结构";
//构造器没写
//方法
public void test1() {
int count = 20;
System.out.println("count = " + count);
}
public static int test2(int cal) {
int result = 0;
try {
int value = 30;
result = value / cal;
} catch (Exception e) {
e.printStackTrace();
}
return result;
}
@Override
public int compareTo(String o) {
return 0;
}
}
- 来看下最简单的 test1( ) 方法，带 # 的字节码指令，就使用到了常量池的引用
- 通过字节码指令可以看出，拼接字符串时，编译器帮我们造了个 StringBuilder 对象，然后调用其 append( ) 方法完成了字符串的拼接
public void test1();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=3, locals=2, args_size=1
0: bipush 20
2: istore_1
3: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
6: new #4 // class java/lang/StringBuilder
9: dup
10: invokespecial #5 // Method java/lang/StringBuilder."<init>":()V
13: ldc #6 // String count =
15: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
18: iload_1
19: invokevirtual #8 // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
22: invokevirtual #9 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
25: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
28: return
LineNumberTable:
line 17: 0
line 18: 3
line 19: 28
LocalVariableTable:
Start Length Slot Name Signature
0 29 0 this Lcn/sxt/java/MethodInnerStrucTest;
3 26 1 count I
- 常量池
Constant pool:
#1 = Methodref #18.#52 // java/lang/Object."<init>":()V
#2 = Fieldref #17.#53 // cn/sxt/java/MethodInnerStrucTest.num:I
#3 = Fieldref #54.#55 // java/lang/System.out:Ljava/io/PrintStream;
#4 = Class #56 // java/lang/StringBuilder
#5 = Methodref #4.#52 // java/lang/StringBuilder."<init>":()V
#6 = String #57 // count =
#7 = Methodref #4.#58 // java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
#8 = Methodref #4.#59 // java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
#9 = Methodref #4.#60 // java/lang/StringBuilder.toString:()Ljava/lang/String;
#10 = Methodref #61.#62 // java/io/PrintStream.println:(Ljava/lang/String;)V
#11 = Class #63 // java/lang/Exception
#12 = Methodref #11.#64 // java/lang/Exception.printStackTrace:()V
#13 = Class #65 // java/lang/String
#14 = Methodref #17.#66 // cn/sxt/java/MethodInnerStrucTest.compareTo:(Ljava/lang/String;)I
#15 = String #67 // 测试方法的内部结构
#16 = Fieldref #17.#68 // cn/sxt/java/MethodInnerStrucTest.str:Ljava/lang/String;
#17 = Class #69 // cn/sxt/java/MethodInnerStrucTest
#18 = Class #70 // java/lang/Object
#19 = Class #71 // java/lang/Comparable
#20 = Class #72 // java/io/Serializable
#21 = Utf8 num
#22 = Utf8 I
#23 = Utf8 str
#24 = Utf8 Ljava/lang/String;
#25 = Utf8 <init>
#26 = Utf8 ()V
#27 = Utf8 Code
#28 = Utf8 LineNumberTable
#29 = Utf8 LocalVariableTable
#30 = Utf8 this
#31 = Utf8 Lcn/sxt/java/MethodInnerStrucTest;
#32 = Utf8 test1
#33 = Utf8 count
#34 = Utf8 test2
#35 = Utf8 (I)I
#36 = Utf8 value
#37 = Utf8 e
#38 = Utf8 Ljava/lang/Exception;
#39 = Utf8 cal
#40 = Utf8 result
#41 = Utf8 StackMapTable
#42 = Class #63 // java/lang/Exception
#43 = Utf8 compareTo
#44 = Utf8 (Ljava/lang/String;)I
#45 = Utf8 o
#46 = Utf8 (Ljava/lang/Object;)I
#47 = Utf8 <clinit>
#48 = Utf8 Signature
#49 = Utf8 Ljava/lang/Object;Ljava/lang/Comparable<Ljava/lang/String;>;Ljava/io/Serializable;
#50 = Utf8 SourceFile
#51 = Utf8 MethodInnerStrucTest.java
#52 = NameAndType #25:#26 // "<init>":()V
#53 = NameAndType #21:#22 // num:I
#54 = Class #73 // java/lang/System
#55 = NameAndType #74:#75 // out:Ljava/io/PrintStream;
#56 = Utf8 java/lang/StringBuilder
#57 = Utf8 count =
#58 = NameAndType #76:#77 // append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
#59 = NameAndType #76:#78 // append:(I)Ljava/lang/StringBuilder;
#60 = NameAndType #79:#80 // toString:()Ljava/lang/String;
#61 = Class #81 // java/io/PrintStream
#62 = NameAndType #82:#83 // println:(Ljava/lang/String;)V
#63 = Utf8 java/lang/Exception
#64 = NameAndType #84:#26 // printStackTrace:()V
#65 = Utf8 java/lang/String
#66 = NameAndType #43:#44 // compareTo:(Ljava/lang/String;)I
#67 = Utf8 测试方法的内部结构
#68 = NameAndType #23:#24 // str:Ljava/lang/String;
#69 = Utf8 cn/sxt/java/MethodInnerStrucTest
#70 = Utf8 java/lang/Object
#71 = Utf8 java/lang/Comparable
#72 = Utf8 java/io/Serializable
#73 = Utf8 java/lang/System
#74 = Utf8 out
#75 = Utf8 Ljava/io/PrintStream;
#76 = Utf8 append
#77 = Utf8 (Ljava/lang/String;)Ljava/lang/StringBuilder;
#78 = Utf8 (I)Ljava/lang/StringBuilder;
#79 = Utf8 toString
#80 = Utf8 ()Ljava/lang/String;
#81 = Utf8 java/io/PrintStream
#82 = Utf8 println
#83 = Utf8 (Ljava/lang/String;)V
#84 = Utf8 printStackTrace
常量池总结
常量池，可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息
运行时常量池
- 运行时常量池（Runtime Constant Pool）是方法区的一部分。
- 常量池表（Constant Pool Table）是Class字节码文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
- 运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池。
- JVM为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的。
- 运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里换为真实地址。
- 运行时常量池，相对于Class文件常量池的另一重要特征是：
具备动态性。 - 运行时常量池类似于传统编程语言中的符号表（symbol table），但是它所包含的数据却比符号表要更加丰富一些。
- 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则JVM会抛OutOfMemoryError异常。
5.方法区使用举例
public class MethodAreaDemo {
public static void main(String[] args) {
int x = 500;
int y = 100;
int a = x / y;
int b = 50;
System.out.println(a + b);
}
}
图解字节码指令执行流程
- 字节码执行过程展示：初始状态
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dITwvh1h-1684071932766)(JVM.assets/image-20211126212348137.png)]
- 首先将操作数500压入操作数栈中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RO9DwC4Y-1684071932766)(JVM.assets/image-20211126212414732.png)]
- 然后将操作数 500 从操作数栈中取出，存储到局部变量表中索引为 1 的位置
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vVwgvD3H-1684071932766)(JVM.assets/image-20211126212433396.png)]
- 将操作数100压入操作数栈中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AOQXdPoG-1684071932767)(JVM.assets/image-20211126212447873.png)]
- 然后操作数 100 从操作数栈中取出，存储到局部变量表中索引为 2 的位置
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qI3GCtBv-1684071932767)(JVM.assets/image-20211126212510514.png)]
- 读取本地变量 1 ，压入操作数栈
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jnWKSVQO-1684071932767)(JVM.assets/image-20211126212527497.png)]
- 读取本地变量 2 ，压入操作数栈
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JzfPC8ci-1684071932767)(JVM.assets/image-20211126212542053.png)]
- 两数相除，计算结果放在操作数栈顶，之后执行 istore_3 指令，将计算结果从操作数栈中弹出，存入本地变量表 3 中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-01n3Tvdb-1684071932768)(JVM.assets/image-20211126212601612.png)]
- 将操作数 50 压入操作数栈
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-chFdzcHM-1684071932768)(JVM.assets/image-20211126212617327.png)]
- 将操作数 50 从栈顶弹出，保存在局部变量表 4 中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-51pCvqQ1-1684071932768)(JVM.assets/image-20211126212633724.png)]
- 获取 System.out 输出流的引用
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UISsGHRj-1684071932769)(JVM.assets/image-20211126212647706.png)]
- 将本地变量表 3 的值取出，压入操作数栈中，准备进行加法运算
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QntSFham-1684071932769)(JVM.assets/image-20211126212705125.png)]
- 将本地变量表 4 的值取出，压入操作数栈中，准备进行加法运算
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3qx8hYeo-1684071932769)(JVM.assets/image-20211126212742418.png)]
- 执行加法运算后，将计算结果放在操作数栈顶
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PvO8s4YC-1684071932769)(JVM.assets/image-20211126212802403.png)]
- 调用静态方法 println( ) ，输出加法结果
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DEKHMsCv-1684071932770)(JVM.assets/image-20211126212817059.png)]
- main( ) 方法执行结束
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jDdYqs5X-1684071932770)(JVM.assets/image-20211126212833004.png)]
关于【符号引用 --> 直接引用】的理解
- 上面代码调用 System.out.println( ) 方法时，首先需要看 System 类有没有加载，再看看 PrintStream 类有没有加载
- 如果没有加载，则执行加载，执行时，将常量池中的符号引用（字面量）转换为直接引用（真正的地址值）
关于程序计数器的说明
程序计数器始终存储的都是当前字节码指令的索引地址，目的是为了方便记录方法调用后能够正常返回，或者是进行了CPU切换后，也能回到原来的代码继续执行。
6.方法区的演进细节
6.1 永久代演进过程
- 首先明确：只有Hotspot才有
永久代。 - BEA JRockit、IBMJ9等来说，是不存在永久代的概念的。原则上如何实现方法区属于虚拟机实现细节，不受《Java虚拟机规范》管束，并不要求统一
- Hotspot中方法区的变化：
| JDK 版本 | 演变细节 |
|---|---|
| JDK1.6及以前 | 有永久代（permanent generation），静态变量存储在永久代上 |
| JDK1.7 | 有永久代，但已经逐步 “去永久代”，字符串常量池、静态变量从永久代中移除，保存在堆中 |
| JDK1.8 | 无永久代，类型信息，字段，方法，常量保存在本地内存的元空间，但字符串常量池、静态变量仍然在堆中。 |
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-G1v4FRyY-1684071932770)(JVM.assets/image-20211126213209955.png)]
JDK6
- 方法区由永久代实现，使用 JVM 虚拟机内存
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YYygaycH-1684071932770)(JVM.assets/image-20211126213241183.png)]
JDK7
- 方法区由永久代实现，使用 JVM 虚拟机内存
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eMJCEV9j-1684071932771)(JVM.assets/image-20211126213259518.png)]
JDK8及以后
- 方法区由元空间实现，使用物理机本地内存
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SbLrT7Ab-1684071932771)(JVM.assets/image-20211126213344849.png)]
6.2 永久代为什么要被元空间替代？
- 官方的牵强解释：JRockit是和HotSpot融合后的结果，因为JRockit没有永久代，所以他们不需要配置永久代，HotSpot也就取消了永久代
- 随着Java8的到来，HotSpot VM中再也见不到永久代了。但是这并不意味着类的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域，这个区域叫做元空间（Metaspace）。
由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间，这项改动是很有必要的，原因有：
- 为永久代设置空间大小是很难确定的。
- 在某些场景下，如果动态加载类过多，容易产生Perm区的OOM。比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态地加载很多类，经常出现致命错误。
Exception in thread 'dubbo client x.x connector' java.lang.OutOfMemoryError:PermGen space - 而元空间和永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。
- 在某些场景下，如果动态加载类过多，容易产生Perm区的OOM。比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态地加载很多类，经常出现致命错误。
- 对永久代进行调优是很困难的。
- 方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再用的类型，方法区的调优主要是为了降低Full GC
- 有些人认为方法区（如HotSpot虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如JDK11时期的ZGC收集器就不支持类卸载）。
- 一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏
6.3 字符串常量池
字符串常量池 StringTable 为什么要调整位置？
-
JDK7中将StringTable放到了堆空间中。因为永久代的回收效率很低，在Full GC的时候才会执行永久代的垃圾回收，而Full GC是老年代的空间不足、永久代不足时才会触发。
-
这就导致StringTable回收效率不高，而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。
6.4 静态变量位置
静态变量存放在哪里？
/**
* 结论：
* 静态变量在jdk6/7存在与永久代中，在jdk8存在于堆中 //private static byte[] arr
* 静态引用对应的对象实体始终都存在堆空间 //new byte[1024 * 1024 * 100];
*
* jdk7：
* -Xms200m -Xmx200m -XX:PermSize=300m -XX:MaxPermSize=300m -XX:+PrintGCDetails
* jdk 8：
* -Xms200m -Xmx200m -XX:MetaspaceSize=300m -XX:MaxMetaspaceSize=300m -XX:+PrintGCDetails
*/
public class StaticFieldTest {
private static byte[] arr = new byte[1024 * 1024 * 100]; //100MB
public static void main(String[] args) {
System.out.println(StaticFieldTest.arr);
}
}
- 设置JVM参数
-Xms200m -Xmx200m -XX:MetaspaceSize=300m -XX:MaxMetaspaceSize=300m -XX:+PrintGCDetails
- 通过 GC 日志可以看出：静态变量引用对应的对象实体始终都在堆空间中（arr 数组对象直接怼到老年区去了）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-woqkELF4-1684071932771)(JVM.assets/image-20211126213643360.png)]
代码示例2
/**
* 《深入理解Java虚拟机》中的案例：
* staticObj、instanceObj、localObj存放在哪里？
*/
public class StaticObjTest {
static class Test {
//静态属性
static ObjectHolder staticObj = new ObjectHolder();
//非静态属性
ObjectHolder instanceObj = new ObjectHolder();
void foo() {
//局部变量
ObjectHolder localObj = new ObjectHolder();
System.out.println("done");
}
}
private static class ObjectHolder {
}
public static void main(String[] args) {
Test test = new StaticObjTest.Test();
test.foo();
}
}
-
可以使用 JHSDB.exe，在JDK9的时候才引入的
-
分析：staticObj随着Test的类型信息存放在方法区，instanceObj随着Test的对象实例存放在Java堆，localObject则是存放在foo( )方法栈帧的局部变量表中。
-
测试发现：三个对象的数据在内存中的地址都落在Eden区范围内，所以结论：只要是对象实例必然会在Java堆中分配。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PnbMM6Zr-1684071932771)(JVM.assets/image-20211126213733621.png)]
- 接着，找到了一个引用该staticObj对象的地方，是在一个java.lang.Class的实例里，并且给出了这个实例的地址，通过Inspector查看该对象实例，可以清楚看到这确实是一个java.lang.Class类型的对象实例，里面有一个名为staticobj的实例字段：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v0prLscc-1684071932772)(JVM.assets/image-20211126213748405.png)]
- 从《Java虚拟机规范》所定义的概念模型来看，所有Class相关的信息都应该存放在方法区之中，但方法区该如何实现，《Java虚拟机规范》并未做出规定，这就成了一件允许不同虚拟机自己灵活把握的事情。JDK7及其以后版本的HotSpot虚拟机选择把静态变量与类型在Java语言一端的映射Class对象存放在一起，存储于Java堆之中，从我们的实验中也明确验证了这一点
7.方法区的垃圾回收
方法区的垃圾收集
-
有些人认为方法区（如Hotspot虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。
-
《Java虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如JDK11时期的ZGC收集器就不支持类卸载）。
-
一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前sun公司的Bug列表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。
-
方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。
7.1 方法区常量的回收
- 先来说说方法区内常量池之中主要存放的两大类常量：字面量和符号引用
- 字面量比较接近Java语言层次的常量概念，如文本字符串、被声明为final的常量值等
- 而符号引用则属于编译原理方面的概念，包括下面三类常量：
- 类和接口的全限定名
- 字段的名称和描述符
- 方法的名称和描述符
- HotSpot虚拟机对常量池的回收策略是很明确的，
只要常量池中的常量没有被任何地方引用，就可以被回收。 - 回收废弃常量与回收Java堆中的对象非常类似。（关于常量的回收比较简单，重点是类的回收）
7.2 方法区类的回收
- 判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。
- 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
- Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了
-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX：+TraceClass-Loading、-XX：+TraceClassUnLoading查看类加载和卸载信息 - 在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及 OSGi 这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。
8.运行时数据区总结
-
线程私有结构：程序计数器、虚拟机栈、本地方法栈
-
每个虚拟机栈由具体的栈帧组成，在栈帧的动态链接中，保存至对方法的引用
-
方法区在 JDK7 之前，使用永久代实现，在 JDK8 之后，使用元空间实现
-
Minor GC 针对于新生区，Major GC 针对于老年区，Full GC 针对于整个堆空间和方法区
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-60ekrjjn-1684071932772)(JVM.assets/image-20211126214129485.png)]
9.大厂面试题
百度
- 三面：说一下JVM内存模型吧，有哪些区？分别干什么的？
字节跳动
- 二面：Java的内存分区
- 二面：讲讲jvm运行时数据库区
- 什么时候对象会进入老年代？
蚂蚁金服
- Java8的内存分代改进
- JVM内存分哪几个区，每个区的作用是什么？
- 一面：JVM内存分布/内存结构？栈和堆的区别？堆的结构？为什么两个survivor区？(复制算法，碎片化)
- 二面：Eden和survior的比例分配
小米
- jvm内存分区，为什么要有新生代和老年代
京东
- JVM的内存结构，Eden和Survivor比例。
- JVM内存为什么要分成新生代，老年代，持久代。新生代中为什么要分为Eden和survivor。
天猫
- 一面：Jvm内存模型以及分区，需要详细到每个区放什么。
- 一面：JVM的内存模型，Java8做了什么改
拼多多
- JVM内存分哪几个区，每个区的作用是什么？
美团
- java内存分配
- jvm的永久代中会发生垃圾回收吗？
- 一面：jvm内存分区，为什么要有新生代和老年代？
第十章 - 对象的实例化内存布局与访问定位
1.对象的实例化
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uVweXFha-1684071932772)(JVM.assets/image-20211127183208894.png)]
1.1 大厂面试题
**美团 **
- 对象在
JVM中是怎么存储的？ - 对象头信息里面有哪些东西？
**蚂蚁金服 **
二面：java对象头里有什么?
1.2 创建对象的方式
-
new：最常见的方式、单例类中调用getInstance的静态类方法、XXXFactory的静态方法
-
Class的newInstance方法：反射的方式，在JDK9里面被标记为过时的方法，因为只能调用空参构造器，并且权限必须为 public
-
Constructor的newInstance(Xxxx)：反射的方式，可以调用空参或带参的构造器，权限没有要求
-
使用clone( )：不调用任何的构造器，要求当前的类需要实现Cloneable接口中的clone( )方法
-
使用反序列化：序列化一般用于Socket的网络传输
-
第三方库 Objenesis
1.3 创建对象的步骤
从字节码角度看待对象的创建过程
public class ObjectTest {
public static void main(String[] args) {
Object obj = new Object();
}
}
- main( ) 方法对应的字节码（后面细讲）
- 调用 new 指令后后，加载 Object 类
- 调用 Object 类的 init( ) 方法
0: new #2 // class java/lang/Object
3: dup
4: invokespecial #1 // Method java/lang/Object."<init>":()V
7: astore_1
8: return
1.3.1 判断对象对应的类是否加载、链接、初始化
-
虚拟机遇到一条new指令，首先去检查这个指令的参数能否在Metaspace的常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载，解析和初始化。（即判断类元信息是否存在）。
-
如果该类没有加载，那么在双亲委派模式下，使用当前类加载器以ClassLoader + 包名 + 类名为key进行查找对应的.class文件，如果没有找到文件，则抛出ClassNotFoundException异常，如果找到，则进行类加载，并生成对应的 Class 类对象。
1.3.2 为对象分配内存
-
首先计算对象占用空间的大小，接着在堆中划分一块内存给新对象。如果实例成员变量是引用变量，仅分配引用变量空间即可，即4个字节大小
-
如果内存规整：采用指针碰撞分配内存
- 如果内存是规整的，那么虚拟机将采用的是指针碰撞法（Bump The Point）来为对象分配内存。
- 意思是所有用过的内存在一边，空闲的内存放另外一边，中间放着一个指针作为分界点的指示器，分配内存就仅仅是把指针往空闲内存那边挪动一段与对象大小相等的距离罢了。
- 如果垃圾收集器选择的是Serial ，ParNew这种基于压缩算法的，虚拟机采用这种分配方式。一般使用带Compact（整理）过程的收集器时，使用指针碰撞。
- 标记压缩（整理）算法会整理内存碎片，堆内存一存对象，另一边为空闲区域
-
如果内存不规整
- 如果内存不是规整的，已使用的内存和未使用的内存相互交错，那么虚拟机将采用的是空闲列表来为对象分配内存。
- 意思是虚拟机维护了一个列表，记录上哪些内存块是可用的，再分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的内容。这种分配方式成为了 “空闲列表（Free List）”
- 选择哪种分配方式由Java堆是否规整所决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定
- 标记清除算法清理过后的堆内存，就会存在很多内存碎片。
1.3.3 处理并发安全问题
- 采用CAS+失败重试、区域加锁保证更新的原子性
- 每个线程预先分配TLAB — 通过设置 -XX:+/-UseTLAB参数来设置（区域加锁机制）
- 在Eden区给每个线程分配一块区域
1.3.4 初始化分配到的空间
- 所有属性设置默认值，保证对象实例字段在不赋值时可以直接使用
1.3.5 设置对象的对象头
- 将对象的所属类（即类的元数据信息）、对象的HashCode和对象的GC信息、锁信息等数据存储在对象的对象头中。这个过程的具体设置方式取决于JVM实现。
1.3.6 执行init方法进行初始化
- 在Java程序的视角看来，初始化才正式开始。初始化成员变量，执行实例化代码块，调用类的构造方法，并把堆内对象的首地址赋值给引用变量
- 因此一般来说（由字节码中跟随invokespecial指令所决定），new指令之后会接着就是执行init方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完成创建出来。
从字节码角度看待init方法
/**
* 测试对象实例化的过程
* ① 加载类元信息 - ② 为对象分配内存 - ③ 处理并发问题 - ④ 属性的默认初始化（零值初始化）
* - ⑤ 设置对象头的信息 - ⑥ 属性的显式初始化、代码块中初始化、构造器中初始化
*
* 给对象的属性赋值的操作：
* ① 属性的默认初始化 - ② 显式初始化 / ③ 代码块中初始化 - ④ 构造器中初始化
*/
public class Customer{
int id = 1001;
String name;
Account acct;
{
name = "匿名客户";
}
public Customer(){
acct = new Account();
}
}
class Account{
}
- init( ) 方法的字节码指令：
- 属性的默认值初始化：
id = 1001; - 显示初始化/代码块初始化：
name = "匿名客户"; - 构造器初始化：
acct = new Account();
- 属性的默认值初始化：
0 aload_0
1 invokespecial #1 <java/lang/Object.<init>>
4 aload_0
5 sipush 1001
8 putfield #2 <cn/sxt/java/Customer.id>
11 aload_0
12 ldc #3 <匿名客户>
14 putfield #4 <cn/sxt/java/Customer.name>
17 aload_0
18 new #5 <cn/sxt/java/Account>
21 dup
22 invokespecial #6 <cn/sxt/java/Account.<init>>
25 putfield #7 <cn/sxt/java/Customer.acct>
28 return
2.对象的内存布局
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FUvU1www-1684071932772)(JVM.assets/image-20211127192758556.png)]
2.1 对象头
对象头包含两部分：运行时元数据（Mark Word）和类型指针
- 运行时元数据
- 哈希值（HashCode），可以看作是堆中对象的地址
- GC分代年龄（年龄计数器）
- 锁状态标志
- 线程持有的锁
- 偏向线程ID
- 偏向时间戳
- 类型指针
- 指向类元数据InstanceKlass，确定该对象所属的类型。指向的其实是方法区中存放的类元信息
说明：如果对象是数组，还需要记录数组的长度
2.2 实例数据
- 说明
- 它是对象真正存储的有效信息，包括程序代码中定义的各种类型的字段（包括从父类继承下来的和本身拥有的字段）
- 规则
- 相同宽度的字段总是被分配在一起
- 父类中定义的变量会出现在子类之前（父类在子类之前加载）
- 如果CompactFields参数为true（默认为true）：子类的窄变量可以插入到父类变量的空隙
2.3 对齐填充
不是必须的，也没特别含义，仅仅起到占位符的作用
2.4 内存布局总结
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mAmDyzi1-1684071932773)(JVM.assets/image-20211127193039801.png)]
3.对象的访问定位
JVM是如何通过栈帧中的对象引用访问到其内部的对象实例呢？
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AKYkK0zq-1684071932773)(JVM.assets/image-20211127195453897.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FCzLSljw-1684071932773)(JVM.assets/image-20211127195508153.png)]
3.1 句柄访问
- 优点：reference中存储稳定句柄地址，对象被移动（垃圾收集时移动对象很普遍）时只会改变句柄中实例数据指针即可，reference本身不需要被修改
- 缺点：在堆空间中开辟了一块空间作为句柄池，句柄池本身也会占用空间；通过两次指针访问才能访问到堆中的对象，效率低
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-helSrgl5-1684071932773)(JVM.assets/image-20211127195536105.png)]
3.2 直接指针(HotSpot采用)
- 优点：直接指针是局部变量表中的引用，直接指向堆中的实例，在对象实例中有类型指针，指向的是方法区中的对象类型数据
- 缺点：对象被移动（垃圾收集时移动对象很普遍）时需要修改 reference 的值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-97CP6cBp-1684071932774)(JVM.assets/image-20211127195607065.png)]
第十一章 - 直接内存
1.直接内存概述
- 不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中定义的内存区域。
- 直接内存是在Java堆外的、直接向系统申请的内存区间。
- 来源于NIO，通过存在堆中的DirectByteBuffer操作Native内存
- 通常，访问直接内存的速度会优于Java堆。即读写性能高。
- 因此出于性能考虑，读写频繁的场合可能会考虑使用直接内存。
- Java的NIO库允许Java程序使用直接内存，用于数据缓冲区
代码示例
/**
* IO NIO (New IO / Non-Blocking IO)
* byte[] / char[] Buffer
* Stream Channel
*
* 查看直接内存的占用与释放
*/
public class BufferTest {
private static final int BUFFER = 1024 * 1024 * 1024; //1GB
public static void main(String[] args){
//直接分配本地内存空间
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(BUFFER);
System.out.println("直接内存分配完毕，请求指示！");
Scanner scanner = new Scanner(System.in);
scanner.next();
System.out.println("直接内存开始释放！");
byteBuffer = null;
System.gc();
scanner.next();
}
}
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W8Uaf8Vm-1684071932774)(JVM.assets/image-20211127203754533.png)]
- 呐，直接占用了 1G 的本地内存
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dBwshZ86-1684071932774)(JVM.assets/image-20211127204008478.png)]
- 释放后，Java程序的内存占用明显减少
2.BIO 与 NIO
非直接缓冲区（BIO）
原来采用BIO的架构，在读写本地文件时，我们需要从用户态切换成内核态
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-luIw1yVY-1684071932774)(JVM.assets/image-20211127204435178.png)]
直接缓冲区（NIO）
使用NIO时，如下图。操作系统划出的直接缓存区可以被Java代码直接访问，只有一份。NIO适合对大文件的读写操作
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RHkO6xda-1684071932775)(JVM.assets/image-20211127204509761.png)]
代码测试
public class BufferTest1 {
private static final String TO = "F:\\test\\异界BD中字.mp4";
private static final int _100Mb = 1024 * 1024 * 100;
public static void main(String[] args) {
long sum = 0;
String src = "F:\\test\\异界BD中字.mp4";
for (int i = 0; i < 3; i++) {
String dest = "F:\\test\\异界BD中字_" + i + ".mp4";
// sum += io(src,dest); //54606
sum += directBuffer(src, dest); //50244
}
System.out.println("总花费的时间为：" + sum);
}
private static long directBuffer(String src, String dest) {
long start = System.currentTimeMillis();
FileChannel inChannel = null;
FileChannel outChannel = null;
try {
inChannel = new FileInputStream(src).getChannel();
outChannel = new FileOutputStream(dest).getChannel();
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_100Mb);
while (inChannel.read(byteBuffer) != -1) {
byteBuffer.flip(); //修改为读数据模式
outChannel.write(byteBuffer);
byteBuffer.clear(); //清空
}
} catch (IOException e) {
e.printStackTrace();
} finally {
if (inChannel != null) {
try {
inChannel.close();
} catch (IOException e) {
e.printStackTrace();
}
}
if (outChannel != null) {
try {
outChannel.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
long end = System.currentTimeMillis();
return end - start;
}
private static long io(String src, String dest) {
long start = System.currentTimeMillis();
FileInputStream fis = null;
FileOutputStream fos = null;
try {
fis = new FileInputStream(src);
fos = new FileOutputStream(dest);
byte[] buffer = new byte[_100Mb];
while (true) {
int len = fis.read(buffer);
if (len == -1) {
break;
}
fos.write(buffer, 0, len);
}
} catch (IOException e) {
e.printStackTrace();
} finally {
if (fis != null) {
try {
fis.close();
} catch (IOException e) {
e.printStackTrace();
}
}
if (fos != null) {
try {
fos.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
long end = System.currentTimeMillis();
return end - start;
}
}
深入 ByteBuffer 源码
- ByteBuffer.allocateDirect( ) 方法
public static ByteBuffer allocateDirect(int capacity) {
return new DirectByteBuffer(capacity);
}
- DirectByteBuffer 类的构造器用到了 Unsafe 类分配本地内存
DirectByteBuffer(int cap) { // package-private
super(-1, 0, cap, cap);
boolean pa = VM.isDirectMemoryPageAligned();
int ps = Bits.pageSize();
long size = Math.max(1L, (long)cap + (pa ? ps : 0));
Bits.reserveMemory(size, cap);
long base = 0;
try {
base = unsafe.allocateMemory(size);
} catch (OutOfMemoryError x) {
Bits.unreserveMemory(size, cap);
throw x;
}
unsafe.setMemory(base, size, (byte) 0);
if (pa && (base % ps != 0)) {
// Round up to page boundary
address = base + ps - (base & (ps - 1));
} else {
address = base;
}
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
att = null;
}
3.直接内存与OOM
- 直接内存也可能导致OutofMemoryError异常
- 由于直接内存在Java堆外，因此它的大小不会直接受限于-Xmx指定的最大堆大小，但是系统内存是有限的，Java堆和直接内存的总和依然受限于操作系统能给出的最大内存。
- 直接内存的缺点为：
- 分配回收成本较高
- 不受JVM内存回收管理
- 直接内存大小可以通过MaxDirectMemorySize设置
- 如果不指定，默认与堆的最大值-Xmx参数值一致
代码示例
/**
* 本地内存的OOM: OutOfMemoryError: Direct buffer memory
*/
public class BufferTest2 {
private static final int BUFFER = 1024 * 1024 * 20; //20MB
public static void main(String[] args) {
ArrayList<ByteBuffer> list = new ArrayList<>();
int count = 0;
try {
while(true){
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(BUFFER);
list.add(byteBuffer);
count++;
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
} finally {
System.out.println(count);
}
}
}
- 本地内存持续增长，直至程序抛出异常：java.lang.OutOfMemoryError: Direct buffer memory
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Yfv5KOBV-1684071932775)(JVM.assets/image-20211127204954757.png)]
代码示例2
- 直接通过 Unsafe 类申请本地内存
/**
* -Xmx20m -XX:MaxDirectMemorySize=10m
*/
public class MaxDirectMemorySizeTest {
private static final long _1MB = 1024 * 1024;
public static void main(String[] args) throws IllegalAccessException {
Field unsafeField = Unsafe.class.getDeclaredFields()[0];
unsafeField.setAccessible(true);
Unsafe unsafe = (Unsafe)unsafeField.get(null);
while(true){
unsafe.allocateMemory(_1MB);
}
}
}
- 设置JVM 参数
-Xmx20m -XX:MaxDirectMemorySize=10m
- 抛出 OOM 异常
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FX4XH9HR-1684071932775)(JVM.assets/image-20211127205045025.png)]
JDK8 中元空间直接使用本地内存
- java程序进程所占的内存空间 = 本地内存 + 堆空间
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-saP1lRU2-1684071932776)(JVM.assets/image-20211127205546273.png)]
第十二章 - 执行引擎
1.执行引擎概述
执行引擎属于JVM的下层，里面包括解释器、及时编译器、垃圾回收器
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aAtGKh9H-1684071932776)(JVM.assets/image-20211128095512285.png)]
-
执行引擎是Java虚拟机核心的组成部分之一。
-
’虚拟机‘是一个相对于’物理机‘的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的，而
虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执行引擎的结构体系，能够执行那些不被硬件直接支持的指令集格式。 -
JVM的主要任务是负责 装载字节码到其内部，但是字节码并不能够直接运行在操作系统之上，因为字节码指令并非等价于本地机器指令，它内部包含的仅仅只是一些能够被JVM所识别的字节码指令、符号表、以及其他辅助信息
-
那么如果想要一个Java程序运行起来，执行引擎（Execution Engine）的任务就是 将字节码指令解释/编译为对应平台的本地机器指令才可以，简单来说JVM的执行引擎充当了高级语言翻译为机器语言的译者
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DuPu79XN-1684071932776)(JVM.assets/image-20211128101108667.png)]
1.1执行引擎的工作流程
-
执行引擎在执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器。
-
每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址。
-
当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息。
-
从外观上来看，所有的Java虚拟机的执行引擎的输入、输出都是一致的：输入的是字节码二进制流，处理过程是字节码解析执行的等效流程，输出的是执行结果
2.Java代码编译和执行过程
- 大部分的程序代码转换成物理机的目标代码或者虚拟机能执行的指令集之前，都需要经过下图的各个步骤。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5JOp8P1T-1684071932776)(JVM.assets/image-20211128102730844.png)]
- Java代码编译是由Java源码编译器（前端编译器）来完成，流程图如下所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tqNs1tgX-1684071932776)(JVM.assets/image-20211128103301556.png)]
- Java字节码的执行是由JVM执行引擎（后端编译器）来完成，流程图 如下所示
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WTQAMut0-1684071932777)(JVM.assets/image-20211128103358383.png)]
问题：什么是解释器（Interpreter），什么是JIT编译器
- 解释器：当Java虚拟机启动的时候会根据预定义的规范 对字节码采用逐行解释的方式执行，将每条字节码文件中的内容“翻译”为对应平台的本地机器指令执行
- JIT（Just In Time Compiler）编译器：就是虚拟机将源代码直接编译成和本地机器平台相关的机器语言
问题：为什么说Java是半编译半解释型语言
- JDK1.0时代，将Java语言定义为“解释执行”还是比较准确的，再后来Java也发展出可以直接生成本地代码的编译器
- 现在JVM在执行Java源码的时候，通常都会将解释执行和编译执行二者结合起来进行。
3.机器码、指令、汇编语言
机器码指令、汇编、高级语言的理解与执行过程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nEGnukJD-1684071932777)(JVM.assets/image-20211128104843998.png)]
3.1机器语言 (机器码)
3.1.1机器码
- 各种用二进制编码的方式表示的指令，叫做机器指令码。开始，人们就用它编写程序，这就是机器语言
- 机器语言虽然能够被计算机理解和接受，但是和人们的语言差别太大，不容易被人们理解和记忆，并且用它编程容易出差错
- 用它编写的程序一经输入到计算机，CPU直接读取执行，因此和其他语言编写的程序相比，执行速度最快
- 机器指令与CPU紧密相关，所以不同种类的CPU所对应的机器指令也就不同
3.1.2指令
- 由于机器码是由0和1组成的二进制序列，可读性实在太差，于是人们发明了指令
- 指令就是把机器码中特定的0和1序列，简化成相应的指令（一般使用英文简写，如mov，inc等），可读性稍好
- 由于不同的硬件平台，执行同一个操作，对应的机器码可能不同，所以不同的硬件平台的同一种指令（如mov）对应的机器码也不同
3.1.3指令集
- 不同的硬件平台，各自支持的指令，是有差别的。因此每个平台所支持的指令，称之为对应平台的指令集
- 常见的
- x86指令集，对应的是x86架构的平台
- ARM指令集，对应的是ARM架构的平台
3.2汇编语言
-
由于机器指令的可读性还是太差，于是人们有发明了汇编语言
-
在汇编语言中，用助记符（Mnemonics）代替机器指令的操作码，用地址符号（Symbol）或者标号（Label）代替指令操作数的地址
-
在不同的硬件平台，汇编语言对应着不同的机器语言指令集，通过汇编过程转称机器指令
- 由于计算机只认识指令码，所以用汇编语言编写的程序还必须翻译成机器指令码。计算机才能识别和执行
3.3高级语言
- 为了使得计算机用户编程序更容易一些，后来就出现了各种高级计算机语言，高级语言比机器语言、汇编语言更接近人的语言
- 当计算机执行高级语言编写程序的时候，仍然需要将程序解释和编译成机器的指令码。完成这个过程的程序就叫做解释程序或者编译程序
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XkvQt2BI-1684071932777)(JVM.assets/image-20211128140012344.png)] C/C++源程序执行过程
3.4字节码
- 字节码是一种中间状态（中间码）的二进制代码（文件），它比机器码更抽象，需要直译器转译之后才能成为机器码
- 字节码主要是为了实现特定软件运行和软件环境、与硬件环境无关
- 字节码的实现方式是通过编译器和虚拟机器，编译器将源码编译成字节码，特定平台上的虚拟机器将字节码转译为可以执行的命令
- 字节码的典型应用就是 ByteCode
4.解释器
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-akYrUltL-1684071932778)(JVM.assets/image-20211128143139906.png)]
- JVM的设计者们的初衷仅仅只是单纯的为了满足Java程序的跨平台性，因此避免采用静态编译的方式直接生成本地机器指令，从而诞生了实现解释器在运行时采用逐行解释字节码执行程序的想法
解释器工作机制（或工作任务）
- 解释器真正意义上所承担的角色就是一个运行时“翻译者”，将字节码文件中的内容“翻译”为对应平台的本地机器指令执行
- 当一条字节码指令被解释执行完成之后，接着再根据PC寄存器中记录的下一条需要被执行的字节码指令执行解释操作
解释器的分类
- 在Java发展历史里，一共有两套解释执行器，即古老的字节码解释器、现在普遍使用的是模板解释器
- 字节码解释器在执行时通过纯软件代码，模板字节码的执行，效率非常地下
- 而模板解释器将 每一条字节码和一个模板函数相关联，模板函数中直接产生这条字节码执行的机器码。从而很大程度上提高了解释器的性能
- 在Hotspot VM中，解释器主要由Interpreter模块和Code模块构成
- Interpreter模块：实现了解释器的核心功能
- Code模块：用于管理Hotspot VM 在运行时生成的本地机器指令
- 在Hotspot VM中，解释器主要由Interpreter模块和Code模块构成
现状
- 由于解释器在设计上和实现上非常简单，因此除了 Java之外，其他语言也基于解释器执行。但是今天 基于解释器执行已经沦落为低效的代名词
- 为了解决这个问题，JVM平台支持一种即时编译的技术。即时编译的目的是避免函数被解释执行，而是将整个函数体编译成机器码吗，每次该函数执行的时候，只执行编译后的机器码即可，这种方式可以使得执行效率大幅度提升
5.JIT编译器
-
Hotspot虚拟机是目前市面上高性能虚拟机的代表之一。它是采用解释器和即时编译器并存的架构，在其运行的时候，会找到解释器和即时编译器相互合作的节点。各自取长补短。
-
今天，Java的运行性能已经可以和C/C++程序一教高下的地步
-
既然Hotspot VM中已经内置了JIT编译器了，那么为啥还需要再使用解释器来“拖累”程序的执行性能呢？比如JRrockit VM 就不包含解释器，字节码全部依靠即时编译后执行 - 所以它号称最快的虚拟机
-
首先明确
- 当程序启动的时候，解释器可以马上发挥作用，省去编译的时间，立即执行，编译器想要发挥作用，把代码编译为本地代码，需要一定的时间。但是编译为本地代码后，执行效率高
- 所以，JRockit 虚拟机执行性能很高，但是再启动的时候会会花费更多的时间
- 所以Hotspot虚拟机，都进行使用，当虚拟机启动的时候，解释器首先发生作用，不必等待即时编译器全部编译完再执行，这样可以省去不必要的编译时间。随着时间的推移，越来越多的热点代码被编译为机器指令代码，所以程序执行会越来越快
5.1 概念解释
- Java语言得“编译期”其实是一段“不确定”得操作过程，因为它可能是指一个前端编译器（其实也叫 编译器的前端）把 .java 文件转换成 .class 文件的过程
- 也可能是指后端运行编译器（JIT编译器 Just In Time Compiler） 把字节码转换为机器码的过程
- 还可能是使用 静态提前编译器（AOT编译器 Ahead Of Time Compiler）直接把 .java 文件编译成本地机器码的过程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qb4vLqGn-1684071932778)(JVM.assets/image-20211128143627425.png)]
5.2 热点代码以及探测方式
-
当然是否需要启动JIT编译器将字节码直接编译为对应平台的本地机器指令，则需要根据代码被调用 执行的频率 而定。这样的被编译为本地代码的字节码，称为热点代码，JIT编译器再运行时会针对哪些被频繁调用的“热点代码”做出深度优化 将其直接编译为对应平台的本地机器指令，以提升Java程序的执行性能
-
一个被多次调用的方法，或者是一个方法体内部循环次数比较多的循环体都可以称为是热点代码，因此都可以通过JIT编译器翻译为本地机器指令，由于这种编译方式发生在方法的执行过程中，因此也被称为栈上替换。或者简称为 OSR（On Stack Replacement）
-
一个方法究竟要调用多少次，或者一个循环体究竟循环多少次，才会达到这个标准？肯定需要一个明确的阈值，JIT才会编译之为本地代码。这里主要依赖 热点探测功能
-
目前Hotspot VM 采用热点探测方式是基于计数器的热点探测
-
采用计数器的热点探测，Hotspot VM 将会为每一个方法都建立2个不同类型的计数器，分别为方法调用计数器，分别为方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）
- 方法回调计数器用于传统统计方法的调用次数
- 回边计数器则用于统计循环体执行的循环次数
5.2.1方法调用计数器
- 这个计数器就是用于统计方法被调用的次数，它的默认阈值再 Client 模式下是1500次，再Server下是10000次，超过这个阈值，就会触发JIT编译
- 这个阈值可以通过虚拟机参数 -XX:ComplieThreshold 来设定
- 当一个方法被调用的时候，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行，如果不存在已经被编译的版本，则将此方法的调用计数器值加1，然后判断 方法调用计数器和回边调用计数器之和是否超过方法调用计数器的阈值，如果超过，就向编译器提交一个该方法的编译请求
热度衰减
- 如何不做任何设置，方法调用计数器统计的不是被调用的绝对次数，而是一个相对的执行频率。即 一段时间之内方法被调用的次数 当超过 一定的时间限制，如果调用的次数不足，就可以将他转交给即时编译器编译，哪这个方法的调用计数器就会减少一半，这个过程就是调用计数器热度的衰减（Counter Decay），而这段时间就称为次方法统计的半衰周期（Counter Half Life Time）
- 进行热度衰减的动作，是再虚拟机内部垃圾收集的时候顺便执行的，可以使用虚拟机参数 -XX:-UseCouinterDecay关闭
- 可以使用 -XX:CounterHalfLifeTime 参数设置半衰周期的时间，单位是秒
5.2.2回边计数器
- 统计方法中循环 体代码的执行次数，建立回边计数器统计就是为了触发 OSR 编译
5.3 Hotspot VM 可以设置程序的执行方式
- 缺省情况下 Hotspot 虚拟机使用解释器与编译器并存的架构，开发人员也可以对齐进行调整，设置为完全采用解释器或者完全采用即时编译器
- -Xint:完全采用解释器模式执行程序
- -Xcomp:完全采用即时编译器模式执行程序，如果编译出现问题，解释器会介入
- -Xmixed:采用解释器+即时编译器混合模式执行程序
使用cmd可以切换执行模式：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rohgsx5I-1684071932778)(JVM.assets/image-20211128154724687.png)]
代码示例
public class IntCompTest {
public static void main(String[] args) {
long start = System.currentTimeMillis();
testPrimeNumber(1000000);
long end = System.currentTimeMillis();
System.out.println("花费的时间为:"+ (end -start));
}
private static void testPrimeNumber(int count) {
for (int i = 0; i < count; i ++){
// 计算100以内的质数
label:for (int j = 2; j <= 100 ; j++) {
for (int k = 2; k < Math.sqrt(j); k++) {
if (j % k == 0){
continue label;
}
}
}
}
}
}
JVM参数（解释器模式）
VM options:-Xint
- 结果
花费的时间为:4658
JVM参数（编译器模式）
VM options:-Xcomp
- 结果
花费的时间为:695
JVM参数（解释编译混合的模式）
VM options:-Xmixed
- 结果
花费的时间为:627
5.4 Hotspot VM 中JIT分类
- 在Hotspot VM 内嵌两个JIT编译器，分别为 Client / Server Compiler 但是大多数情况下我们称之为 C1编译器和C2编译器，可以设置使用哪一种编译器
- -client 使用c1编译器
- C1编译器会对字节码进行 简单和可靠的优化，耗时短 以达到更快的编译速度
- -server 使用c2 编译器
- C2进行 耗时较长的优化，以及激进优化 但是优化的代码执行效率高
5.5 C1和C2编译器不同的优化策略
- 在不同的编译器上有不同的优化策略
- C1编译器有方法内联，去虚拟化、冗余消除
- 方法内联：将引用的函数代码编译道引用点处，这样就可减少栈帧的生成，减少参数的传递和跳转过程
- 去虚拟化：对唯一的实现类进行内联
- 冗余消除：在运行期间会把一些不会执行的代码折叠掉
- C2的优化主要是在全局层面，逃逸分析师优化的基础，基于逃逸分析在C2上有如下几种优化
- 标量替换：用标量替换聚合变量
- 栈上分配：对于为逃逸的对象分配对象的在栈而不是在堆
- 同步消除：清除同步动作，通常指的是synchronized
- 分层编译（Tiered Compiler）策略
- 程序解释执行（不开启性能监控）可以触发C1，将字节码编译成机器码，可以进行简单优化，也可加上性能优化，C2编译会根据性能监控信息进行激进优化
- 不过在Java7版本之后，一旦开发人员在程序中显示指定命令 "-server"时，默认开启，使用c1和c2共同执行
总结
- 一般来讲，JIT编译器出来的机器码性能比解释器高
- C2编译器启动时长比C1编译器慢，系统稳定执行以后，C2编译器执行速度远远快于C1编译器
5.6 Graal编译器与AOT编译器
5.6.1 Graal编译器
- 在JDK10之后，Hotspot又加入了一个全新的即时编译器：Graal 编译器
- 编译效果短短几年就追平了C2编译器
- 目前还在实验阶段
- -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler去激活才能使用
5.6.2 AOT编译器
-
JDK9.0 之后加入了AOT编译器（静态提前编译器 Ahead Of Time Compiler）
-
JDK9 引入了实验性的 AOT 编译工具 jaotc ，它借助了 Graal 编译器。将所输入的Java类文件转换为机器码，并存放道生成的动态共享库中
-
所谓的AOT编译器 时与即时编译器对立的一个概念，即时编译器在程序运行的时候，而AOT编译器是在程序运行之前
-
最大好处：可以直接执行，不必等程序预热，减少第一次运行慢的体验
-
缺点：
- 破坏了 Java”一次编译，到处运行“，因为直接编译之后的文件是固定的，必须为每种系统都编译
- 降低了Java动态链接的动态性，加载的代码在编译器期就必须全部已知
- 还需要继续优化中，最初只支持Linux x64 java base
第十三章 - StringTable
1.String的基本特性
- String:字符串，使用一对""引起来表示
- String s1 = “hello”;
- String s2 = new String(“hello”);
- String：声明为final的，不可被继承
- String 实现了Serializable接口：表示字符串是支持序列化的，实现了Comparable接口：表示String可以比较大小
- 在JDK8以及之前，String内部定义了final char[] value 用来存储字符串数据，JDK9之后使用 byte[]
源码
jdk1.8
public final class String
implements java.io.Serializable, Comparable<String>, CharSequence {
private final char value[];
.....
}
jdk1.9
public final class String
implements java.io.Serializable, Comparable<String>, CharSequence {
@Stable
private final byte[] value;
.....
}
同时基于String的数据结构，例如StringBuffer和StringBuilder也同样做了修改
1.1为什么JDK9改变了结构
-
String类的当前实现将字符存储在char数组中，每个字符使用两个字节(16位)。从许多不同的应用程序收集的数据表明，字符串是堆使用的主要组成部分，而且，大多数字符串对象只包含拉丁字符。这些字符只需要一个字节的存储空间，因此这些字符串对象的内部char数组中有一半的空间将不会使用。
-
我们建议改变字符串的内部表示clasš从utf - 16字符数组到字节数组+一个encoding-flag字段。新的String类将根据字符串的内容存储编码为ISO-8859-1/Latin-1(每个字符一个字节)或UTF-16(每个字符两个字节)的字符。编码标志将指示使用哪种编码。
✡️ 结论：String再也不用char[] 来存储了，改成了byte [] 加上编码标记，节约了一些空间
1.2String的不可变的特性
-
String：代表不可变的字符序列。简称：不可变性
- 当对字符串重新赋值的时候，需要重写指定内存区域赋值，而不是修改原有的value进行赋值
- 不能对现有的字符串进行连接操作，也需要重新指定内存区域，不是修改原有的value进行赋值
- 当调用String的replace()方法修改指定字符或者字符串的时候，也需要重新指定内存区域赋值，不能使用原有的value赋值
-
通过字面量的方式（区别于new）给一个字符串赋值，此时的字符串声明在常量池中
代码示例
/**
* @Description: String的基本使用 体现String的不可变性
* @author: JC
* @date: 2021/11/29 13:06
*/
public class StringTest3 {
@Test
public void test1(){
String s1 = "abc";// 字面量定义的方式，“abc”存储在字符串常量池中
String s2 = "abc";//
s1 = "hello";
System.out.println(s1 == s2);// 判断地址:true (s1=“hello”的注释前) --->false
System.out.println(s1);// hello
System.out.println(s2);// abc
}
@Test
public void test2(){
String s1 = "abc";
String s2 = "abc";
s2 += "def";
System.out.println(s2);// abcdef
System.out.println(s1);// abc
}
@Test
public void test3(){
String s1 = "abc";
String s2 = s1.replace('a', 'm');
System.out.println(s1); // abc
System.out.println(s2); // mbc
}
}
面试题
public class StringExer {
String str = new String("good");
char[] ch = {'t','e','s','t'};
public void change(String str, char ch[]){
str = "test ok";
ch[0] = 'b';
}
public static void main(String[] args) {
StringExer ex = new StringExer();
ex.change(ex.str,ex.ch);
System.out.println(ex.str);//
System.out.println(ex.ch);//
}
}
- 输出结果
good
best
1.3字符串常量池中是不会存储相同内容的字符串的
-
String的String Pool 是一个固定大小的HashTable 默认长度为1009，如果放进去String Pool 的String非常多，就会造成Hash冲突严重，从而导致链表很长，而链表长了之后，会直接影响调用 String.intern()的性能
-
使用 -XX:StringTableSize 可设置StringTable的长度
-
在JDK6中的StringTable是固定的，就是1009的长度，如果字符串常量池中的字符串过多就会导致效率下降很快，StirngTableSize设置没有要求
-
在JDK7中，StringTable的默认长度为 60013，设置没有要求
-
JDK8开始1009 是可设置的最小值
-
Stirng#intern()方法：如果字符串常量池中没有对应的字符串的话，就添加在常量池
2.String的内存分配
-
在Java语言中有8种基本数据类型和String，这些类型为了使它们在运行速度中更快，更节省内存。都提供了常量池
-
常量池就相似于一个Java系统级别提供的缓存。8中基本类型都是系统协调的，
String类型的常量池比较特殊，主要的使用方法有2种- 直接使用双引号声明String的对象会直接存储在常量池种中
- 比如： String info = “xinxin.com”;
- 如果不是使用双引号声明的String对象，可以使用String提供的intern() 方法。（这个后面详谈）
- 直接使用双引号声明String的对象会直接存储在常量池种中
-
在JDK6以及以前，字符串常量池存放在永久代
-
JDK7种Oracle对字符串池的逻辑做了很大的改变，将
字符串常量池的位置调整到Java堆内- 所有的字符串都保存在堆中，和其他普通对象一样，这样可以让你在进行调优的时候仅仅需要调整堆大小就可以了
- 字符串常量池的概念原本使用的比较多，但是这个改动使得我们有足够的理由考虑使用String.intern();
-
Java8元空间，字符串常量在堆
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Go10rslb-1684071932779)(JVM.assets/image-20211129145751583.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-inNKrE1E-1684071932779)(JVM.assets/image-20211129145811642.png)]
2.1 StringTable为什么需要调整到堆中
-
之前的永久代比较小，放大量的字符串，会占用很大的空间
-
永久代垃圾回收的频率很低
-
Java语言规范要求完全相同的字符字面常量，应该包含同样的Unicode字符序列，并且必须是指向同一个String类实例
代码示例
/**
*
* jdk6中：
* -XX:PermSize=6m -XX:MaxPermSize=6m -Xms6m -Xmx6m
*
* jdk8中：
* -XX:MetaspaceSize=6m -XX:MaxMetaspaceSize=6m -Xms6 -Xmx6m
*
* @author: JC
* @date: 2021/11/29 13:06
*/
public class StringTest4 {
public static void main(String[] args) {
// 使用Set保存着常量池引用，避免full GC回收常量池行为
HashSet<String> set = new HashSet<>();
// 在short可以取值的范围内足以让6MB的PermSize或heap产生OOM了
short i = 0;
while (true){
set.add(String.valueOf(i++).intern());
}
}
}
JVM配置
jdk6中：
-XX:PermSize=6m -XX:MaxPermSize=6m -Xms6m -Xmx6m
- 结果
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YKzFW8HE-1684071932779)(JVM.assets/image-20211129150945542.png)]
JVM配置
jdk8中：
-XX:MetaspaceSize=6m -XX:MaxMetaspaceSize=6m -Xms6 -Xmx6m
- 结果
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MznjuLGW-1684071932780)(JVM.assets/image-20211129151113518.png)]
3.String的基本操作
-
Java语言规范要求完全相同的字符字面常量，应该包含同样的Unicode字符序列，并且必须是指向同一个String类实例
-
前面的数在常量池中存在了，相同的字符输出也不会增加常量池中的个数
**代码示例 **
public class StringTest4 {
public static void main(String[] args) {
System.out.println();//2236 一开始就由这么多字符串 常量池中字符串的个数
System.out.println("1");//2237 换行+1
System.out.println("2");//2238
System.out.println("3");
System.out.println("4");
System.out.println("5");
System.out.println("6");
System.out.println("7");
System.out.println("8");
System.out.println("9");
System.out.println("10");//2346
// 如下的字符串"1"到"10" 不会再次加载
System.out.println("1");//2347
System.out.println("2");//2347
System.out.println("3");//2347
System.out.println("4");
System.out.println("5");
System.out.println("6");
System.out.println("7");
System.out.println("8");
System.out.println("9");
System.out.println("10");//2347
}
}
代码示例2
public class Memory {
public static void main(String[] args) {
int i = 1; //line 2
Object obj = new Object();//line 3
Memory mem = new Memory();//line 4
mem.foo(obj);//line 5
}//line 9
public void foo(Object param) {//line 6
String str = param.toString();// line 7
System.out.println(str);
}// line 8
}
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s9iolWE9-1684071932780)(JVM.assets/image-20211129153318300.png)]
4.字符串拼接操作
常量与常量的拼接结果在常量池，原理是编译期优化- 常量池中不会存在相同内容的常量
只要其中有一个是变量，结果就在堆中。变量拼接的原理是StringBuilder- 如果拼接的结果调用intern()方法，则主动将常量池中还没有的字符串对象放入池中，并返回此对象的地址
代码示例（编译期优化）
/**
* @Description:字符串拼接操作-----编译期优化
* @author: JC
* @date: 2021/11/29 15:40
*/
public class StringTest5 {
@Test
public void test1(){
String s1 = "a" + "b" + "c";//等同于"abc"
String s2 = "abc";//“abc”一定是放在字符串常量池中，将此地址赋给s2
/**
* 最终.java编译成.class，再执行.class
* String s1 = "abc";
* String s2 = "abc";
*/
System.out.println(s1 == s2);// true
System.out.println(s1.equals(s2));// true
}
}
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ACsUyDJG-1684071932780)(JVM.assets/image-20211129154648829.png)]
代码示例2
@Test
public static void test2() {
String s1 = "javaEE";
String s2 = "hadoop";
String s3 = "javaEEhadoop";
String s4 = "javaEE" + "hadoop"; //编译期优化
// 如果拼接符号的前后出现了变量，则相当于在堆空间中new String,具体的内容为拼接的结果：javaEEhadoop
String s5 = s1 + "hadoop";
String s6 = "javaEE" + s2;
String s7 = s1 + s2;
System.out.println(s3 == s4); // true
System.out.println(s3 == s5); // false
System.out.println(s3 == s6); // false
System.out.println(s3 == s7); // false
System.out.println(s5 == s6); // false
System.out.println(s5 == s7); // false
System.out.println(s6 == s7); // false
// intern()：判断字符串常量池中是否存在"javaEEhadoop"值，如果存在，则返回常量池中"javaEEhadoop"的地址；
//如果字符串常量池不存在"javaEEhadoop"，则在字符串常量池中加载一份"javaEEhadoop",并返回对象地址
String s8 = s6.intern();
System.out.println(s3 == s8); // true
}
代码示例3
- 先创建一个StringBuilder ,把局部变量表中索引为1取出使用StringBuilder.append（）
- 然后把局部变量表中索引为2的取出来再使用append()
- 最后再进行toString();
@Test
public void test3(){
String s1 = "a";
String s2 = "b";
String s3 = "ab";
String s4 = s1 + s2 ;//
System.out.println(s3 == s4);//false
}
s1+s2的执行细节：(变量s是自己临时定义的)
①StringBuilder s = new StringBuilder();
②s.append("a");
③s.append("b");
④s.toString() --> 约等于 new String("ab");
补充：在jdk5.0之后使用StringBuilder ，在jdk5.0之前使用的是StringBuffer
- 对应字节码
0 ldc #14 <a>
2 astore_1
3 ldc #15 <b>
5 astore_2
6 ldc #16 <ab>
8 astore_3
9 new #9 <java/lang/StringBuilder> // 创建StringBuilder
12 dup
13 invokespecial #10 <java/lang/StringBuilder.<init> : ()V>
16 aload_1
17 invokevirtual #11 <java/lang/StringBuilder.append : (Ljava/lang/String;)Ljava/lang/StringBuilder;>
20 aload_2
21 invokevirtual #11 <java/lang/StringBuilder.append : (Ljava/lang/String;)Ljava/lang/StringBuilder;>
24 invokevirtual #12 <java/lang/StringBuilder.toString : ()Ljava/lang/String;>
27 astore 4
29 getstatic #3 <java/lang/System.out : Ljava/io/PrintStream;>
32 aload_3
33 aload 4
35 if_acmpne 42 (+7)
38 iconst_1
39 goto 43 (+4)
42 iconst_0
43 invokevirtual #4 <java/io/PrintStream.println : (Z)V>
46 return
字符串拼接一定是StringBuilder的吗
不是
代码示例4
-
字符串拼接操作不一定都是使用StringBuilder
-
如果拼接符号左右两边都是字符串常量或常量引用，则任然使用编译器优化，既非StringBuilder的方式。
-
针对于final修饰类、方法、基本数据类型、引用数据类型的量的结构时，能使用上final的时候建议使用上。
@Test
public void test4(){
final String s1 = "a";
final String s2 = "b";
String s3 = "ab";
String s4 = s1 + s2;
System.out.println(s3 == s4);// true
}
练习:
@Test
public void test5(){
String s1 = "javaEEhadoop";
String s2 = "javaEE";
String s3 = s2 + "hadoop";
System.out.println(s1 == s3);//
final String s4 = "javaEE";//s4:常量
String s5 = s4 + "hadoop";
System.out.println(s1 == s5);
}
- 答案
System.out.println(s1 == s3);//false
System.out.println(s1 == s5);//true
代码案例5
-
method1方法会创建100000个Stringbuilder和String 所以性能低
-
通过StringBuilder的append（）的方式添加字符串的效率要远高于使用String的字符串拼接方式！
-
详情StringBuilder的append的方式：
- 自始至终只创建过一个StringBuilder对象
-
使用String的字符串拼接方式：
- 创建过多个StringBuilder和String的对象
- 内存中由于创建了较多的StringBuiler和String的对象，内存占用更大;如果进行GC，需要花费额外的时间。
-
该进的空间：再实际开发中，如果基本确定要前前后后添加的字符串长度不高于某个限定值highLevel的情况下，建议使用如下构造器实例化:
StringBuilder s = new StringBuilder(highLevel);//new char[highLevel]
-
@Test
public void test6(){
long start = System.currentTimeMillis();
//method1(100000); // 花费的时间为:4470
method2(100000);//花费的时间为:5
long end = System.currentTimeMillis();
System.out.println("花费的时间为:"+(end - start));
}
public void method1(int highLevel){
String src = "";
for (int i = 0; i < highLevel; i++) {
src = src + "a";// 每次循环都会创建一个StringBuilder、String
}
}
public void method2(int highLevel){
// 只创建一个StringBuilder
StringBuilder src = new StringBuilder(highLevel);
for (int i = 0; i < highLevel; i++) {
src.append("a");// 每次循环都会创建一个StringBuilder
}
}
5.intern()的使用
5.1iniern()概述
intern是一个native方法，调用的是底层C的方法
尽管在输出中调用intern方法并没有什么效果，但是实际上后台这个方法会做一系列的动作和操作。在调用”ab”.intern()方法的时候会返回”ab”，但是这个方法会首先检查字符串池中是否有”ab”这个字符串，如果存在则返回这个字符串的引用，否则就将这个字符串添加到字符串池中，然会返回这个字符串的引用。
- 如果不是双引号声明的String对象，可以使用String提供的intern方法：intern方法会从字符串常量池中查询当前字符串是否存在，若不存在，就会将当前字符串放入常量池中
- String myInfo = new String(“icanci.cn”).intern();
- 也就是说，如果在任意字符串上调用String.intern方法，那么其返回结果所指向的哪个类实例，必须和直接以常量形式出现的字符串实例完全相同。因此，下列表达式的值必为true
- (“a”+“b”+“c”).intern() == “abc”
- 通俗点讲，Interned String 就是确保字符串在内存中只有一份拷贝，这样可以节约内存空间，加快字符串操作任务的执行速度。注意：这个值会被存放在字符串内部池（String Intern Pool）
5.2 intern()例题实战
如何保证变量s指向的是字符串常量池中的数据呢？
-
有两种方式：
-
方式一： String s = “jc.com”//字面量定义的方式
-
方式二： 调用intern()
-
String s = new String("jc.com").intern(); -
String s = new StringBuilder("jc.com").toString().intern();
-
-
题目：new String（“ab”）会创建几个对象
- 两个，一个在堆中，另一个在堆的字符串常量池中 （如何举例和解释呢？）
代码如下：
/**
* 题目：new String（“ab”）会创建几个对象 ? 看字节码，就知道是两个
* 一个对象是：new 关键字在堆空间创建的
* 另一个对象是：字符串常量池中的对象。字节码指令：ldc
*
* @author: JC
* @date: 2021/11/29 19:44
*/
public class StringNewTest {
public static void main(String[] args) {
String str = new String("ab");
}
}
- 看字节码
0 new #2 <java/lang/String> 在堆空间开辟空间
3 dup
4 ldc #3 <ab> 在常量池中ab
6 invokespecial #4 <java/lang/String.<init> : (Ljava/lang/String;)V>
9 astore_1
10 return
拓展：new String(“a”) + new String (“b”)创造了几个对象？
-
对象1：new StringBuilder（）
-
对象2：new String（）
-
对象3 ：常量池中”a“
-
对象4：new String（”b“）
-
对象5: 常量池中的”b“
-
深入剖析： StringBuilder的toString();
-
对象6： new String（”ab“）
-
字符串常量池中有”ab“吗？
强调一下，toString（）调用，在字符串常量池中，没有生成”ab“
public class StringNewTest {
public static void main(String[] args) {
String str = new String("a") + new String ("b");
}
}
- 字节码
0 new #2 <java/lang/StringBuilder>
3 dup
4 invokespecial #3 <java/lang/StringBuilder.<init> : ()V>
7 new #4 <java/lang/String>
10 dup
11 ldc #5 <a>
13 invokespecial #6 <java/lang/String.<init> : (Ljava/lang/String;)V>
16 invokevirtual #7 <java/lang/StringBuilder.append : (Ljava/lang/String;)Ljava/lang/StringBuilder;>
19 new #4 <java/lang/String>
22 dup
23 ldc #8 <b>
25 invokespecial #6 <java/lang/String.<init> : (Ljava/lang/String;)V>
28 invokevirtual #7 <java/lang/StringBuilder.append : (Ljava/lang/String;)Ljava/lang/StringBuilder;>
31 invokevirtual #9 <java/lang/StringBuilder.toString : ()Ljava/lang/String;>
34 astore_1
35 return
面试题
public class StringIntern1 {
public static void main(String[] args) {
String s = new String("1");
s.intern();// 调用此方法之前，字符串常量池中已经存在了"1"
String s2 = "1";
System.out.println(s == s2); //
String s3 = new String("1") + new String("1");
// 执行完上一行代码以后，字符串常量池中，是否存在"11"呢？不存在"11"
s3.intern(); // 在字符串常量池中生成"11"。
// 如何理解 jdk6中：创建了一个新的对象"11",也就有新的地址
// jdk7中：此时常量池中没有创建”11“，
// 而是创建一个指向堆空间中new String("11")的地址
String s4 = "11"; // 使用上一行代码生成"11"的地址
System.out.println(s3 == s4);//
}
}
- jdk6的结果
false
false
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KGvkcBQY-1684071932780)(JVM.assets/image-20211129201558360.png)]
- jdk7/8的结果
false
true
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fff1l9dJ-1684071932781)(JVM.assets/image-20211129201610340.png)]
拓展：
public class StringIntern1 {
public static void main(String[] args) {
String s3 = new String("1") + new String("1");
String s4 = "11";
s3.intern();
System.out.println(s3 == s4);// flase
}
}
总结
- jdk6中，将这个字符串对象尝试放入串池
- 如果串池中有，则不会放入，返回已有的串池中的对象的地址
- 如果没有，会把此对象复制一份，放入串池，并返回串池中的对象地址
- jdk7中，将这个字符串对象尝试放入串池
- 如果串池中有，则并不会放入。返回已有的串池中的对象的地址
- 如果没有，会把此对象的引用地址复制一份，放入串池，并返回串池中引用地址地址
练习巩固
public class StringExer1 {
public static void main(String[] args) {
String s =new String("a") + new String("b");
// 执行完上一行代码以后，字符串常量池中并没"ab"
String s2 = s.intern();
System.out.println(s2 == "ab");
System.out.println(s == "ab");
}
}
- jdk6中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-39EUu3t5-1684071932781)(JVM.assets/image-20211129204531795.png)]
- jdk7/8中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Hqhl0jxz-1684071932781)(JVM.assets/image-20211129204709270.png)]
5.3 intern()的空间效率测试：空间角度
public class StringIntern2 {
static final int MAX_COUNT = 1000 * 10000;
static final String[] arr = new String[MAX_COUNT];
public static void main(String[] args) {
Integer[] data = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
long start = System.currentTimeMillis();
for (int i = 0; i < MAX_COUNT; i++) {
// 花费的时间：2815 ms String 实例 1000W
// arr[i] = new String(String.valueOf(data[i % data.length]));
// 花费的时间：1304 ms
arr[i] = new String(String.valueOf(data[i % data.length])).intern();
}
long end = System.currentTimeMillis();
System.out.println("花费的时间：" + (end - start) + " ms");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
- 没使用intern()
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ju76JErI-1684071932781)(JVM.assets/image-20211129210409740.png)]
- 使用intern()
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bgu4ESAP-1684071932782)(JVM.assets/image-20211129210426205.png)]
- 对于程序中大量的重复的字符串，可以使用intern() 方法节省空间
- 大的社交网站，需要内存中存储大量的字符串。如果都调用 intern() 方法，就会明显降低内存的大小
6.StringTable的垃圾回收
- 什么都不执行，只查看参数
/**
* String的垃圾回收:
* -Xms15m -Xmx15m -XX:+PrintStringTableStatistics -XX:+PrintGCDetails
* @author: JC
* @date: 2021/11/30 9:33
*/
public class StringGCTest {
public static void main(String[] args) {
}
}
- JVM参数：
-Xms15m -Xmx15m -XX:+PrintStringTableStatistics -XX:+PrintGCDetails
- 控制台输出：
StringTable statistics:
Number of buckets : 60013 = 480104 bytes, avg 8.000
Number of entries : 1787 = 42888 bytes, avg 24.000
Number of literals : 1787 = 159328 bytes, avg 89.159
Total footprint : = 682320 bytes
- 执行代码（循环100次）后:
/**
* String的垃圾回收:
* -Xms15m -Xmx15m -XX:+PrintStringTableStatistics -XX:+PrintGCDetails
* @author: JC
* @date: 2021/11/30 9:33
*/
public class StringGCTest {
public static void main(String[] args) {
for (int i = 0; i < 100; i++) {
String.valueOf(i).intern();
}
}
}
- JVM参数：
-Xms15m -Xmx15m -XX:+PrintStringTableStatistics -XX:+PrintGCDetails
- 控制台输出：
Number of entries和Number of literals增加了有些字符可能已经有了，就没加载了
StringTable statistics:
Number of buckets : 60013 = 480104 bytes, avg 8.000
Number of entries : 1874 = 44976 bytes, avg 24.000
Number of literals : 1874 = 163368 bytes, avg 87.176
Total footprint : = 688448 bytes
- 修改代码 增加循环次数
public class StringGCTest {
public static void main(String[] args) {
for (int i = 0; i < 10000; i++) {
String.valueOf(i).intern();
}
}
}
- JVM参数：
-Xms15m -Xmx15m -XX:+PrintStringTableStatistics -XX:+PrintGCDetails
- 控制台输出:
Number of entries和Number of literals又增加了
StringTable statistics:
Number of buckets : 60013 = 480104 bytes, avg 8.000
Number of entries : 11710 = 281040 bytes, avg 24.000
Number of literals : 11710 = 636032 bytes, avg 54.315
Total footprint : = 1397176 bytes
- 修改代码，增加循环次数
public class StringGCTest {
public static void main(String[] args) {
for (int i = 0; i < 100000; i++) {
String.valueOf(i).intern();
}
}
}
- JVM参数一样控制台输出：
StringTable statistics:
Number of buckets : 60013 = 480104 bytes, avg 8.000
Number of entries : 62631 = 1503144 bytes, avg 24.000
Number of literals : 62631 = 3566696 bytes, avg 56.948
Total footprint : = 5549944 bytes
按道理Number of entries和Number of literals应该10w了，但是现在不足10w
因为执行了执行了GC，也同时验证StringTable存在垃圾回收行为
[GC (Allocation Failure) [PSYoungGen: 4096K->488K(4608K)] 4096K->740K(15872K), 0.0212635 secs] [Times: user=0.00 sys=0.00, real=0.02 secs]
Heap
PSYoungGen total 4608K, used 3887K [0x00000000ffb00000, 0x0000000100000000, 0x0000000100000000)
eden space 4096K, 82% used [0x00000000ffb00000,0x00000000ffe51d70,0x00000000fff00000)
from space 512K, 95% used [0x00000000fff00000,0x00000000fff7a020,0x00000000fff80000)
to space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
ParOldGen total 11264K, used 252K [0x00000000ff000000, 0x00000000ffb00000, 0x00000000ffb00000)
object space 11264K, 2% used [0x00000000ff000000,0x00000000ff03f010,0x00000000ffb00000)
Metaspace used 3496K, capacity 4498K, committed 4864K, reserved 1056768K
class space used 387K, capacity 390K, committed 512K, reserved 1048576K
7.G1中的String去重操作
去重首先指的不是字符串常量池中的，因为字符串常量池不存在重复数据
String str1 = new String("hello");
String str2 = new String("hello");
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E9xz2nm7-1684071932782)(JVM.assets/image-20211130100717466.png)]
背景：对许多Java应用（有大的也有小的）做的测试得出以下结果：
-
堆存活数据集合里面string对象占了25%
-
堆存活数据集合里面重复的string对象有13.5%
-
string对象的平均长度是45
-
许多大规模的Java应用的瓶颈在于内存，测试表明，在这些类型的应用里面，
Java堆中存活的数据集合差不多25%是string对象。更进一步，这里面差不多一半string对象是重复的，重复的意思是说： stringl.equals（string2）= true。
堆上存在重复的string对象必然是一种内存的浪费。这个项目将在G1垃圾收集器中实现自动持续对重复的string对象进行去重，这样就能避免浪费内存。
描述
- 当垃圾收集器工作的时候，会访问堆上存活的对象。
对每一个访问的对象都会检查是否是候选的要去重的string对象。 - 如果是，把这个对象的一个引用插入到队列中等待后续的处理。一个去重的线程在后台运行，处理这个队列。处理队列的一个元素意味着从队列删除这个元素，然后尝试去重它引用的string对象。
- 使用一个hashtab1e来记录所有的被string对象使用的不重复的char数组。当去重的时候，会查这个hashtable，来看堆上是否已经存在一个一模一样的char数组。
- 如果存在，string对象会被调整引用那个数组，释放对原来的数组的引用，最终会被垃圾收集器回收掉。
- 如果查找失败，char数组会被插入到hashtable，这样以后的时候就可以共享这个数组了。
开启(默认是不开启的)
- 命令行选项
- UsestringDeduplication（bool）：开启string去重，
默认是不开启的，需要手动开启。 - Printstringbeduplicationstatistics（bool）：打印详细的去重统计信息
- stringpeduplicationAgeThreshold（uintx）：达到这个年龄的string对象被认为是去重的候选对象
- UsestringDeduplication（bool）：开启string去重，
第十四章 - 垃圾回收概述
1.前言
在提到什么是垃圾之前，我们先看下面一张图
从上图我们可以很明确的知道，Java 和 C++语言的区别，就在于垃圾收集技术和内存动态分配上，C语言没有垃圾收集技术，需要我们手动的收集。
-
垃圾收集，不是Java语言的伴生产物。早在1960年，第一门开始使用内存动态分配和垃圾收集技术的Lisp语言诞生。 关于垃圾收集有三个经典问题：
- 哪些内存需要回收？
- 什么时候回收？
- 如何回收？
-
垃圾收集机制是Java的招牌能力，
极大地提高了开发效率。如今，垃圾收集几乎成为现代语言的标配，即使经过如此长时间的发展，Java的垃圾收集机制仍然在不断的演进中，不同大小的设备、不同特征的应用场景，对垃圾收集提出了新的挑战，这当然也是面试的热点。
大厂面试题 (如下题目再后面4章都有讲解）
-
蚂蚁金服- 你知道哪几种垃圾回收器，各自的优缺点，重点讲一下cms和G1？
- 一面：JVM GC算法有哪些，目前的JDK版本采用什么回收算法？
- 一面：G1回收器讲下回收过程GC是什么？为什么要有GC？
- 一面：GC的两种判定方法？CMS收集器与G1收集器的特点
-
百度- 说一下GC算法，分代回收说下
- 垃圾收集策略和算法
-
天猫- 一面：JVM GC原理，JVM怎么回收内存
- 一面：CMS特点，垃圾回收算法有哪些？各自的优缺点，他们共同的缺点是什么？
-
滴滴- 一面：Java的垃圾回收器都有哪些，说下g1的应用场景，平时你是如何搭配使用垃圾回收器的
-
京东- 你知道哪几种垃圾收集器，各自的优缺点，重点讲下cms和G1，
- 包括原理，流程，优缺点。垃圾回收算法的实现原理
-
阿里- 讲一讲垃圾回收算法。
- 什么情况下触发垃圾回收？
- 如何选择合适的垃圾收集算法？
- JVM有哪三种垃圾回收器？
-
字节跳动- 常见的垃圾回收器算法有哪些，各有什么优劣？
- System.gc（）和Runtime.gc（）会做什么事情？
- 一面：Java GC机制？GC Roots有哪些？
- 二面：Java对象的回收方式，回收算法。
- CMS和G1了解么，CMS解决什么问题，说一下回收的过程。
- CMS回收停顿了几次，为什么要停顿两次?
2.什么是垃圾？
-
垃圾是指在
运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾。 -
如果不及时对内存中的垃圾进行清理，那么，这些垃圾对象所占的内存空间会一直保留到应用程序的结束，被保留的空间无法被其它对象使用，甚至可能导致
内存溢出。
磁盘碎片整理
机械硬盘需要进行磁盘整理，同时还有坏道
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-92D12Xaw-1684071932782)(JVM.assets/image-20211130105610830.png)]
3.为什么需要GC
- 对于高级语言来说，一个基本认知是如果不进行垃圾回收，
内存迟早都会被消耗完，因为不断地分配内存空间而不进行回收，就好像不停地生产生活垃圾而从来不打扫一样 - 除了释放没用的对象，垃圾回收也可以清除内存里地记忆碎片。碎片整理将所占用地对内存移动到堆的一端，以便
JVM 将整理出来的内存分配给新的对象 - 随着应用程序所应付的业务越来越庞大、复杂，用户越来越多，
没有GC就不能保证应用程序的正常进行。而经常造成STW的GC又跟不上实际的需求，所以在不断对GC进行优化
4.早期垃圾回收
在早期的C/C++时代，垃圾回收基本上是手工进行的。开发人员可以使用new关键字进行内存申请，并使用delete关键字进行内存释放。比如以下代码：
MibBridge *pBridge= new cmBaseGroupBridge（）；
//如果注册失败，使用Delete释放该对象所占内存区域
if（pBridge->Register（kDestroy）！=NO ERROR）
delete pBridge；
-
这种方式可以灵活控制内存释放的时间，但是会给开发人员带来
频繁申请和释放内存的管理负担。倘若有一处内存区间由于程序员编码的问题忘记被回收，那么就会产生
内存泄漏，垃圾对象永远无法被清除，随着系统运行时间的不断增长，垃圾对象所耗内存可能持续上升，直到出现内存溢出并造成应用程序崩溃。
有了垃圾回收机制后，上述代码极有可能变成这样:
MibBridge *pBridge=new cmBaseGroupBridge();
pBridge->Register(kDestroy);
- 现在，除了Java以外，C#、Python、Ruby等语言都使用了自动垃圾回收的思想，也是未来发展趋势，可以说这种自动化的内存分配和来及回收方式已经成为了现代开发语言必备的标准。
5.Java垃圾回收机制
好处
- 自动内存管理，无需开发人员手动参与内存的分配与回收，这样
降低内存泄漏和内存溢出的风险- 没有垃圾回收器，java也会和cpp一样，各种悬垂指针，野指针，泄露问题让你头疼不已。
- 自动内存管理机制，将程序员从繁重的内存管理中释放出来，可以
更专心的专注于业务开发 - oracle官网关于垃圾回收的介绍
担忧
- 对于Java开发人员而言，自动内存管理就像是一个黑匣子，如果过度依赖于“自动”，那么这将会是一场灾难，最严重的就会
弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力。 - 此时，了解JVM的自动内存分配和内存回收原理就显得非常重要，只有在真正了解JVM是如何管理内存后，我们才能够在遇见outofMemoryError时，快速地根据错误异常日志定位问题和解决问题。
- 当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就必须对这些“自动化”的技术
实施必要的监控和调节。
GC主要关注的区域
- GC主要关注于 方法区 和堆中的垃圾收集
垃圾收集器可以对年轻代回收，也可以对老年代回收，甚至是全栈和方法区的回收
- 其中，
Java堆是垃圾收集器的工作重点
从次数上讲：
频繁收集Young区较少收集Old区基本不收集Perm区（元空间）
第十五章 - 垃圾回收相关算法
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7XdwR0F9-1684071932783)(JVM.assets/image-20211130132147125.png)]
1.标记阶段：引用计数算法
1.1对象是否存活判断?
- 在堆里存放着几乎所有的Java对象实例，在GC执行垃圾回收之前，首先
需要区分出内存中哪些是存活对象，哪些是已经死亡的对象。只有被标记为死亡的对象，GC才会执行垃圾回收，释放掉其所占用的内存空间，因此这个过程我们称为垃圾标记阶段 - 那么在JVM中究竟是怎样标记一个死亡对象呢？简答来说，当一个对象已经不再被任何存活对象引用的时候，就可以宣判为已经死亡。
- 判断对象存活一般有两种方式：
引用计数法和可达性分析算法
1.2方式以：引用计数算法
-
引用计数算法（Reference Counting）比较简单，对每个对象保存一个整型的
引用计数器属性。用于记录对象被引用的情况。 -
对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1；当引用失效时，引用计数器就减1。只要对象A的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收。
-
优点
实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性。
-
缺点
- 它需要单独的字段存储计数器，这样的做法增加了
存储空间的开销。 - 每次复制都需要更新计数器，伴随着加法和减法操作，这增加了
时间开销 - 引用计数器有一个严重的问题，即
无法处理循环引用的情况，这是一条致命的缺陷，导致在Java的垃圾回收器中没有使用到这类算法。
- 它需要单独的字段存储计数器，这样的做法增加了
-
循环引用
- 当p的指针断开的时候，内部的引用形成一个循环，这就是循环引用，从而造成内存泄漏
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mX6mF79U-1684071932783)(JVM.assets/image-20211130132939893.png)]
举例
来证明Java中确实没有使用引用计数算法
/**
* -XX:PrintGCDetails
* 证明：java使用的不是引用计算算法
*/
public class RefCountGC {
// 这个成员属性的唯一作用就是占用一点内存
private byte[] bigSize = new byte[5*1024*1024]; // 5MB
// 引用
Object reference = null;
public static void main(String[] args) {
RefCountGC obj1 = new RefCountGC();
RefCountGC obj2 = new RefCountGC();
obj1.reference = obj2;
obj2.reference = obj1;
obj1 = null;
obj2 = null;
// 显示的执行垃圾收集行为，判断obj1 和 obj2是否被回收？
System.gc();
}
}
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bghf8eW8-1684071932783)(JVM.assets/image-20211130134143274.png)]
- 如果不小心直接把 Obj1.reference 和 Obj2.reference置为null。则在Java堆当中的两块内存依然有相互引用，无法回收。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2xys8KeX-1684071932783)(JVM.assets/image-20211130134543951.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8GXwcbre-1684071932784)(JVM.assets/image-20211130134837041.png)]
小结
- 引用计数算法，是很多语言的资源回收选择，入Python，支持引用计数和垃圾收集机制
- 具体哪种是最优是要看场景的，业界有大规模实践中进保留引用计数机制，以提高吞吐量的尝试
- Java并没有选择引用计数，是因为其存在一个基本的难题，就是很难处理循环引用问题
- Python如何解决?
- 手动解除：很好理解，就是在合适的时机，解除引用关系
- 使用弱引用weakref，weakref是Python的标准库，为了解决循环引用
2.标记阶段：可达性分析算法
2.1概念
- 可达性分析算法：也可以称为 根搜索算法、追踪性垃圾收集
- 相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效地
解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。 - 相较于引用计数算法，这里的可达性分析就是
Java、C#选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集（Tracing Garbage Collection）
2.2实现思路
所谓"GCRoots”根集合就是一组必须活跃的引用。
- 基本思路
- 可达性分析算法是以根对象集合（GCRoots）为起始点，按照从上至下的方式
搜索被根对象集合所连接的目标对象是否可达。 - 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为
引用链（Reference Chain） - 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。
- 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。
- 可达性分析算法是以根对象集合（GCRoots）为起始点，按照从上至下的方式
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-t3smZdNu-1684071932784)(JVM.assets/image-20211130135950411.png)]
2.3GC Roots可以是哪些结构？
在Java语言中， GC Roots 包括一下几类元素:
-
虚拟机栈中引用的对象
- 比如：各个线程被调用的方法中使用到的参数、局部变量等。
-
本地方法栈内JNI（通常说的本地方法）引用的对象
-
方法区中类静态属性引用的对象
- 比如：Java类的引用类型静态变量
-
方法区中常量引用的对象
- 比如：字符串常量池（string Table）里的引用
-
所有被同步锁synchronized持有的对象
-
Java虚拟机内部的引用。
- 基本数据类型对应的Class对象，一些常驻的异常对象（如：NullPointerException、outofMemoryError），系统类加载器。
-
反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
-
除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。比如：分代收集和局部回收（PartialGC）。
-
如果只针对Java堆中的某一块区域进行垃圾回收（比如：典型的只针对新生代），必须考虑到内存区域是虚拟机自己的实现细节，更不是孤立封闭的，这个区域的对象完全有可能被其他区域的对象所引用，这时候就需要一并将关联的区域对象也加入GCRoots集合中去考虑，才能保证可达性分析的准确性。
-
小技巧:
- 由于Root 采用栈方式存储变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放再堆内存里面，那它就是一个Root
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4LkqJT5a-1684071932784)(JVM.assets/image-20211130140737094.png)]
注意
-
如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。
-
这点也是导致GC进行时必须“stop The World”的一个重要原因。
- 即使是号称（几乎）不会发生停顿的CMS收集器中，
枚举根节点时也是必须要停顿的。
- 即使是号称（几乎）不会发生停顿的CMS收集器中，
3.对象的finalization机制
- Java语言提供了对象终止（finalization）机制来允许开发人员提供
对象被销毁之前的自定义处理逻辑。 - 当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize()方法。
- finalize() 方法允许在子类中被重写，
用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。
注意
- 永远不要主动调用某个对象的 finalize() 方法，应该交给垃圾回收机制调用，理由包括下面三点:
- 在finalize()时可能导致对象复活
- finalize()方法的执行时间是没有报障的，它完全由GC线程决定，极端情况下，若不发生GC，则finalize()方法没有执行机会
- 因为优先级比较低，即使主动调用该方法，也不会因此就直接进行回收
- 一个糟糕的finalize()会严重影响GC性能
- 从功能上来说，finalize()方法与C++中的析构函数类似，但是Java采用的是基于垃圾回收器的自动内存管理机制，所以finalize()方法在本质上不同于C++中的析构函数。
- 由于finalize()方法的存在，
虚拟机中的对象一般处于三种可能的状态
对象生存还是死亡？
-
如果从所有的根节点都无法访问到某个对象，说明对象己经不再使用了。一般来说，此对象需要被回收。但事实上，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段。
一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它的回收就是不合理的，为此，定义虚拟机中的对象可能的三种状态。如下：可触及的：从根节点开始，可以到达这个对象。可复活的：对象的所有引用都被释放，但是对象有可能在finalize()中复活。不可触及的：对象的finalize（）被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一次。
-
以上3种状态中，是由于finalize（）方法的存在，进行的区分。只有在对象不可触及时才可以被回收。
具体过程
-
判定一个对象objA是否可回收，至少要经历两次标记过程：
-
如果对象objA到GC Roots没有引用链，则进行第一次标记。
-
进行筛选，判断此对象是否有必要执行finalize（）方法
-
如果对象objA没有重写finalize()方法，或者finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA被判定为不可触及的。
-
如果对象objA重写了finalize()方法，且还未执行过，那么objA会被插入到F-Queue队列中，由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize()方法执行。
-
finalize()方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被移出“即将回收”集合。
之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize()方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize()方法只会被调用一次。
-
-
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sPevBEY3-1684071932784)(JVM.assets/image-20211130144926314.png)]
- 上图就是我们看到的Finalizer线程（一直处于等待中）
代码演示可复活的对象
我们使用重写 finalize()方法，然后在方法的内部，重写将其存放到GC Roots中
/**
* 测试Object类中finalize()方法
* 对象复活场景
*/
public class CanReliveObj {
// 类变量，属于GC Roots的一部分
public static CanReliveObj canReliveObj;
// 此方法只能被调用一次
@Override
protected void finalize() throws Throwable {
System.out.println("调用当前类重写的finalize()方法");
canReliveObj = this;// 当前对象与引用链上任意一个对象建立了联系
}
public static void main(String[] args) throws Exception {
canReliveObj = new CanReliveObj();
canReliveObj = null;
System.gc();
System.out.println("-----------------第一次gc操作------------");
// 因为Finalizer线程的优先级比较低，暂停2秒，以等待它
Thread.sleep(2000);
if (canReliveObj == null) {
System.out.println("obj is dead");
} else {
System.out.println("obj is still alive");
}
System.out.println("-----------------第二次gc操作------------");
canReliveObj = null;
System.gc();
// 下面代码和上面代码是一样的，但是 canReliveObj却自救失败了
Thread.sleep(2000);
if (canReliveObj == null) {
System.out.println("obj is dead");
} else {
System.out.println("obj is still alive");
}
}
}
4.MAT于JProfiler的GC Roots溯源
4.1MAT是什么？
- MAT是Memory Analyzer的简称，它是一款功能强大的Java堆内存分析器。用于查找内存泄漏以及查看内存消耗情况。
- MAT是基于Eclipse开发的，是一款免费的性能分析工具。
获取dump文件
- 实例代码
public class GcRootsTest {
public static void main(String[] args) {
ArrayList<Object> numList = new ArrayList<>();
Date birth = new Date();
for (int i = 0; i < 100; i++) {
numList.add(String.valueOf(i));
try {
Thread.sleep(10);
} catch (Exception e) {
e.printStackTrace();
}
}
System.out.println("数据添加完毕，请操作");
new Scanner(System.in).nextLine();
numList = null;
birth = null;
System.out.println("numList birth 已经置空，请操作");
new Scanner(System.in).nextLine();
System.out.println("结束");
}
}
生成dump文件的两种方式 命令行的jmap和使用JVIsualVM
- 命令行使用 jmap
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eOkaoxgD-1684071932785)(JVM.assets/image-20211130160911251.png)]
- 使用JVIsualVM
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WIHTChdS-1684071932785)(JVM.assets/image-20211130161643786.png)]
- 使用MAT打开Dump文件
- 打开后，我们就可以看到有哪些可以作为GC Roots的对象
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wPt5BUyl-1684071932785)(JVM.assets/image-20211130162419067.png)]
- JProfiler的GC Roots溯源
我们在实际的开发中，一般不会查找全部的GC Roots，可能只是查找某个对象的整个链路，或者称为GC Roots溯源，这个时候，我们就可以使用JProfiler
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xpezhQVE-1684071932785)(JVM.assets/image-20211130163541175.png)]
- 标记下当前的值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-chtzh8V6-1684071932786)(JVM.assets/image-20211130163639291.png)]
- 个数就为绿色，还会基于之前的有变化显示
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BKxCe7ra-1684071932786)(JVM.assets/image-20211130163556160.png)]
如何判断什么原因造成OOM
当我们程序出现OOM的时候，我们就需要进行排查，我们首先使用下面的例子进行说明
public class HeapOOM {
// 创建1M的文件
byte [] buffer = new byte[1 * 1024 * 1024];
public static void main(String[] args) {
ArrayList<HeapOOM> list = new ArrayList<>();
int count = 0;
try {
while (true) {
list.add(new HeapOOM());
count++;
}
} catch (Exception e) {
e.getStackTrace();
System.out.println("count:" + count);
}
}
}
- 上述代码就是不断的创建一个1M小字节数组，然后让内存溢出，我们需要限制一下内存大小，同时使用HeapDumpOnOutOfMemoryError将出错时候的dump文件输出
JVM参数
-Xms8m -Xmx8m -XX:HeapDumpOnOutOfMemoryError
- 我们将生成的dump文件打开，然后点击Biggest Objects就能够看到超大对象
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Bx1sCG3X-1684071932786)(JVM.assets/image-20211130164235279.png)]
- 然后我们通过线程，还能够定位到哪里出现OOM
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sqVCvGw6-1684071932786)(JVM.assets/image-20211130164306060.png)]
5.清除阶段：标记-清除算法
-
当成功区分处内存中存活对象和死亡对象之后，GC接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存
-
目前在JVM中比较常见的三种垃圾收集算法是
- 标记-清除算法（Mark-Sweep）
- 复制算法（Copying）
- 标记-压缩算法（Mark-Compact）
-
标记-清除算法（Mark-Sweep）是一种非常基础和常见的垃圾收集算法，该算法被 J.McCarthy等人在1960年提出并应用于Lisp语言
执行过程
- 当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除
标记:Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。(标记的是非清除对象）清除:Collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收
什么是清除？
- 这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放覆盖原有的地址。
关于空闲列表是在为对象分配内存的时候 提过
- 如果内存规整
- 采用指针碰撞的方式进行内存分配
- 如果内存不规整
- 虚拟机需要维护一个列表
- 空闲列表分配
缺点
- 标记清除算法的效率不算高
- 在进行GC的时候，需要停止整个应用程序，用户体验较差
- 这种方式清理出来的空闲内存是不连续的，产生内碎片，需要维护一个空闲列表
6.清除阶段：复制算法
背景
为了解决标记-清除算法在垃圾收集效率方面的缺陷，M.L.Minsky于1963年发表了著名的论文，“使用双存储区的Lisp语言垃圾收集器CA LISP Garbage Collector Algorithm Using Serial Secondary Storage）”。M.L.Minsky在该论文中描述的算法被人们称为复制（Copying）算法，它也被M.L.Minsky本人成功地引入到了Lisp语言的一个实现版本中。
- 核心思想
- 将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收
优点- 没有标记和清除过程，实现简单，运行高效
- 复制过去之后保证空间的连续性，不会出现”碎片“问题
缺点- 很明显，需要2倍的空间
- 对于G1这种拆分未大量 region 的GC，复制而不是移动，意味着GC需要维护region之间对象的引用关系，不管是内存或者实现开销都不小
特别需要注意的问题- 如果系统中的垃圾对象不是很多，复制算法需要复制的存活对象数量太大，效率就低了,存活数非常低才行。
- 应用场景
- 在新生代，对常规的应用的垃圾回收，一次通常可以回收 70%~99%的内存 空间，回收性价比很高，所以现在的商业虚拟机都是使用这种方式作为收集算法回收新生代
7.清除阶段：标记-压缩(标记-整理、Mark-Compact)算法
背景
-
复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生区经常发生，但是在老年区，更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，
基于老年代垃圾回收的特性，需要使用其他的算法。 -
标记一清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JvM的设计者需要在此基础之上进行改进。标记-压缩（Mark-Compact）算法由此诞生。
-
1970年前后，G.L.Steele、C.J.Chene和D.s.Wise等研究者发布标记-压缩算法。在许多现代的垃圾收集器中，人们都使用了标记-压缩算法或其改进版本。
执行过程
- 第一阶段和标记清除算法一样，从根节点开始标记所有被引用的对象
- 第二阶段将所有的存活对象压缩到内存的一端，按照顺序排放
- 之后，清理边界外所有的空间
- 标记-压缩算法的最终效果等同于标记-清除算法执行完成后，再进行一次内存碎片整理，因此，也可以把它称为
标记-清除-压缩（Mark-Sweep-Compact）算法。
标记-清除和标记-整理的区别
-
二者的本质差异在于标记-清除算法是一种
非移动式的回收算法，标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。 -
可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。
-
优点
- 消除了 标记-清除算法当中，内存区域分散的缺点。我们需要给新对象分配内存的时，JVM只需要持有一个内存的起始地址即可。
- 消除了复制算法当中，内存减半的高额代价。
-
缺点
- 从效率上说，标记-整理算法要低于复制算法。
- 移动对象的同时，如果对象被引用，还需要调整引用的地址。
- 移动过程中，需要全程暂停用户应用程序 即:STW。
8.三种算法对比
-
效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存。
-
而为了尽量兼顾下面提到的三个指标，标记-整理算法相对来说更平滑一些，但是效率上不尽如人意，它比复制算法多了一个标记的阶段，比标记-清除多了一个整理内存的阶段。
| Mark-Sweep | Mark-Compact | Copying(复制算法) | |
|---|---|---|---|
| 速度 | 中等 | 最慢 | 最快 |
| 空间开销 | 少（但会堆积碎片） | 少（不堆积碎片） | 通常需求要活对象都2倍大小（不堆积碎片） |
| 移动对象 | 否 | 是 | 是 |
综合我们可以找到，没有最好的算法，只有最合适的算法
9.分代收集算法
-
前面所有这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集算法应运而生。
-
分代收集算法，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，
不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率。 -
在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如
Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如：string对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。
目前几乎所有的GC都采用分代收集(Generational Collecting)算法执行垃圾回收的。
-
在HotSpot中，基于分代的概念，GC所使用的内存回收算法必须结合年轻代和老年代各自的特点。
-
年轻代（Young Gen）
-
年轻代特点：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。
这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。
-
-
老年代（Tenured Gen）
-
老年代特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。
这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由
标记-清除或者是标记-清除与标记-整理的混合实现。
-
-
Mark阶段的开销与存活对象的数量成正比。
-
Sweep阶段的开销与所管理区域的大小成正相关。
-
compact阶段的开销与存活对象的数据成正比。
-
-
以HotSpot中的CMS回收器为例，CMS是基于 Mark-Sweep实现的。对于对象的回收效率很高。对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器作为补偿措施：当内存回收热点（碎片导致的 Concurrent Mode Failure时），将采用Serial Old 执行Full GC对老年代进行内存的整理
-
分代的思想被现有的虚拟机广泛使用。几乎所有的垃圾回收器都区分新生代和老年代
10.增量收集算法、分区算法
10.1增量收集算法
概述
- 上述现有的算法，在垃圾回收过程中，应用软件将处于一种stop the World的状态。在stop the World状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，==将严重影响用户体验或者系统的稳定性。==为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集（Incremental Collecting）算法的诞生。
基本思想
- 如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，
垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。 - 总的来说，增量收集算法的基础仍是传统的
标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作
缺点
- 使用这种方式，由于在垃圾回收过程中，间断性的还执行了应用程序代码，所以能减少系统的停顿时间。但是因为线程上下文切换的消耗，会使得垃圾回收的总体成本上升，
造成系统的吞吐量下降。
10.2分区算法
概述
- 一般来说，在相同条件下，堆空间越大，一次Gc时所需要的时间就越长，有关GC产生的停顿也越长。为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。
- 分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。
- 每一个小空间独立使用，独立回收，这种算法的好处是可以控制一次回收多少个小区间。
写到最后
- 注意，这些只是基本的算法思路，实际GC实现过程要复杂的多，目前还在发展中的前沿GC都是复合算法，并且并行和并发兼备。
第十六章 - 垃圾回收相关概念
1.System.gc()的理解
- 在默认情况下，通过system.gc()者Runtime.getRuntime().gc() 的调用，
会显式触发FullGC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。 - 然而system.gc() 调用附带一个免责声明，无法保证对垃圾收集器的调用。(不能确保立即生效)
- JVM实现者可以通过system.gc() 调用来决定JVM的GC行为。而一般情况下，垃圾回收应该是自动进行的，
无须手动触发，否则就太过于麻烦了。在一些特殊情况下，如我们正在编写一个性能基准，我们可以在运行之间调用System.gc()
代码示例
public class SystemGCTest {
public static void main(String[] args) {
new SystemGCTest();
System.gc();// 提醒JVM的垃圾回收器执行gc
}
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("SystemGCTest 执行了 finalize方法");
}
}
-
结果是不一定能输出finalize()中的println()
-
结论：System.gc();只是提醒JVM执行gc，但并不确定是否马上执行gc
-
System.gc()底层为：
public static void gc() { Runtime.getRuntime().gc(); }所以System.gc()与 Runtime.getRuntime().gc()的作用一样
代码示例2
public class SystemGCTest {
public static void main(String[] args) {
new SystemGCTest();
System.gc();// 提醒JVM的垃圾回收器执行gc
System.runFinalization();
}
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("SystemGCTest 执行了 finalize方法");
}
}
- 结果:每次都执行了finalize()
- 结论：System.runFinalization()会强制调用 使用引用的对象的finalize()方法
手动GC来理解 不可达对象的回收
public class LocalVarGC {
/**
* 触发Minor GC没有回收对象，然后在触发Full GC将该对象存入old区
*/
public void localvarGC1() {
byte[] buffer = new byte[10*1024*1024];// 10MB
System.gc();
}
/**
* 触发YoungGC的时候，已经被回收了
*/
public void localvarGC2() {
byte[] buffer = new byte[10*1024*1024];// 10MB
buffer = null;
System.gc();
}
/**
* 不会被回收，因为它还存放在局部变量表索引为1的槽中
*/
public void localvarGC3() {
{
byte[] buffer = new byte[10*1024*1024];// 10MB
}
System.gc();
}
/**
* 会被回收，因为它还存放在局部变量表索引为1的槽中，但是后面定义的value把这个槽给替换了
*/
public void localvarGC4() {
{
byte[] buffer = new byte[10*1024*1024];
}
int value = 10;
System.gc();
}
/**
* localvarGC5中的数组已经被回收
*/
public void localvarGC5() {
localvarGC1();
System.gc();
}
public static void main(String[] args) {
LocalVarGC localVarGC = new LocalVarGC();
localVarGC.localvarGC3();
}
}
- 查看内存占用情况,所以JVM参数都为
-XX:+PrintGCDetails
- 执行localvarGC1()方法
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lqk79XKo-1684071932787)(JVM.assets/image-20211201155117520.png)]
- 执行localvarGC2()方法
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NiBjJloH-1684071932787)(JVM.assets/image-20211201155542052.png)]
- localvarGC3()方法
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IzTuiFG7-1684071932787)(JVM.assets/image-20211201160157880.png)]
- localvarGC4()方法
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LkOSctH2-1684071932788)(JVM.assets/image-20211201160405361.png)]
2.内存溢出与内存泄漏
2.1内存溢出
概念
-
内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一。
-
由于GC一直在发展，所有一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现OOM的情况。
-
大多数情况下，GC会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的FullGC操作，这时候会回收大量的内存，供应用程序继续使用。
-
javadoc中对OutOfMemoryError的解释是，
没有空闲内存，并且垃圾收集器也无法提供更多内存。
空闲内存不够原因
首先说没有空闲内存的情况：说明Java虚拟机的堆内存不够。原因有二：
-
Java虚拟机的堆内存设置不够。
- 比如：可能存在内存泄漏问题；也很有可能就是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显式指定JVM堆大小或者指定数值偏小。我们可以通过参数-Xms 、-Xmx来调整。
-
代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）
- 对于老版本的oracle JDK，因为永久代的大小是有限的，并且JVM对永久代垃圾回收（如，常量池回收、卸载不再需要的类型）非常不积极，所以当我们不断添加新类型的时候，永久代出现OutOfMemoryError也非常多见，尤其是在运行时存在大量动态类型生成的场合；类似intern字符串缓存占用太多空间，也会导致OOM问题。对应的异常信息，会标记出来和永久代相关：“
java.lang.OutOfMemoryError:PermGen space”。 - 随着元数据区的引入，方法区内存已经不再那么窘迫，所以相应的ooM有所改观，出现ooM，异常信息则变成了：“
java.lang.OutofMemoryError:Metaspace"。直接内存不足，也会导致OOM。
- 对于老版本的oracle JDK，因为永久代的大小是有限的，并且JVM对永久代垃圾回收（如，常量池回收、卸载不再需要的类型）非常不积极，所以当我们不断添加新类型的时候，永久代出现OutOfMemoryError也非常多见，尤其是在运行时存在大量动态类型生成的场合；类似intern字符串缓存占用太多空间，也会导致OOM问题。对应的异常信息，会标记出来和永久代相关：“
-
OOM这里面隐含着一层意思是，在抛出OutofMemoryError之前，通常垃圾收集器会被触发，尽其所能去清理出空间。
- 例如：在引用机制分析中，涉及到JVM会去尝试回收
软引用指向的对象等。 - 在java.nio.BIts.reserveMemory（）方法中，我们能清楚的看到，System.gc（）会被调用，以清理空间。
- 例如：在引用机制分析中，涉及到JVM会去尝试回收
-
当然，也不是任何情况下垃圾回收器都会被触发的
- 比如我们去分配一个超级大的对象,类似一个超大的数组超过堆的最大值，JVM判断出垃圾收集器并不能解决这个问题，所以直接抛出OutOfMemoryError。
2.1内存泄漏(Memory Leak)
概述
- 也称作“存储渗漏”。严格来说，
只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏。 - 但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致OOM，也可以叫做
宽泛意义上的“内存泄漏”。 - 尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现OutOfMemory异常，导致程序崩溃。
- 注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。
Java使用可达性分析算法，最上面的数据不可达，就是需要被回收的。后期有一些对象不用了，按道理应该断开引用，但是存在一些链没有断开，从而导致没有办法被回收。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jinVPWCu-1684071932788)(JVM.assets/image-20211201164633125.png)]
内存泄露举例：
- 单例模式
- 单例的生命周期和应用程序时一样长的，所以单例程序中，如果持有对象外部引用的话，那么这个外部对象时不能被回收的，则会导致内存泄漏的发生
- 一些提供close的资源未关闭而导致内存泄漏
- 数据库连接(dataSourse.getConnection())网络连接(socket) 和io连接必须手动close，否则不能回收
3.Stop The World
-
Stop-the-World，简称STW，指的是GC事件发生过程中，会产生应用程序的停顿。
停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为STW。- 可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿。(根节点个数会随时变化的)
- 分析工作必须在一个能确保一致性的快照中进行
- 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证
- 可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿。(根节点个数会随时变化的)
-
被STW中断的应用程序线程会在完成GC之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以我们需要减少STW的发生。
-
STW事件和采用哪款GC无关所有的GC都有这个事件。
-
哪怕是G1也不能完全避免Stop-the-world情况发生，只能说垃圾回收器越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间。
-
STW是JVM在
后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。 -
开发中不要用System.gc() 会导致Stop-the-world的发生。
4.垃圾回收的并行与并发
4.1程序方面
并发（Concurrent）
- 在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理器上运行。
- 并发不是真正意义上的“同时进行”，只是CPU把一个时间段划分成几个时间片段（时间区间），然后在这几个时间区间之间来回切换，由于CPU处理的速度非常快，只要时间间隔处理得当，即可让用户感觉是多个应用程序同时在进行。
并行（Parallel）
- 当系统有一个以上CPU时，当一个CPU执行一个进程时，另一个CPU可以执行另一个进程，两个进程互不抢占CPU资源，可以同时进行，我们称之为并行（Parallel）。
- 其实决定并行的因素不是CPU的数量，而是CPU的核心数量，比如一个CPU多个核也可以并行。
- 适合科学计算，后台处理等弱交互场景
并行 VS 并发
二者对比:
-
并发：指的是多个事情，在
同一个时间段内同时发生了 -
并行：指的是多个事情，在
同一个时间点上同时发生了 -
并发的多个任务之间是互相抢占资源的。
-
并行的多个任务之间是不互相抢占资源的。
-
只有在多CPU或者一个CPU多核的情况中，才会发生并行。否则，看似同时发生的事情，其实都是并发执行的。
4.2垃圾回收方面
并发和并行，在谈论垃圾收集器的上下文语境中，它们可以解释如下：
- 并行(Parallel):指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
- 如ParNew、Parallel Scavenge、Parallel old;
- 串行(Serial)
- 相较于并行的概念，单线程执行。
- 如果内存不够，则程序暂停，启动JVM垃圾回收器进行垃圾回收。回收完，再启动程序的线程。
单核CPU下并行可能更慢
- 并发(Concurrent):指
用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），垃圾回收线程在执行时不会停顿用户程序的运行。- 用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上;
- 如：CMS、G1
5.安全点与安全区域
5.1安全点(Safe Point)
-
程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置称为“安全点（Safepoint）”。
-
Safe Point的选择很重要，
如果太少可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。比如：选择一些执行时间较长的指令作为Safe Point，如方法调用、循环跳转和异常跳转等。 -
如何在cc发生时，检查所有线程都跑到最近的安全点停顿下来呢？
- 抢先式中断：（目前没有虚拟机采用了）
- 首先中断所有线程。如果还有线程不在安全点，就恢复线程，让线程跑到安全点。
- 主动式中断：
- 设置一个中断标志，各个线程运行到Safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。（有轮询的机制）
- 抢先式中断：（目前没有虚拟机采用了）
5.2安全区域(Safe Region)
- Safepoint 机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？例如线程处于sleep-状态或Blocked 状态，这时候线程无法响应JVM的中断请求，“走”到安全点去中断挂起，JVM也不太可能等待线程被唤醒。对于这种情况，就需要安全区域（Safe Region）来解决。
安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始Gc都是安全的。我们也可以把Safe Region看做是被扩展了的Safepoint。
实际执行时：
- 当线程运行到Safe Region的代码时，首先标识已经进入了Safe Relgion，如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程
- 当线程即将离开Safe Region时，会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开Safe Region的信号为止；
6.Java中的引用
6.1引用
我们希望能描述这样一类对象：当内存空间还足够时，则能保留在内存中；如果内存空间在进行垃圾收集后还是很紧张，则可以抛弃这些对象。
-
【既偏门又非常高频的面试题】强引用、软引用、弱引用、虚引用有什么区别？具体使用场景是什么？
-
在JDK1.2版之后，Java对引用的概念进行了扩充，将引用分为（
强度依次减弱）： -
强引用（Strong Reference）
-
软引用（Soft Reference）
-
弱引用（Weak Reference）
-
虚引用（Phantom Reference）
除强引用外，其他3种引用均可以在java.lang.ref包中找到它们的身影。如下图，显示了这3种引用类型对应的类，开发人员可以在应用程序中直接使用它们。
Reference子类中只有终结器引用是包内可见的，其他3种引用类型均为public，可以在应用程序中直接使用
强引用（StrongReference）：最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“**Object obj=new Object()”**这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。软引用（SoftReference）：在系统将要发生内存溢出之前，将会把这些对象列入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出内存流出异常。(内存不够，既回收)弱引用（WeakReference）：被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象。(发现既回收)虚引用（PhantomReference）：一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
6.2强引用(Strong Reference)—不回收
- 在Java程序中，最常见的引用类型是强引用（
普通系统99%以上都是强引用），也就是我们最常见的普通对象引用，也是默认的引用类型。 - 当在Java语言中使用new操作符创建一个新的对象，并将其赋值给一个变量的时候，这个变量就成为指向该对象的一个强引用。
强引用的对象是可触及的，垃圾收集器就永远不会回收掉被引用的对象。- 对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显式地将相应（强）引用赋值为null，就是可以当做垃圾被收集了，当然具体回收时机还是要看垃圾收集策略。
- 相对的，软引用、弱引用和虚引用的对象是软可触及、弱可触及和虚可触及的，在一定条件下，都是可以被回收的。所以，
强引用是造成Java内存泄漏的主要原因之一。
代码-强引用举例
StringBuffer str = new StringBuffer("hello");
- 局部变量str指向stringBuffer实例所在堆空间，通过str可以操作该实例，那么str就是stringBuffer实例的强引用对应内存结构：
- 如果此时，在运行一个赋值语句
StringBuffer str = new StringBuffer("hello");
StringBuffer str1 = str;
- 对应的内存结构为:
那么我们将 str = null; 则 原来堆中的对象也不会被回收，因为还有其它对象指向该区域
总结
本例中的两个引用，都是强引用，强引用具备以下特点：
- 强引用可以直接访问目标对象。
- 强引用所指向的对象在任何时候都不会被系统回收，虚拟机宁愿抛出OOM异常，也不会回收强引用所指向对象。
- 强引用可能导致内存泄漏。
6.3软引用(Soft Reference)—内存不足既回收
- 软引用是用来描述一些还有用，但非必需的对象。
只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。
注意，这里的第一次回收是不可达的对象,而且软引用(弱引用和虚引用也是)是不会导致内存溢出
-
软引用通常用来实现内存敏感的缓存。比如：
高速缓存就有用到软引用。如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。 -
垃圾回收器在某个时刻决定回收软可达的对象的时候，会清理软引用，并可选地把引用存放到一个引用队列（Reference Queue）。
-
类似弱引用，只不过Java虚拟机会尽量让软引用的存活时间长一些，迫不得已才清理。
一句话概括：
内存足够时，不会回收软引用可达的对象。
内存不够时，会回收软引用的可达对象
- 在JDK1.2版之后提供了SoftReference类来实现软引用
// 声明强引用
Object obj = new Object();
// 创建一个软引用
SoftReference<Object> sf = new SoftReference<>(obj);
obj = null; //销毁强引用，这是必须的，不然会存在强引用和软引用
- 下面举例说明：先配置IDEA执行代码的VM参数
-Xms2M -Xmx3MJVM初始内存设为2M，最大可用内存为3M
/**
* VM参数：-Xms2M -Xmx3M
*/
public class Test2 {
public static void main(String[] args) {
byte[] bytes = new byte[1024 * 1024 * 3];
}
}
// Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
- 现在设置为软引用，如下代码所示
/**
* VM参数：-Xms2M -Xmx3M
*/
public class TestSoftReferenceOom {
private static List<Object> list = new ArrayList();
public static void main(String[] args) {
testReferenceOom();
}
public static void testReferenceOom() {
for (int i = 0; i < 10; i++) {
byte[] b = new byte[1024 * 1024];
SoftReference<byte[]> reference = new SoftReference<>(b);
list.add(reference);
}
// 触发一次GC 注意：并不是一定会立刻执行GC
System.gc();
for (int i = 0; i < list.size(); i++) {
Object obj = ((SoftReference) list.get(i)).get();
System.out.print(obj + " ");
}
}
}
// null null null null null null null null null [B@1540e19d
- 此时我们发现，无论创建了多少对象，之前的对象都为null，只保留了最后一个对象，这就说明了在内存空间不足的情况下，软引用会被回收
- 值得注意的一点 , 即使有 byte[] b引用指向对象, 且 b 是一个strong reference, 但是 SoftReference str 指向的对象仍然被回收了，这是因为Java的编译器发现了在之后的代码中, b已经没有被使用了, 所以自动进行了优化。
- 这时候稍稍改动一下代码如下
/**
* VM参数：-Xms2M -Xmx3M
*/
public class TestSoftReferenceOom {
private static List<Object> list = new ArrayList();
public static void main(String[] args) {
testReferenceOom();
}
public static void testReferenceOom() {
byte[] b = null;
for (int i = 0; i < 10; i++) {
b = new byte[1024 * 1024];
SoftReference<byte[]> reference = new SoftReference<>(b);
list.add(reference);
}
// 触发一次GC 注意：并不是一定会立刻执行GC
System.gc();
for (int i = 0; i < list.size(); i++) {
Object obj = ((SoftReference) list.get(i)).get();
System.out.print(obj + " ");
}
}
}
// Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
- 此时b是强引用，无法被回收。报错
6.4弱引用(Weak Reference)—发现既回收
-
弱引用也是用来描述那些非必需对象，
只被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。 -
但是，由于垃圾回收器的线程通常优先级很低，因此，并不一定能很快地发现持有弱引用的对象。在这种情况下，
弱引用对象可以存在较长的时间。 -
弱引用和软引用一样，在构造弱引用时，也可以指定一个引用队列，当弱引用对象被回收时，就会加入指定的引用队列，通过这个队列可以跟踪对象的回收情况。
-
软引用、弱引用都非常适合来保存那些可有可无的缓存数据。如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。
在JDK1.2版之后提供了WeakReference类来实现弱引用。
// 声明强引用
Object obj = new Object();
// 创建一个弱引用
WeakReference<Object> sf = new WeakReference<>(obj);
obj = null; //销毁强引用，这是必须的，不然会存在强引用和弱引用
弱引用对象与软引用对象的最大不同就在于，当GC在进行回收时，需要通过算法检查是否回收软引用对象，而对于弱引用对象，GC总是进行回收。弱引用对象更容易、更快被GC回收。
面试题：你开发中使用过WeakHashMap吗？
- WeakHashMap用来存储图片信息，可以在内存不足的时候，及时回收，避免了OOM
6.5虚引用(Phantom Reference)—对象回收跟踪
-
也称为“幽灵引用”或者“幻影引用”，是所有引用类型中最弱的一个
-
一个对象是否有虚引用的存在，完全不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收。
-
它不能单独使用，也无法通过虚引用来获取被引用的对象。当试图通过虚引用的get()方法取得对象时，总是null
-
为一个对象设置虚引用关联的唯一目的在于跟踪垃圾回收过程。比如：能在这个对象被收集器回收时收到一个系统通知。 -
虚引用必须和引用队列一起使用。虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况。
-
由于虚引用可以跟踪对象的回收时间，因此，也可以将一些资源释放操作放置在虚引用中执行和记录。
虚引用无法获取到我们的数据
在JDK1.2版之后提供了PhantomReference类来实现虚引用。
// 声明强引用
Object obj = new Object();
// 声明引用队列
ReferenceQueue phantomQueue = new ReferenceQueue();
// 声明虚引用（还需要传入引用队列）
PhantomReference<Object> sf = new PhantomReference<>(obj, phantomQueue);
obj = null;
代码示例
public class PhantomReferenceTest {
// 当前类对象的声明
public static PhantomReferenceTest obj;
// 引用队列
static ReferenceQueue<PhantomReferenceTest> phantomQueue = null;
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("调用当前类的finalize方法");
obj = this;
}
public static void main(String[] args) {
Thread thread = new Thread(() -> {
while(true) {
if (phantomQueue != null) {
PhantomReference<PhantomReferenceTest> objt = null;
try {
objt = (PhantomReference<PhantomReferenceTest>) phantomQueue.remove();
} catch (Exception e) {
e.getStackTrace();
}
if (objt != null) {
System.out.println("追踪垃圾回收过程：PhantomReferenceTest实例被GC了");
}
}
}
}, "t1");
thread.setDaemon(true);// 设置守护线程：当程序中没有非守护线程时，守护线程就结束
thread.start();
phantomQueue = new ReferenceQueue<>();
obj = new PhantomReferenceTest();
// 构造了PhantomReferenceTest对象的虚引用，并指定了引用队列
PhantomReference<PhantomReferenceTest> phantomReference = new PhantomReference<>(obj, phantomQueue);
try {
System.out.println(phantomReference.get());
// 去除强引用
obj = null;
// 第一次进行GC，由于对象可复活，GC无法回收该对象
System.out.println("第一次GC操作");
System.gc();
Thread.sleep(1000);
if (obj == null) {
System.out.println("obj 是 null");
} else {
System.out.println("obj 不是 null");
}
System.out.println("第二次GC操作");
obj = null;
System.gc();// 一旦将obj对象回收，就会将虚引用存放到引用队列中。
Thread.sleep(1000);
if (obj == null) {
System.out.println("obj 是 null");
} else {
System.out.println("obj 不是 null");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
}
}
}
- 结果
null
第一次GC操作
调用当前类的finalize方法
obj 不是 null
第二次GC操作
追踪垃圾回收过程：PhantomReferenceTest实例被GC了
obj 是 null
- 从上述运行结果我们知道，第一次尝试获取虚引用的值，发现无法获取的，这是因为虚引用是无法直接获取对象的值，然后进行第一次gc，因为会调用finalize方法，将对象复活了，所以对象没有被回收，但是调用第二次gc操作的时候，因为finalize方法只能执行一次，所以就触发了GC操作，将对象回收了，同时将会触发第二个操作就是 将回收的值存入到引用队列中。
6.6终结器引用（Final reference）了解即可
- 它用于实现对象的finalize() 方法，也可以称为终结器引用
- 无需手动编码，其内部配合引用队列使用
- 在GC时，终结器引用入队。由Finalizer线程通过终结器引用找到被引用对象调用它的finalize()方法，第二次GC时才回收被引用的对象
7总结
| 类型 | 回收时间 | 使用场景 |
|---|---|---|
| 强引用 | 一直存活，除非GC Roots不可达 | 所有程序的场景，基本对象，自定义对象等。 |
| 软引用 | 内存不足时会被回收 | 一般用在对内存非常敏感的资源上，用作缓存的场景比较多，例如：网页缓存、图片缓存 |
| 弱引用 | 只能存活到下一次GC前 | 生命周期很短的对象，例如ThreadLocal中的Key。 |
| 虚引用 | 随时会被回收， 创建了可能很快就会被回收 | 业界暂无使用场景， 可能被JVM团队内部用来跟踪JVM的垃圾回收活动 |
第十七章 - 垃圾回收器
1.GC分类与性能指标
1.1GC分类
概述
-
垃圾回收器没有在规范中进行过多的规定，可以由不同厂商、不同版本的JVM来实现
-
由于JDK的版本在高速迭代过程中，因此Java发展至今已经衍生了众多的GC版本。
Java不同版本的新特性：
- 1.语法层面：Lambda表达式、switch、自动装箱、自动拆箱、enum、<>
- 2.API层面：Stream API、新的日期时间、Optional、String、集合框架
- 3.底层优化：JVM的优化，GC的变化、元空间、静态域、字符串常量池
-
从不同角度分析垃圾回收器，可以将GC分为不同的类型
-
按照线程数分，可以分为串行垃圾回收器和并行垃圾回收器 （指垃圾回收器的线程）
按线程数来分
串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直至垃圾收集工作结束。
- 在诸如单CPU处理器或者较小的应用内存等硬件平台不是特别优越的场合，串行回收器的性能表现可以超过并行回收器和并发回收器。所以，
串行回收默认被应用在客户端的Client模式下的JVM中 - 在并发能力比较强的CPU上，并行回收器产生的停顿时间要短于串行回收器。
和串行回收相反，并行收集可以运用多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用独占式，使用了“Stop-the-world”机制。
按工作模式分
按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器。
- 并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间。
- 独占式垃圾回收器（Stop the world）一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束。
按碎片处理方式分
按碎片处理方式分，可分为压缩武垃圾回收器和非压缩式垃圾回收器。
- 压缩式垃圾回收器会在回收完成后，对存活对象进行压缩整理，消除回收后的碎片。
- 再分配对象空间使用：指针碰撞
- 非压缩式的垃圾回收器不进行这步操作。
- 再分配对象空间使用：空闲列表
按工作的内存区间
按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器。
1.2评估GC的性能指标
-
吞吐量：运行用户代码的时间占总运行时间的比例- （总运行时间 = 程序的运行时间 + 内存回收的时间）
-
垃圾收集开销：吞吐量的补数，垃圾收集所用时间与总运行时间的比例。
-
暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。 -
收集频率：相对于应用程序的执行，收集操作发生的频率。
-
内存占用：Java堆区所占的内存大小。 -
快速：一个对象从诞生到被回收所经历的时间。
-
吞吐量、暂停时间、内存占用 共同构成了一个“不可能三角”, 三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。
-
这三项里，
暂停时间的重要性日益凸显。因为随着硬件发展，内存占用多些越来越能容忍，硬件性能的提升也有助于降低收集器运行时对应用程序的影响，即提高了吞吐量。 -
而内存的扩大，对延迟反而带来负面效果。 简单来说，主要抓住两点：
- 吞吐量
- 暂停时间
1.2.1性能指标：吞吐量
-
吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间 /（运行用户代码时间+垃圾收集时间）
- 比如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
-
这种情况下，应用程序能容忍较高的暂停时间，因此，高吞吐量的应用程序有更长的时间基准，快速响应是不必考虑的。
-
吞吐量优先，意味着在单位时间内，STW的时间最短：0.2 + 0.2 = 0.4
蓝色：用户线程红色：垃圾回收线程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0LAEKbvx-1684071932788)(JVM.assets/image-20211202092305312.png)]
1.2.2 性能指标：暂停时间
- “暂停时间”是指一个时间段内应用程序线程暂停，让GC线程执行的状态
- 例如，GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的。
- 暂停时间优先，意味着尽可能让单次STW的时间最短：0.1+0.1 + 0.1+ 0.1+ 0.1=0.5
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HjdaczDm-1684071932789)(JVM.assets/image-20211202092622638.png)]
1.2.3性能指标：吞吐量vs暂停时间
-
高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作。直觉上，吞吐量越高程序运行越快。
-
低暂停时间（低延迟）较好因为从最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型，
有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。因此，具有低的较大暂停时间是非常重要的，特别是对于一个交互式应用程序。 -
不幸的是”高吞吐量”和”低暂停时间”是一对相互竞争的目标（矛盾）。
- 因为如果选择以吞吐量优先，那么
必然需要降低内存回收的执行频率，但是这样会导致GC需要更长的暂停时间来执行内存回收。 - 相反的，如果选择以低延迟优先为原则，那么为了降低每次执行内存回收时的暂停时间，也
只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。
- 因为如果选择以吞吐量优先，那么
-
在设计（或使用）GC算法时，我们必须确定我们的目标：一个GC算法只可能针对两个目标之一（即只专注于较大吞吐量或最小暂停时间），或尝试找到一个二者的折衷。
-
现在标准：在最大吞吐量优先的情况下，降低停顿时间
2.不同等待垃圾回收器概述
-
垃圾收集机制是Java的招牌能力，极大地提高了开发效率。这当然也是面试的热点。
-
那么，Java常见的垃圾收集器有哪些？
- GC垃圾收集器是和JVM一脉相承的，它是和JVM进行搭配使用，在不同的使用场景对应的收集器也是有区别
2.1垃圾回收器发展史
有了虚拟机，就一定需要收集垃圾的机制，这就是Garbage Collection，对应的产品我们称为Garbage Collector。
- 1999年随JDK1.3.1一起来的是串行方式的serial Gc，它是第一款GC。ParNew垃圾收集器是Serial收集器的多线程版本
- 2002年2月26日，Parallel GC和Concurrent Mark Sweep GC跟随JDK1.4.2一起发布
- Parallel GC在JDK6之后成为HotSpot默认GC。
- 2012年，在JDK1.7u4版本中，G1可用。
- 2017年，JDK9中G1变成默认的垃圾收集器，以替代CMS。
- 2018年3月，JDK10中G1垃圾回收器的并行完整垃圾回收，实现并行性来改善最坏情况下的延迟。
- 2018年9月，JDK11发布。引入Epsilon 垃圾回收器，又被称为 "No-Op(无操作)“ 回收器。同时，引入ZGC：可伸缩的低延迟垃圾回收器（Experimental）
- 2019年3月，JDK12发布。增强G1，自动返回未用堆内存给操作系统。同时，引入Shenandoah GC：低停顿时间的GC（Experimental）。·2019年9月，JDK13发布。增强zGC，自动返回未用堆内存给操作系统。
- 2020年3月，JDK14发布。删除cMs垃圾回收器。扩展zGC在macos和Windows上的应用
7款经典垃圾收集器（在JDK11的ZGC之前）
- 串行回收器：Serial、Serial Old
- 并行收集器：ParNew、Parallel、Scavenge、Parallel Old
- 并发回收器：CMS、G1
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m09Z1CMu-1684071932789)(JVM.assets/image-20211202100109465.png)]
2.2 7款经典收集器与垃圾分代之间的关系
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hsgkRjIj-1684071932789)(JVM.assets/image-20211202100319240.png)]
- 新生代收集器：Serial、ParNew、Parallel 、Scavenge
- 老年代收集器：Serial Old、Parallel Old、CMS
- 整堆收集器：G1
2.3 垃圾收集器的组合关系
JDK8/9的变化:红线 JDK14的变化:绿色和青色的 虚线表示取消的组合关系
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Adymo5PA-1684071932789)(JVM.assets/image-20211202100646931.png)]
- 两个收集器间有连线，表明它们可以搭配使用：
- Serial/Serial old、Serial/CMS、ParNew/Serial old、ParNew/CMS、Parallel Scavenge/Serial Old、Parallel Scavenge/Parallel Old、G1；
- 其中Serial Old作为CMS出现"Concurrent Mode Failure"失败的后备预案。
- （红色虚线）由于维护和兼容性测试的成本，在JDK 8时将Serial+CMS、ParNew+Serial old这两个组合声明为废弃（JEP173），并在JDK9中完全取消了这些组合的支持（JEP214），即：移除。
- （绿色虚线）JDK14中：弃用Paralle1 Scavenge和Serialold GC组合（JEP366）
- （青色虚线）JDK14中：删除CMs垃圾回收器（JEP363）
2.4不同垃圾回收器概述
-
为什么要有很多收集器，一个不够吗？因为Java的使用场景很多，移动端，服务器等。所以就需要针对不同的场景，提供不同的垃圾收集器，提高垃圾收集的性能。
-
虽然我们会对各个收集器进行比较，但并非为了挑选一个最好的收集器出来。没有一种放之四海皆准、任何场景下都适用的完美收集器存在，更加没有万能的收集器。所以
我们选择的只是对具体应用最合适的收集器。
2.5如何查看默认垃圾收集器
-
-XX:+PrintcommandLineFlags：查看命令行相关参数（包含使用的垃圾收集器）-
随便运行一个程序，输出结果：
-XX:InitialHeapSize=266668608 -XX:MaxHeapSize=4266697728 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
-
-
使用命令行指令：
jinfo -flag相关垃圾回收器参数 进程ID
+号表示使用，-号表示没使用 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YqYEtz8q-1684071932790)(JVM.assets/image-20211202103238076.png)]
3.Serial回收器：串行回收
-
Serial收集器是最基本、历史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的选择。
-
Serial收集器作为HotSpot中client模式下的默认新生代垃圾收集器。
-
Serial收集器采用复制算法、串行回收和"stop-the-World"机制的方式执行内存回收。 -
除了年轻代之外，Serial收集器还提供用于执行老年代垃圾收集的Serial old收集器。
Serial old收集器同样也采用了串行回收和"stop the World"机制，只不过内存回收算法使用的是标记-压缩算法。- Serial Old是运行在Client模式下默认的老年代的垃圾回收器
- Serial Old在Server模式下主要有两个用途：
- ①与新生代的Parallel scavenge配合使用
- ②作为老年代CMS收集器的后备垃圾收集方案
这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束（Stop The World）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c18kONoi-1684071932790)(JVM.assets/image-20211202104049253.png)]
-
优势：
简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。- 运行在Client模式下的虚拟机是个不错的选择。
-
在用户的桌面应用场景中，可用内存一般不大（几十MB至一两百MB），可以在较短时间内完成垃圾收集（几十ms至一百多ms），只要不频繁发生，使用串行回收器是可以接受的。
-
在HotSpot虚拟机中，使用
-XX：+UseSerialGC参数可以指定年轻代和老年代都使用串行收集器。- 等价于新生代用Serial GC，且老年代用Serial Old GC
总结
-
这种垃圾收集器大家了解，现在已经不用串行的了。而且在限定单核cpu才可以用。现在都不是单核的了。
-
对于交互较强的应用而言，这种垃圾收集器是不能接受的。一般在Java web应用程序中是不会采用串行垃圾收集器的。
4.ParNew回收器：并行回收
- 如果说Serial GC是年轻代中的单线程垃圾收集器，那么ParNew收集器则是serial收集器的多线程版本。
- Par是Parallel的缩写，New:只能处理的是新生代
- ParNew收集器除了采用并行回收的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。ParNew收集器在年轻代中同样也是采用复制算法、"stop-the-World"机制
- ParNew是很多JVM运行在server模式下新生代的默认垃圾收集器。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-znygrQlf-1684071932790)(JVM.assets/image-20211202123611378.png)]
- 对于新生代，回收次数频繁，使用并行方式高效
- 对于老年代，回收次数少，使用串行方式节省资源（CPU并行需要切换线程，串行可以省去切换线程的资源）
由于ParNew收集器是基于并行回收，那么是否可以断定ParNew收集器的回收效率在任何场景下都会比serial收集器更高效？
-
ParNew 收集器运行再多CPU的环境下，由于可以充分利用多CPU、多核心等物理硬件资源优势，可以更快地完成垃圾收集，提升程序的吞吐量。
-
但是再单个CPU的环境下，ParNew收集器不比Serial收集器更高效。虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销。
-
因为除Serial外，目前只有ParNew GC能与CMS收集器配合工作
参数配置
-
在程序中，开发人员可以通过选项"
-XX：+UseParNewGC"手动指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代。 -
-XX:ParallelGCThreads限制线程数量，默认开启和CPU数据相同的线程数。
5.Parallel 回收器：吞吐量优先
-
HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外，Parallel Scavenge收集器同样也采用了复制算法、并行回收和"Stop the World"机制。
-
那么Parallel 收集器的出现是否多此一举？
- 和ParNew收集器不同，ParallelScavenge收集器的目标则是达到一个可控制的吞吐量（Throughput），它也被称为吞吐量优先的垃圾收集器。
- 自适应调节策略也是Paralle1 Scavenge与ParNew一个重要区别。
-
高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要
适合在后台运算而不需要太多交互的任务。因此，常见在服务器环境中使用。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序。 -
Parallel收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel old收集器，用来代替老年代的serialold收集器。
-
Parallel old收集器采用了
标记-压缩算法，但同样也是基于并行回收和"stop-the-World"机制。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-d4f0GzSx-1684071932790)(JVM.assets/image-20211202133656454.png)]
- 在程序吞吐量优先的应用场景中，Parallel 收集器和Parallel Old的结合在Server模式下的内存回收性能很不错
- Java8中默认是此收集器
参数设置
-
-XX：+UseParallelGC手动指定年轻代使用Parallel并行收集器执行内存回收任务。 -
-XX：+UseParalleloldGC手动指定老年代都是使用并行回收收集器。- 分别适用于新生代和老年代。默认jdk8是开启的。
- 上面两个参数，默认开启一个，另一个也会被开启。
（互相激活）
-
-XX:ParallelGCThreads设置年轻代并行收集器的线程数。一般地，最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能。-
在默认情况下，当CPU数量小于8个，ParallelGCThreads的值等于CPU数量。
当CPU数量大于8个，ParallelGCThreads的值等于3+[5*CPU_Count]/8]
-
-
-XX:MaxGCPauseMillis设置垃圾收集器最大停顿时间（也就是STW的时间）单位是毫秒- 为了尽可能地把停顿时间控制在MaxGCPauseMisll以内，收集器在工作时会调整Java堆大小或者其他一些参数。
- 对于用户来讲，停顿时间越短体验越好。但是在服务器端，我们注重高并发，整体的吞吐量。所以服务器端适合Parallel，进行控制。
- 使用此参数需要谨慎
-
-XX:GCTimeRatio垃圾回收时间占总时间的比例（= 1/（N+1）） 用于衡量吞吐量的大小- 取值范围（1~100 ） 默认99，也就是垃圾回收时间不超过1%。
- 与前一个-XX:MaxGCPauseMillis参数有一定矛盾性。暂停时间越长，Radio参数就容易超过设定的比例。
-
-XX:+UseAdaptiveSizePolicy设置Parallel scavenge收集器具有自适应调节策略- 在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。
- 在手动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量（GCTimeRatio）和停顿时间（MaxGCPauseMills），让虚拟机自己完成调优工作。
6.CMS回收器：低延时
-
在JDK1.5时期，HotSpot推出了一款在
强交互应用中几乎可认为有划时代意义的垃圾收集器：CMS（Concurrent-Mark-Sweep）收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。 -
CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。
目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
-
CMS的垃圾收集算法采用
标记-清除算法，并且也会"Stop-the-world" -
不幸的是，CMS作为老年代的收集器，却无法与JDK1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。
-
在G1出现之前，CMS使用还是非常广泛的。一直到今天，仍然有很多系统使用CMS GC。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZtSlvdIU-1684071932791)(JVM.assets/image-20211202155418495.png)]
工作原理
CMS整个过程比之前的收集器要复杂，整个过程分为4个主要阶段，即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。(涉及STW的阶段主要是：初始标记 和 重新标记)
- 初始标记（Initial-Mark）阶段：在这个阶段中，程序中所有的工作线程都将会因为“stop-the-world”机制而出现短暂的暂停，这个阶段的主要任务仅仅只是标记出GCRoots能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小，所以这里的
速度非常快。 - 并发标记（Concurrent-Mark）阶段：从Gc Roots的
直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。 - 重新标记（Remark）阶段：由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了
修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。 - 并发清除（Concurrent-Sweep）阶段：此阶段
清理删除掉标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的
分析
- 尽管CMS收集器采用的是并发回收（非独占式），但是在其
初始化标记和再次标记这两个阶段中仍然需要执行“Stop-the-World”机制暂停程序中的工作线程，不过暂停时间并不会太长，因此可以说明目前所有的垃圾收集器都做不到完全不需要“stop-the-World”，只是尽可能地缩短暂停时间。 由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的。- 另外，由于在垃圾收集阶段用户线程没有中断，所以
在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure” 失败，这时虚拟机将启动后备预案：临时启用Serial old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。
CMS收集器的垃圾收集算法采用的是标记清除算法，这意味着每次执行完内存回收后，由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，不可避免地将会产生一些内存碎片。那么CMS在为新对象分配内存空间时，将无法使用指针碰撞（Bump the Pointer）技术，而只能够选择空闲列表（Free List）执行内存分配。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MbDDqyhL-1684071932791)(JVM.assets/image-20211202161317984.png)]
CMS为什么不使用标记整理算法？
- 答案其实很简答，因为当并发清除的时候，用Compact整理内存的话，原来的用户线程使用的内存还怎么用呢？要保证用户线程能继续执行，前提的它运行的资源不受影响嘛。Mark Compact更适合“stop the world” 这种场景下使用
优点
- 并发收集
- 低延迟
弊端
会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发FullGC。CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。CMS收集器无法处理浮动垃圾。可能出现“Concurrent Mode Failure"失败而导致另一次Full GC的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间。
设置的参数
-
-XX：+UseConcMarkSweepGC手动指定使用CMS收集器执行内存回收任务。- 开启该参数后会自动将-XX：+UseParNewGC打开。即：ParNew（Young区用）+CMS（01d区用）+Serial old的组合。
-
-XX:CMSInitiatingoccupanyFraction设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。- JDK5及以前版本的默认值为68%，即当老年代的空间使用率达到68%时，会执行一次CMS回收。
JDK6及以上版本默认值为92% - 如果内存增长缓慢，则可以设置一个稍大的值，大的阀值可以有效降低CMS的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能。反之，如果应用程序内存使用率增长很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。因此
通过该选项便可以有效降低FullGc的执行次数。
- JDK5及以前版本的默认值为68%，即当老年代的空间使用率达到68%时，会执行一次CMS回收。
-
-XX：+UseCMSCompactAtFullCollection用于指定在执行完Full- GC后对内存空间进行压缩整理，以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。
-
-XX:CMSFullGCsBeforeCompaction设置在执行多少次FullGC后对内存空间进行压缩整理。 -
-XX:ParallelcMSThreads设置CMs的线程数量。- CMS默认启动的线程数是（ParallelGCThreads+3）/4，ParallelGCThreads是年轻代并行收集器的线程数。当CPU资源比较紧张时，受到CMS收集器线程的影响，应用程序的性能在垃圾回收阶段可能会非常糟糕。
小结
HotSpot有这么多的垃圾回收器，那么如果有人问，Serial GC、Parallel GC、Concurrent Mark Sweep GC这三个Gc有什么不同呢？
请记住以下口令：
- 如果你想要最小化地使用内存和并行开销，请选Serial GC；
- 如果你想要最大化应用程序的吞吐量，请选Parallel GC；
- 如果你想要最小化GC的中断或停顿时间，请选CMs GC。
JDK后续版本中CMS的变化
-
JDK9新特性：CMS被标记为eprecate了（JEP291）如果对JDK9及以上版本的HotSpot虚拟机使用参数-XX： +UseConcMarkSweepGC来开启CMS收集器的话，用户会收到一个警告信息，提示CMS未来将会被废弃。
-
JDK14新特性：删除CMs垃圾回收器（JEP363）移除了CMS垃圾收集器，如果在JDK14中使用 XX：+UseConcMarkSweepGC的话，JVM不会报错，只是给出一个warning信息，但是不会exit。JVM会自动回退以默认GC方式启动JVM
7.G1回收器：区域化分代式
既然我们已经有了前面几个强大的GC，为什么还要发布Garbage First（G1）？
-
原因就在于应用程序所应对的
业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序正常进行，而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化。G1（Garbage-First）垃圾回收器是在Java7 update 4之后引入的一个新的垃圾回收器，是当今收集器技术发展的最前沿成果之一。 -
与此同时，为了适应现在
不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间（pause time），同时兼顾良好的吞吐量。 -
官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以才担当起“全功能收集器”的重任与期望。
为什么名字叫 Garbage First(G1)呢？
-
因为G1是一个并行回收器，它把堆内存分割为很多不相关的区域(Region)(物理上不连续的)。使用不同的Region来表示Eden、幸存者0区，幸存者1区，老年代等。
-
G1 GC有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值)，在后台维护一个优先列表，
每次根据允许的收集时间，优先回收价值最大的Region。 -
由于这种方式的侧重点在于回收垃圾最大量的区间(Region)，所以我们给G1一个名字:垃圾优先(Garbage First)。
7.1概述
-
G1（Garbage-First）是一款面向服务端应用的垃圾收集器，
主要针对配备多核CPU及大容量内存的机器，以极高概率满足GC停顿时间的同时，还兼具高吞吐量的性能特征。 -
在JDK1.7版本正式启用，移除了Experimenta1的标识，
是JDK9以后的默认垃圾回收器，取代了CMS回收器以及Parallel+Parallel old组合。被oracle官方称为“全功能的垃圾收集器”。 -
与此同时，CMS已经在JDK9中被标记为废弃（deprecated）。在jdk8中还不是默认的垃圾回收器，需要使用-XX:+UseG1GC来启用。
7.2特点
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JgKktiIB-1684071932791)(JVM.assets/image-20211202193239239.png)]
与其他GC收集器相比，G1使用了全新的分区算法，其特点如下所示：
-
并行与并发- 并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。此时用户线程STW
- 并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况
-
分代收集- 从分代上看，
G1依然属于分代型垃圾回收器，它会区分年轻代和老年代，年轻代依然有Eden区和Survivor区。但从堆的结构上看，它不要求整个Eden区、年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量。 - 将
堆空间分为若干个区域（Region），这些区域中包含了逻辑上的年轻代和老年代。 - 和之前的各类回收器不同，它同时
兼顾年轻代和老年代。对比其他回收器，或者工作在年轻代，或者工作在老年代;
- 从分代上看，
-
G1所谓的分代，已经不是下面这样的了
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FTUO64Ev-1684071932791)(JVM.assets/image-20211202193519847.png)]
- 而是这样的一个区域
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yDoj51wz-1684071932792)(JVM.assets/image-20211202193540471.png)]
空间整合
- CMS：“标记-清除”算法、内存碎片、若干次GC后进行一次碎片整理
- G1将内存划分为一个个的region。内存的回收是以region作为基本单位的。
Region之间是复制算法，但整体上实际可看作是标记-压缩（Mark-Compact）算法，两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当Java堆非常大的时候，G1的优势更加明显。
可预测的停顿时间模型（即：软实时soft real-time）
这是G1相对于CMS的另一大优势，G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
- 由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。
- G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，
每次根据允许的收集时间，优先回收价值最大的Region。保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。 - 相比于CMSGC，G1未必能做到CMS在最好情况下的延时停顿，但是最差情况要好很多。
G1垃圾收集器的缺点
-
相较于CMS，G1还不具备全方位、压倒性优势。比如在用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用（Footprint）还是程序运行时的额外执行负载（overload）都要比CMS要高。
-
从经验上来说，在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。
7.3G1参数设置
-XX:+UseG1GC：手动指定使用G1垃圾收集器执行内存回收任务-XX:G1HeapRegionSize设置每个Region的大小。值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000。-XX:MaxGCPauseMillis设置期望达到的最大Gc停顿时间指标(JVM会尽力实现，但不保证达到)。默认值是200ms-XX:+ParallelGcThread设置STW工作线程数的值。最多设置为8-XX:ConcGCThreads设置并发标记的线程数。将n设置为并行垃圾回收线程数(ParallelGcThreads)的1/4左右。-XX:InitiatingHeapoccupancyPercent设置触发并发GC周期的Java堆占用率阈值。超过此值，就触发GC。默认值是45。
7.4 G1收集器的常见操作步骤
G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：
- 第一步：开启G1垃圾收集器
- 第二步：设置堆的最大内存
- 第三步：设置最大的停顿时间
G1中提供了三种垃圾回收模式：YoungGC、Mixed GC和FullGC，在不同的条件下被触发。
G1收集器的适用场景
-
面向服务端应用，针对具有大内存、多处理器的机器。（在普通大小的堆里表现并不惊喜）
-
最主要的应用是需要低GC延迟，并具有大堆的应用程序提供解决方案；
-
如：在堆大小约6GB或更大时，可预测的暂停时间可以低于0.5秒；（G1通过每次只清理一部分而不是全部的Region的增量式清理来保证每次Gc停顿时间不会过长）。 用来替换掉JDK1.5中的CMS收集器；
- 在下面的情况时，使用G1可能比CMS好：
- 超过50%的Java堆被活动数据占用；
- 对象分配频率或年代提升频率变化很大；
- GC停顿时间过长（长于0.5至1秒）
- 在下面的情况时，使用G1可能比CMS好：
-
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:G1HeapRegionsize设定。
所有的Region大小相同，且在JVM生命周期内不会被改变。 -
虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。通过Region的动态分配方式实现逻辑上的连续。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dkThE6ca-1684071932792)(JVM.assets/image-20211202202956601.png)]
-
一个region有可能属于Eden，Survivor或者old/Tenured内存区域。但是一个region只可能属于一个角色。图中的E表示该region属于Eden内存区域，s表示属于survivor内存区域，o表示属于old内存区域。图中空白的表示未使用的内存空间。
-
G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的H块。主要用于存储大对象，如果超过1.5个region，就放到H。
-
**设置H的原因：**对于堆中的对象，默认直接会被分配到老年代，但是如果它是一个短期存在的大对象就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放大对象。
如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Fu11Gc。G1的大多数行为都把H区作为老年代的一部分来看待。 -
每个Region都是通过指针碰撞来分配空间
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SHgDCx31-1684071932792)(JVM.assets/image-20211202203600406.png)]
7.5 G1垃圾回收器的回收过程
G1GC的垃圾回收过程主要包括如下三个环节：
-
年轻代GC（Young GC）
-
老年代并发标记过程（Concurrent Marking）
-
混合回收（Mixed GC）
-
(如果需要，单线程、独占式、高强度的FullGC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收。)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MZ6TLJrn-1684071932793)(JVM.assets/image-20211202210335457.png)]
- 顺时针，
young gc->young gc+concurrent mark->Mixed GC顺序，进行垃圾回收。
说明
-
应用程序分配内存，
当年轻代的Eden区用尽时开始年轻代回收过程；G1的年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期，G1GC暂停所有应用程序线程，启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到Survivor区间或者老年区间，也有可能是两个区间都会涉及。 -
当堆内存使用达到一定值（默认45%）时，开始老年代并发标记过程。
-
标记完成马上开始混合回收过程。对于一个混合回收期，G1GC从老年区间移动存活对象到空闲区间，这些空闲区间也就成为了老年代的一部分。和年轻代不同，老年代的G1回收器和其他GC不同，
G1的老年代回收器不需要整个老年代被回收，一次只需要扫描/回收一小部分老年代的Region就可以了。同时，这个老年代Region是和年轻代一起被回收的。 -
举个例子：一个Web服务器，Java进程最大堆内存为4G，每分钟响应1500个请求，每45秒钟会新分配大约2G的内存。G1会每45秒钟进行一次年轻代回收，每31个小时整个堆的使用率会达到45%，会开始老年代并发标记过程，标记完成后开始四到五次的混合回收。
7.6 Remembered 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；就可以保证不进行全局扫描，也不会有遗漏。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HpaTZ3Wb-1684071932793)(JVM.assets/image-20211203182806878.png)] 7.7 回收过程
G1回收过程一:年轻代GC
-
JVM启动时，G1先准备好Eden区，程序在运行过程中不断创建对象到Eden区，当Eden空间耗尽时，G1会启动一次年轻代垃圾回收过程。
-
年轻代垃圾回收只会回收Eden区和Survivor区
-
YGC时，首先G1停止应用程序的执行（stop-The-Wor1d），G1创建回收集（Collection Set），回收集是指需要被回收的内存分段的集合，年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z8xZUyla-1684071932793)(JVM.assets/image-20211203183459500.png)]
然后开始如下回收过程：
第一阶段，扫描根
根是指static变量指向的对象，正在执行的方法调用链条上的局部变量等。根引用连同RSet记录的外部引用作为扫描存活对象的入口。
第二阶段，更新RSet
处理dirty card queue（见备注）中的card，更新RSet。此阶段完成后，RSet可以准确的反映老年代对所在的内存分段中对象的引用。
第三阶段，处理RSet
识别被老年代对象指向的Eden中的对象，这些被指向的Eden中的对象被认为是存活的对象。
第四阶段，复制对象。
此阶段，对象树被遍历，Eden区内存段中存活的对象会被复制到Survivor区中空的内存分段，Survivor区内存段中存活的对象如果年龄未达阈值，年龄会加1，达到阀值会被会被复制到o1d区中空的内存分段。如果Survivor空间不够，Eden空间的部分数据会直接晋升到老年代空间。
第五阶段，处理引用
处理Soft，Weak，Phantom，Final，JNI Weak 等引用。最终Eden空间的数据为空，GC停止工作，而目标内存中的对象都是连续存储的，没有碎片，所以复制过程可以达到内存整理的效果，减少碎片。
G1回收过程二：并发标记过程
初始标记阶段：标记从根节点直接可达的对象。这个阶段是sTw的，并且会触发一次年轻代GC。根区域扫描（Root Region Scanning）：G1 Gc扫描survivor区直接可达的老年代区域对象，并标记被引用的对象。这一过程必须在youngGC之前完成。并发标记（Concurrent Marking）：在整个堆中进行并发标记（和应用程序并发执行），此过程可能被youngGC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那这个区域会被立即回收。同时，并发标记过程中，会计算每个区域的对象活性（区域中存活对象的比例）。再次标记（Remark）：由于应用程序持续进行，需要修正上一次的标记结果。是STW的。G1中采用了比CMS更快的初始快照算法：snapshot-at-the-beginning（SATB）。独占清理（cleanup，STW）：计算各个区域的存活对象和GC回收比例，并进行排序，识别可以混合回收的区域。为下阶段做铺垫。是STW的。- 这个阶段并不会实际上去做垃圾的收集
并发清理阶段：识别并清理完全空闲的区域。
G1回收过程三：混合回收
当越来越多的对象晋升到老年代o1d region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即Mixed GC，该算法并不是一个old GC，除了回收整个Young Region，还会回收一部分的old Region。
这里需要注意：是一部分老年代，而不是全部老年代。
可以选择哪些o1d Region进行收集，从而可以对垃圾回收的耗时时间进行控制。也要注意的是Mixed GC并不是Full GC。
- 并发标记结束以后，老年代中百分百为垃圾的内存分段被回收了，部分为垃圾的内存分段被计算了出来。默认情况下，这些老年代的内存分段会分8次（可以通过
-XX:G1MixedGCCountTarget设置）被回收。 - 混合回收的回收集(Collection Set）包括八分之一的老年代内存分段，Eden区内存分段，Survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样，只是回收集多了老年代的内存分段。具体过租请参考上面的年轻代回收过程。
- 由于老年代中的内存分段默认分8次回收，G1会优先回收垃圾多的内存分段。垃圾占内存分段比例越高的，越会被先回收。并且有一个阈值会决定内存分段是否被回收，
-XX:G1MixedGCLiveThresholdPercent，默认为65%，意思是垃圾占内存分段比例要达到65%才会被回收。如果垃圾占比太低，意味着存活的对象占比高，在复制的时候会花费更多的时间。 - 混合回收并不一定要进行8次。有一个阈值
-XX:G1HeapWastePercent，默认值为10%，意思是允许整个堆内存中有10%的空间被浪费，意味着如果发现可以回收的垃圾占堆内存的比例低于10%，则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存却很少。
G1回收过程四：Full GC
- G1的初衷就是要避免Full GC的出现。但是如果上述方式不能正常工作，G1会
停止应用程序的执行（Stop-The-World），使用单线程的内存回收算法进行垃圾回收，性能会非常差，应用程序停顿时间会很长。 - 要避免Full GC的发生，一旦发生需要进行调整。什么时候会发生Full GC呢?比如
堆内存太小，当G1在复制存活对象的时候没有空的内存分段可用，则会回退到full gc，这种情况可以通过增大内存解决。 - 导致G1Full GC的原因可能有两个:
- Evacuation的时候没有足够的to-space来存放晋升的对象;
- 并发处理过程完成之前空间耗尽。
G1回收过程：补充
- 从Oracle官方透露出来的信息可获知，回收阶段(Evacuation)其实本也有想过设计成与用户程序一起并发执行，但这件事情做起来比较复杂，考虑到G1只是回收一部分Region, 停顿时间是用户可控制的，所以并不迫切去实现，而
选择把这个特性放到了G1之后出现的低延迟垃圾收集器(即ZGC)中。另外，还考虑到G1不是仅仅面向低延迟，停顿用户线程能够最大幅度提高垃圾收集效率，为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。
G1回收器优化建议
- 年轻代大小
- 避免使用
-Xmn或-XX:NewRatio等相关选项显示设置年轻代大小 - 固定年轻代的大小会覆盖暂停时间目标
- 避免使用
- 暂停时间目标不要太过严苛
- G1 GC的吞吐量目标是90%的应用程序时间和10%的垃圾回收时间
- 评估G1 GC的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销，而这些会直接影响到吞吐量。
8.垃圾回收器总结
7种经典的垃圾回收器总结
- 截止JDK1.8，一共有7款不同的垃圾收集器。每一款的垃圾收集器都有不同的特点，在具体使用的时候，需要根据具体的情况选用不同的垃圾收集器。
- GC发展阶段：Seria l=> Parallel（并行）=> CMS（并发）=> G1 => ZGC
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GzbjQmGM-1684071932794)(JVM.assets/image-20211203191812133.png)]
- 不同厂商、不同版本的虚拟机实现差距比较大。HotSpot虚拟机在JDK7/8后所有收集器及组合如下图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0S56RPb0-1684071932794)(JVM.assets/image-20211203192424763.png)]
怎么选择垃圾回收器
-
Java垃圾收集器的配置对于JVM优化来说是一个很重要的选择，选择合适的垃圾收集器可以让JVM的性能有一个很大的提升。
-
怎么选择垃圾收集器？
- 优先调整堆的大小让JVM自适应完成。
- 如果内存小于100M，使用串行收集器
- 如果是单核、单机程序，并且没有停顿时间的要求，串行收集器
- 如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行或者JVM自己选择
- 如果是多CPU、追求低停顿时间，需快速响应（比如延迟不能超过1秒，如互联网应用），使用并发收集器
- 官方推荐G1，性能高。
现在互联网的项目，基本都是使用G1。
-
最后需要明确一个观点：
- 没有最好的收集器，更没有万能的收集
- 调优永远是针对特定场景、特定需求，不存在一劳永逸的收集器
面试
-
对于垃圾收集，面试官可以循序渐进从理论、实践各种角度深入，也未必是要求面试者什么都懂。但如果你懂得原理，一定会成为面试中的加分项。 这里较通用、基础性的部分如下：
- 垃圾收集的算法有哪些？
- 如何判断一个对象是否可以回收？
- 垃圾收集器工作的基本流程。
-
另外，大家需要多关注垃圾回收器这一章的各种常用的参数
9.GC日志分析
通过阅读Gc日志，我们可以了解Java虚拟机内存分配与回收策略。 内存分配与垃圾回收的参数列表
-XX:+PrintGC输出Gc日志。类似:-verbose:gc-XX:+PrintGCDetails输出Gc的详细日志-XX:+PrintGCTimestampsGc的时间戳（以基准时间的形式)-XX:+PrintGCDatestamps输出Gc的时间戳（以日期的形式，如2013-05-04T21:53:59.234+0800)-XX :+PrintHeapAtGC在进行GC前后打印出堆栈信息-Xloggc:../logs/gc.log日志文件的输出路径
verbose:gc
打开GC日志
-verbose:gc
- 这个只会显示总的GC堆的变化，如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XhkclIQc-1684071932794)(JVM.assets/image-20211203194737356.png)]
- 参数解析
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XVIQYb1B-1684071932795)(JVM.assets/image-20211203194815817.png)]
PrintGCDetails
打开GC日志
-verbose:gc -XX:+PrintGCDetails
- 输入信息如下
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fmPQphdo-1684071932795)(JVM.assets/image-20211203195421874.png)]
- 参数解析
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Pxy8C88N-1684071932795)(JVM.assets/image-20211203195438607.png)]
日志补充说明
- [GC"和"[FullGC"说明了这次垃圾收集的停顿类型，如果有"Full"则说明GC发生了"Stop The World"
- 使用Seria1收集器在新生代的名字是Default New Generation，因此显示的是"[DefNew"
- 使用ParNew收集器在新生代的名字会变成"[ParNew"，意思是"Parallel New Generation"
- 使用Parallel scavenge收集器在新生代的名字是”[PSYoungGen"
- 老年代的收集和新生代道理一样，名字也是收集器决定的
- 使用G1收集器的话，会显示为"garbage-first heap"
关于时间的说明
-
Allocation Failure
- 表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。
-
[PSYoungGen：5986K->696K（8704K）]5986K->704K（9216K）
- 中括号内：GC回收前年轻代大小，回收后大小，（年轻代总大小）
- 括号外：GC回收前年轻代和老年代大小，回收后大小，（年轻代和老年代总大小）
-
user代表用户态回收耗时，sys内核态回收耗时，rea实际耗时。由于多核的原因，时间总和可能会超过real时间
关于堆空间占用说明
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zGwotsnX-1684071932795)(JVM.assets/image-20211203200452129.png)]
GC日志中垃圾回收参数数据的分析
- Young GC图片
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5WKuw5fh-1684071932796)(JVM.assets/image-20211203200538384.png)]
- FullGC图片
GC回收举例
public class GCUseTest {
static final Integer _1MB = 1024 * 1024;
public static void main(String[] args) {
byte [] allocation1, allocation2, allocation3, allocation4;
allocation1 = new byte[2 *_1MB];
allocation2 = new byte[2 *_1MB];
allocation3 = new byte[2 *_1MB];
allocation4 = new byte[4 *_1MB];
}
}
- 设置JVM启动参数
-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+UseSerialGC
- 首先我们会将3个2M的数组存放到Eden区，然后后面4M的数组来了后，将无法存储，因为Eden区只剩下2M的剩余空间了，那么将会进行一次Young GC操作，将原来Eden区的内容，存放到Survivor区，但是Survivor区也存放不下，那么就会直接晋级存入Old 区
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ypTym0Xe-1684071932796)(JVM.assets/image-20211203202544021.png)]
- 然后我们将4M对象存入到Eden区中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2lMr61Ps-1684071932796)(JVM.assets/image-20211203203025720.png)]
日志分析工具
-
可以用一些工具去分析这些GC日志
-
常用的日志分析工具有：
GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat等
GCViewer
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-03CVy7dc-1684071932796)(JVM.assets/image-20211203203853221.png)]
GC easy(推荐)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bK9Z7MYP-1684071932797)(JVM.assets/image-20211203203916534.png)]
10.垃圾回收器的新发展
GC仍然处于飞速发展之中，目前的默认选项G1 GC在不断的进行改进，很多我们原来认为的缺点，例如串行的FullGC、Card Table扫描的低效等，都已经被大幅改进，例如，JDK10以后，FullGC已经是并行运行，在很多场景下，其表现还略优于ParallelGC的并行FullGC实现。
即使是SerialGC，虽然比较古老，但是简单的设计和实现未必就是过时的，它本身的开销，不管是GC相关数据结构的开销，还是线程的开销，都是非常小的，所以随着云计算的兴起，在serverless等新的应用场景下，Serial Gc找到了新的舞台。
比较不幸的是CMSGC，因为其算法的理论缺陷等原因，虽然现在还有非常大的用户群体，但在JDK9中已经被标记为废弃，并在JDK14版本中移除
jdk11新特性
-
Epsilon:A No-Op GarbageCollector（Epsilon垃圾回收器，"No-Op（无操作）"回收器）http://openidk.iava.net/ieps/318
-
ZGC:A Scalable Low-Latency Garbage Collector（Experimental）（ZGC：可伸缩的低延迟垃圾回收器，处于实验性阶段）
现在G1回收器已成为默认回收器好几年了。我们还看到了引入了两个新的收集器：ZGC（JDK11出现）和Shenandoah（Open JDK12）
主打特点：低停顿时间
Open JDK12的Shenandoash GC
Open JDK12的shenandoash GC：低停顿时间的GC（实验性）
Shenandoah，无疑是众多GC中最孤独的一个。是第一款不由oracle公司团队领导开发的Hotspot垃圾收集器。不可避免的受到官方的排挤。比如号称openJDK和OracleJDk没有区别的Oracle公司仍拒绝在oracleJDK12中支持Shenandoah。
Shenandoah垃圾回收器最初由RedHat进行的一项垃圾收集器研究项目Pauseless GC的实现，旨在针对JVM上的内存回收实现低停顿的需求。在2014年贡献给OpenJDK。
Red Hat研发Shenandoah团队对外宣称，Shenandoah垃圾回收器的暂停时间与堆大小无关，这意味着无论将堆设置为200MB还是200GB，99.9%的目标都可以把垃圾收集的停顿时间限制在十毫秒以内。不过实际使用性能将取决于实际工作堆的大小和工作负载。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QZVLwkam-1684071932797)(JVM.assets/image-20211203205200806.png)]
这是RedHat在2016年发表的论文数据，测试内容是使用Es对200GB的维基百科数据进行索引。从结果看：
- 停顿时间比其他几款收集器确实有了质的飞跃，但也未实现最大停顿时间控制在十毫秒以内的目标。 而吞吐量方面出现了明显的下降，总运行时间是所有测试收集器里最长的。
总结
- shenandoah GC的弱项：高运行负担下的吞吐量下降。
- shenandoah GC的强项：低延迟时间。
革命性的ZGC
ZGC与shenandoah目标高度相似，在尽可能对吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停颇时间限制在十毫秒以内的低延迟。
《深入理解Java虚拟机》一书中这样定义ZGC：2GC收集器是一款基于Region内存布局的，（暂时）不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-压缩算法的，以低延迟为首要目标的一款垃圾收集器。
ZGC的工作过程可以分为4个阶段：并发标记 - 并发预备重分配 - 并发重分配 - 并发重映射 等。
ZGC几乎在所有地方并发执行的，除了初始标记的是STW的。所以停顿时间几乎就耗费在初始标记上，这部分的实际时间是非常少的。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0xAy64US-1684071932797)(JVM.assets/image-20211203205318284.png)]
- 停顿时间对比
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Q1UFP7ms-1684071932797)(JVM.assets/image-20211203205344048.png)]
虽然ZGC还在试验状态，没有完成所有特性，但此时性能已经相当亮眼，用“令人震惊、革命性”来形容，不为过。 未来将在服务端、大内存、低延迟应用的首选垃圾收集器。
JDK14之前，2GC仅Linux才支持。
尽管许多使用zGc的用户都使用类Linux的环境，但在Windows和macos上，人们也需要ZGC进行开发部署和测试。许多桌面应用也可以从ZGC中受益。因此，2GC特性被移植到了Windows和macos上。
现在mac或Windows上也能使用ZGC了，示例如下：
AliGC
AliGC是阿里巴巴JVM团队基于G1算法，面向大堆（LargeHeap）应用场景。指定场景下的对比：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NXge1E5W-1684071932798)(JVM.assets/image-20211203205455784.png)]
当然，其它厂商也提供了各种别具一格的GC实现，例如比较有名的低延迟GC Zing
中篇：字节码与类的加载篇
下篇：性能监控与调优篇
此阶段，对象树被遍历，Eden区内存段中存活的对象会被复制到Survivor区中空的内存分段，Survivor区内存段中存活的对象如果年龄未达阈值，年龄会加1，达到阀值会被会被复制到o1d区中空的内存分段。如果Survivor空间不够，Eden空间的部分数据会直接晋升到老年代空间。
第五阶段，处理引用
处理Soft，Weak，Phantom，Final，JNI Weak 等引用。最终Eden空间的数据为空，GC停止工作，而目标内存中的对象都是连续存储的，没有碎片，所以复制过程可以达到内存整理的效果，减少碎片。
G1回收过程二：并发标记过程
初始标记阶段：标记从根节点直接可达的对象。这个阶段是sTw的，并且会触发一次年轻代GC。根区域扫描（Root Region Scanning）：G1 Gc扫描survivor区直接可达的老年代区域对象，并标记被引用的对象。这一过程必须在youngGC之前完成。并发标记（Concurrent Marking）：在整个堆中进行并发标记（和应用程序并发执行），此过程可能被youngGC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那这个区域会被立即回收。同时，并发标记过程中，会计算每个区域的对象活性（区域中存活对象的比例）。再次标记（Remark）：由于应用程序持续进行，需要修正上一次的标记结果。是STW的。G1中采用了比CMS更快的初始快照算法：snapshot-at-the-beginning（SATB）。独占清理（cleanup，STW）：计算各个区域的存活对象和GC回收比例，并进行排序，识别可以混合回收的区域。为下阶段做铺垫。是STW的。- 这个阶段并不会实际上去做垃圾的收集
并发清理阶段：识别并清理完全空闲的区域。
G1回收过程三：混合回收
当越来越多的对象晋升到老年代o1d region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即Mixed GC，该算法并不是一个old GC，除了回收整个Young Region，还会回收一部分的old Region。
这里需要注意：是一部分老年代，而不是全部老年代。
可以选择哪些o1d Region进行收集，从而可以对垃圾回收的耗时时间进行控制。也要注意的是Mixed GC并不是Full GC。
- 并发标记结束以后，老年代中百分百为垃圾的内存分段被回收了，部分为垃圾的内存分段被计算了出来。默认情况下，这些老年代的内存分段会分8次（可以通过
-XX:G1MixedGCCountTarget设置）被回收。 - 混合回收的回收集(Collection Set）包括八分之一的老年代内存分段，Eden区内存分段，Survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样，只是回收集多了老年代的内存分段。具体过租请参考上面的年轻代回收过程。
- 由于老年代中的内存分段默认分8次回收，G1会优先回收垃圾多的内存分段。垃圾占内存分段比例越高的，越会被先回收。并且有一个阈值会决定内存分段是否被回收，
-XX:G1MixedGCLiveThresholdPercent，默认为65%，意思是垃圾占内存分段比例要达到65%才会被回收。如果垃圾占比太低，意味着存活的对象占比高，在复制的时候会花费更多的时间。 - 混合回收并不一定要进行8次。有一个阈值
-XX:G1HeapWastePercent，默认值为10%，意思是允许整个堆内存中有10%的空间被浪费，意味着如果发现可以回收的垃圾占堆内存的比例低于10%，则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存却很少。
G1回收过程四：Full GC
- G1的初衷就是要避免Full GC的出现。但是如果上述方式不能正常工作，G1会
停止应用程序的执行（Stop-The-World），使用单线程的内存回收算法进行垃圾回收，性能会非常差，应用程序停顿时间会很长。 - 要避免Full GC的发生，一旦发生需要进行调整。什么时候会发生Full GC呢?比如
堆内存太小，当G1在复制存活对象的时候没有空的内存分段可用，则会回退到full gc，这种情况可以通过增大内存解决。 - 导致G1Full GC的原因可能有两个:
- Evacuation的时候没有足够的to-space来存放晋升的对象;
- 并发处理过程完成之前空间耗尽。
G1回收过程：补充
- 从Oracle官方透露出来的信息可获知，回收阶段(Evacuation)其实本也有想过设计成与用户程序一起并发执行，但这件事情做起来比较复杂，考虑到G1只是回收一部分Region, 停顿时间是用户可控制的，所以并不迫切去实现，而
选择把这个特性放到了G1之后出现的低延迟垃圾收集器(即ZGC)中。另外，还考虑到G1不是仅仅面向低延迟，停顿用户线程能够最大幅度提高垃圾收集效率，为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。
G1回收器优化建议
- 年轻代大小
- 避免使用
-Xmn或-XX:NewRatio等相关选项显示设置年轻代大小 - 固定年轻代的大小会覆盖暂停时间目标
- 避免使用
- 暂停时间目标不要太过严苛
- G1 GC的吞吐量目标是90%的应用程序时间和10%的垃圾回收时间
- 评估G1 GC的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销，而这些会直接影响到吞吐量。
8.垃圾回收器总结
7种经典的垃圾回收器总结
- 截止JDK1.8，一共有7款不同的垃圾收集器。每一款的垃圾收集器都有不同的特点，在具体使用的时候，需要根据具体的情况选用不同的垃圾收集器。
- GC发展阶段：Seria l=> Parallel（并行）=> CMS（并发）=> G1 => ZGC
[外链图片转存中…(img-GzbjQmGM-1684071932794)]
- 不同厂商、不同版本的虚拟机实现差距比较大。HotSpot虚拟机在JDK7/8后所有收集器及组合如下图
[外链图片转存中…(img-0S56RPb0-1684071932794)]
怎么选择垃圾回收器
-
Java垃圾收集器的配置对于JVM优化来说是一个很重要的选择，选择合适的垃圾收集器可以让JVM的性能有一个很大的提升。
-
怎么选择垃圾收集器？
- 优先调整堆的大小让JVM自适应完成。
- 如果内存小于100M，使用串行收集器
- 如果是单核、单机程序，并且没有停顿时间的要求，串行收集器
- 如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行或者JVM自己选择
- 如果是多CPU、追求低停顿时间，需快速响应（比如延迟不能超过1秒，如互联网应用），使用并发收集器
- 官方推荐G1，性能高。
现在互联网的项目，基本都是使用G1。
-
最后需要明确一个观点：
- 没有最好的收集器，更没有万能的收集
- 调优永远是针对特定场景、特定需求，不存在一劳永逸的收集器
面试
-
对于垃圾收集，面试官可以循序渐进从理论、实践各种角度深入，也未必是要求面试者什么都懂。但如果你懂得原理，一定会成为面试中的加分项。 这里较通用、基础性的部分如下：
- 垃圾收集的算法有哪些？
- 如何判断一个对象是否可以回收？
- 垃圾收集器工作的基本流程。
-
另外，大家需要多关注垃圾回收器这一章的各种常用的参数
9.GC日志分析
通过阅读Gc日志，我们可以了解Java虚拟机内存分配与回收策略。 内存分配与垃圾回收的参数列表
-XX:+PrintGC输出Gc日志。类似:-verbose:gc-XX:+PrintGCDetails输出Gc的详细日志-XX:+PrintGCTimestampsGc的时间戳（以基准时间的形式)-XX:+PrintGCDatestamps输出Gc的时间戳（以日期的形式，如2013-05-04T21:53:59.234+0800)-XX :+PrintHeapAtGC在进行GC前后打印出堆栈信息-Xloggc:../logs/gc.log日志文件的输出路径
verbose:gc
打开GC日志
-verbose:gc
- 这个只会显示总的GC堆的变化，如下：
[外链图片转存中…(img-XhkclIQc-1684071932794)]
- 参数解析
[外链图片转存中…(img-XVIQYb1B-1684071932795)]
PrintGCDetails
打开GC日志
-verbose:gc -XX:+PrintGCDetails
- 输入信息如下
[外链图片转存中…(img-fmPQphdo-1684071932795)]
- 参数解析
[外链图片转存中…(img-Pxy8C88N-1684071932795)]
日志补充说明
- [GC"和"[FullGC"说明了这次垃圾收集的停顿类型，如果有"Full"则说明GC发生了"Stop The World"
- 使用Seria1收集器在新生代的名字是Default New Generation，因此显示的是"[DefNew"
- 使用ParNew收集器在新生代的名字会变成"[ParNew"，意思是"Parallel New Generation"
- 使用Parallel scavenge收集器在新生代的名字是”[PSYoungGen"
- 老年代的收集和新生代道理一样，名字也是收集器决定的
- 使用G1收集器的话，会显示为"garbage-first heap"
关于时间的说明
-
Allocation Failure
- 表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。
-
[PSYoungGen：5986K->696K（8704K）]5986K->704K（9216K）
- 中括号内：GC回收前年轻代大小，回收后大小，（年轻代总大小）
- 括号外：GC回收前年轻代和老年代大小，回收后大小，（年轻代和老年代总大小）
-
user代表用户态回收耗时，sys内核态回收耗时，rea实际耗时。由于多核的原因，时间总和可能会超过real时间
关于堆空间占用说明
[外链图片转存中…(img-zGwotsnX-1684071932795)]
GC日志中垃圾回收参数数据的分析
- Young GC图片
[外链图片转存中…(img-5WKuw5fh-1684071932796)]
- FullGC图片
GC回收举例
public class GCUseTest {
static final Integer _1MB = 1024 * 1024;
public static void main(String[] args) {
byte [] allocation1, allocation2, allocation3, allocation4;
allocation1 = new byte[2 *_1MB];
allocation2 = new byte[2 *_1MB];
allocation3 = new byte[2 *_1MB];
allocation4 = new byte[4 *_1MB];
}
}
- 设置JVM启动参数
-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+UseSerialGC
- 首先我们会将3个2M的数组存放到Eden区，然后后面4M的数组来了后，将无法存储，因为Eden区只剩下2M的剩余空间了，那么将会进行一次Young GC操作，将原来Eden区的内容，存放到Survivor区，但是Survivor区也存放不下，那么就会直接晋级存入Old 区
[外链图片转存中…(img-ypTym0Xe-1684071932796)]
- 然后我们将4M对象存入到Eden区中
[外链图片转存中…(img-2lMr61Ps-1684071932796)]
日志分析工具
-
可以用一些工具去分析这些GC日志
-
常用的日志分析工具有：
GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat等
GCViewer
[外链图片转存中…(img-03CVy7dc-1684071932796)]
GC easy(推荐)
[外链图片转存中…(img-bK9Z7MYP-1684071932797)]
10.垃圾回收器的新发展
GC仍然处于飞速发展之中，目前的默认选项G1 GC在不断的进行改进，很多我们原来认为的缺点，例如串行的FullGC、Card Table扫描的低效等，都已经被大幅改进，例如，JDK10以后，FullGC已经是并行运行，在很多场景下，其表现还略优于ParallelGC的并行FullGC实现。
即使是SerialGC，虽然比较古老，但是简单的设计和实现未必就是过时的，它本身的开销，不管是GC相关数据结构的开销，还是线程的开销，都是非常小的，所以随着云计算的兴起，在serverless等新的应用场景下，Serial Gc找到了新的舞台。
比较不幸的是CMSGC，因为其算法的理论缺陷等原因，虽然现在还有非常大的用户群体，但在JDK9中已经被标记为废弃，并在JDK14版本中移除
jdk11新特性
-
Epsilon:A No-Op GarbageCollector（Epsilon垃圾回收器，"No-Op（无操作）"回收器）http://openidk.iava.net/ieps/318
-
ZGC:A Scalable Low-Latency Garbage Collector（Experimental）（ZGC：可伸缩的低延迟垃圾回收器，处于实验性阶段）
现在G1回收器已成为默认回收器好几年了。我们还看到了引入了两个新的收集器：ZGC（JDK11出现）和Shenandoah（Open JDK12）
主打特点：低停顿时间
Open JDK12的Shenandoash GC
Open JDK12的shenandoash GC：低停顿时间的GC（实验性）
Shenandoah，无疑是众多GC中最孤独的一个。是第一款不由oracle公司团队领导开发的Hotspot垃圾收集器。不可避免的受到官方的排挤。比如号称openJDK和OracleJDk没有区别的Oracle公司仍拒绝在oracleJDK12中支持Shenandoah。
Shenandoah垃圾回收器最初由RedHat进行的一项垃圾收集器研究项目Pauseless GC的实现，旨在针对JVM上的内存回收实现低停顿的需求。在2014年贡献给OpenJDK。
Red Hat研发Shenandoah团队对外宣称，Shenandoah垃圾回收器的暂停时间与堆大小无关，这意味着无论将堆设置为200MB还是200GB，99.9%的目标都可以把垃圾收集的停顿时间限制在十毫秒以内。不过实际使用性能将取决于实际工作堆的大小和工作负载。
[外链图片转存中…(img-QZVLwkam-1684071932797)]
这是RedHat在2016年发表的论文数据，测试内容是使用Es对200GB的维基百科数据进行索引。从结果看：
- 停顿时间比其他几款收集器确实有了质的飞跃，但也未实现最大停顿时间控制在十毫秒以内的目标。 而吞吐量方面出现了明显的下降，总运行时间是所有测试收集器里最长的。
总结
- shenandoah GC的弱项：高运行负担下的吞吐量下降。
- shenandoah GC的强项：低延迟时间。
革命性的ZGC
ZGC与shenandoah目标高度相似，在尽可能对吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停颇时间限制在十毫秒以内的低延迟。
《深入理解Java虚拟机》一书中这样定义ZGC：2GC收集器是一款基于Region内存布局的，（暂时）不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-压缩算法的，以低延迟为首要目标的一款垃圾收集器。
ZGC的工作过程可以分为4个阶段：并发标记 - 并发预备重分配 - 并发重分配 - 并发重映射 等。
ZGC几乎在所有地方并发执行的，除了初始标记的是STW的。所以停顿时间几乎就耗费在初始标记上，这部分的实际时间是非常少的。
[外链图片转存中…(img-0xAy64US-1684071932797)]
- 停顿时间对比
[外链图片转存中…(img-Q1UFP7ms-1684071932797)]
虽然ZGC还在试验状态，没有完成所有特性，但此时性能已经相当亮眼，用“令人震惊、革命性”来形容，不为过。 未来将在服务端、大内存、低延迟应用的首选垃圾收集器。
JDK14之前，2GC仅Linux才支持。
尽管许多使用zGc的用户都使用类Linux的环境，但在Windows和macos上，人们也需要ZGC进行开发部署和测试。许多桌面应用也可以从ZGC中受益。因此，2GC特性被移植到了Windows和macos上。
现在mac或Windows上也能使用ZGC了，示例如下：
AliGC
AliGC是阿里巴巴JVM团队基于G1算法，面向大堆（LargeHeap）应用场景。指定场景下的对比：
[外链图片转存中…(img-NXge1E5W-1684071932798)]
当然，其它厂商也提供了各种别具一格的GC实现，例如比较有名的低延迟GC Zing
770
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
