面试常见:
请你谈谈你对JVM的理解? JVM(Java虚拟机)是Java程序的运行环境,它允许Java程序在不同的平台上运行。JVM负责将Java源代码编译成字节码,并在运行时解释或编译执行这些字节码。JVM还负责内存管理、垃圾回收、安全性等任务。它的主要优点是跨平台性和自动内存管理。
java8虚拟机和之前的变化更新? Java 8的虚拟机相比之前的版本有一些变化和更新,其中包括:
- Lambda表达式和函数式接口的支持,使得在JVM中能更方便地使用函数式编程风格。
- 元空间(Metaspace)的引入,取代了永久代(Permanent Generation),用于存储类的元数据信息。
- 默认方法(Default Methods)的支持,允许接口中有具体的方法实现。
- 增强的垃圾回收器性能和功能。
- 新的时间和日期API(java.time包)的引入。
- 什么是OOM,什么是栈溢出StackOverFlowError? 怎么分析?
- OOM(Out of Memory)是指JVM内存不足,无法分配更多的内存给应用程序使用,导致应用程序无法继续执行的情况。这可能是由于堆内存溢出、方法区(元空间)溢出或者线程栈空间不足等原因引起的。
- 栈溢出(StackOverflowError)是指线程调用栈的深度超过了JVM所允许的最大深度,导致栈空间耗尽而抛出的错误。通常是由于递归调用或者方法调用层级过深引起的。
- 要分析这些问题,可以通过查看JVM的日志、堆栈跟踪信息以及内存使用情况来确定问题的根源,并可能通过调整JVM参数或者修改代码来解决问题。
- JVM的常用调优参数有哪些? 常用的JVM调优参数包括:
- -Xms:设置初始堆大小
- -Xmx:设置最大堆大小
- -Xss:设置线程栈大小
- -XX:PermSize和-XX:MaxPermSize:设置永久代(Java 8之前)或元空间(Java 8及之后)大小
- -XX:+UseG1GC:启用G1垃圾回收器
- -XX:+UseConcMarkSweepGC:启用CMS垃圾回收器
- -XX:MaxGCPauseMillis:设置最大垃圾回收停顿时间
- -XX:NewRatio:设置新生代与老年代的大小比例
内存快照如何抓取?怎么分析Dump文件? 内存快照可以通过JVM工具(如jmap、jcmd)或者第三方工具(如VisualVM、MAT)来抓取。分析Dump文件通常可以使用MAT(Memory Analyzer Tool)等工具,这些工具能够解析Dump文件并生成分析报告,帮助定位内存泄漏、对象占用过多内存等问题。
谈谈JVM中,类加载器你的认识? 类加载器负责将类文件加载到JVM中,并生成对应的Class对象。JVM中的类加载器主要分为三种:启动类加载器(Bootstrap ClassLoader)、扩展类加载器(Extension ClassLoader)和应用程序类加载器(Application ClassLoader)。类加载器采用双亲委派模型,即当一个类加载器收到加载类的请求时,它会先将请求委派给父类加载器处理,只有在父类加载器无法完成加载时,才会自己尝试加载。这种机制保证了类的唯一性和安全性。自定义类加载器可以实现一些特殊的类加载行为,例如从网络或者其他非标准的地方加载类。
JVM(Java虚拟机, Java Virtual Machine)是Java程序的运行环境,它负责解释Java字节码并将其转换为机器码以在特定平台上执行。JVM通常安装在操作系统之上,并提供了一个虚拟的运行时环境来执行Java应用程序。
JVM的位置通常取决于安装的Java开发工具包(JDK)。在安装了JDK的系统中,JVM的二进制文件通常存储在JDK安装目录的子目录中,例如在Windows系统中,它可能位于C:\Program Files\Java\jdk
目录下。
三种JVM:
我们学习都是:HotSpot
红色的为多个线程共享,灰色的为单个线程私有的
线程间共享:堆,方法区.
线程私有:程序计数器,栈,本地方法栈.
程序在执行之前先要把 java 代码转换成字节码(class 文件),jvm 首先需要把字节码通过一定的方式 类加载器(ClassLoader) 把文件加载到内存中的运行时数据区(Runtime Data Area)的方法区(Method Area) ,而字节码文件是 jvm 的一套指令集规范,并不能直接交个底层操作系统去执行,因此需要特定的命令解析器 执行引擎(Execution Engine) 将字节码翻译成底层系统指令再交由CPU 去执行,而这个过程中需要调用其他语言的接口 本地库接口(Native Interface) 来实现整个程序的功能,这就是这 4 个主要组成部分的职责与功能。
而我们通常所说的 JVM 组成指的是 运行时数据区(Runtime Data Area) ,因为通常需要程序员调试分析的区域就是“运行时数据区”,或者更具体的来说就是“运行时数据区”里面的 Heap(堆)模块。
jvm调优:99%都是在方法区和堆,大部分时间调堆。 JNI(java native interface)本地方法接口。
为什么栈和 P C 没有垃圾回收? \red {为什么栈和PC没有垃圾回收?} 为什么栈和PC没有垃圾回收?
栈(Stack)和 PC(Program Counter,程序计数器)通常不需要进行垃圾回收,因为它们所占用的内存空间具有确定的生命周期,并且由编译器或虚拟机进行管理。
栈: 栈是一种数据结构,用于存储函数调用时的局部变量、函数参数、返回地址等数据。栈上的数据存储遵循后进先出(LIFO)的原则,每当函数调用时,都会为该函数分配一块栈帧(Stack Frame)用于存储相关数据。当函数执行完毕时,其对应的栈帧会被弹出,从而释放其占用的内存空间。这种自动的分配和释放机制使得栈上的内存管理成本较低,并且不需要进行垃圾回收。
程序计数器: 程序计数器是一种特殊的寄存器,用于存储当前线程正在执行的指令地址。在程序执行过程中,程序计数器会随着指令的执行而不断更新,指向下一条将要执行的指令。程序计数器的生命周期与线程的生命周期密切相关,当线程结束时,程序计数器的内容也会被销毁。由于程序计数器的内容是由硬件直接管理的,因此不需要进行垃圾回收。
类加载器分类:
JVM角度
引导类加载器(启动类加载器 Bootstrap ClassLoader).
其他所有类加载器,这些类加载器由 java 语言实现,独立存在于虚拟机外部,并 且全部继承自抽象类 java.lang.ClassLoader.
开发人员角度
启动类加载器/根加载器/启动类加载器 Bootstrap ClassLoader
加载
JAVA_HOME\jre\lib\rt.jar
中的类(runtime, Java 运行环境的核心库目录)启动类加载器通常只加载指定的核心类库rt.jar,并不会加载
lib
目录下的其他 JAR 文件。这个类加载器使用 C/C++语言实现,嵌套在 JVM 内部.它用来加载 java 核心类库.并不继承于 java.lang.ClassLoader 没有父加载器,java 程序获取不到
负责加载扩展类加载器和应用类加载器,并为他们指定父类加载器.
出于安全考虑,引用类加载器只加载存放在
JAVA_HOME\jre\lib\rt.jar
目录,或者被-Xbootclasspath 参数锁指定的路径中存储放的类扩展类加载器 Extension ClassLoader
Java 语言编写的,由 sun.misc.Launcher$ExtClassLoader 实现.
派生于 ClassLoader 类.
系统类加载器/应用程序类加载器 System/App ClassLoader
从 java.ext.dirs 系统属性所指定的目录中加载类库,或从 JDK 系统安装目录的
JAVA_HOME\jre\lib\ext
子目录(扩展目录)下加载类库.如果用户创建的 jar 放在此目录下,也会自动由扩展类加载器加载Java 语言编写的,由 sun.misc.Launcher$AppClassLoader 实现.
派生于 ClassLoader 类.
加载我们自己定义的类,用于加载用户类路径(classpath)上所有的类.
该类加载器是程序中默认的类加载器.
ClassLoader 类 , 它 是 一 个 抽 象 类 , 其 后 所 有 的 类 加 载 器 都 继 承 自 ClassLoader(不包括启动类加载器)
package github.JVM.Demo01;
/** * @author subeiLY * @create 2021-06-08 07:42 */
public class Test01 {
public static void main(String[] args) {
Test01 test01 = new Test01();
Test01 test02 = new Test01();
Test01 test03 = new Test01();
System.out.println(test01.hashCode());
System.out.println(test02.hashCode());
System.out.println(test03.hashCode());
/*18360192403250408041173230247 */
Class<? extends Test01> aClass1 = test01.getClass();
ClassLoader classLoader = aClass1.getClassLoader();
System.out.println(classLoader);
System.out.println(classLoader.getParent());
System.out.println(classLoader.getParent().getParent());
/*sun.misc.Launcher$AppClassLoader@18b4aac2sun.misc.Launcher$ExtClassLoader@330bedb4null */
Class<? extends Test01> aClass2 = test02.getClass();
Class<? extends Test01> aClass3 = test03.getClass();
System.out.println(aClass1.hashCode());
System.out.println(aClass2.hashCode());
System.out.println(aClass3.hashCode());
/* 2133927002 2133927002 2133927002 */
}
}
类加载器的分类
类加载过程:
2、2、1 加载:
- 通过类名(地址)获取此类的二进制字节流。
- 将这个字节流所代表的静态存储结构转换为方法区(元空间)的运行时结构。
- 在内存中生成一个代表这个类的 java.lang.Class 对象,作为这个类的各种数据的访问入口。
2、2、2 链接:
- 验证:
- 文件格式验证:检查 class 文件是否以 CA FE BA BE 开头。
- 主、次版本号验证:确认版本号在当前 Java 虚拟机接收范围内。对于 Java 17.0.1,其主版本号是 17,次版本号是 0, 1 表示补丁或更新版本。
- 元数据验证:对字节码描述的信息进行语义分析,确保符合 Java 语言规范的要求。
- 准备:
- 为类的静态属性分配内存,并设置默认初始值。
- 不包含用
final
修饰的 static 常量,在编译时进行初始化。
- 解析:
- 将类的二进制数据中的符号引用替换成直接引用。(符号引用是 Class 文件的逻辑符号,直接引用指向的方法区中某一个地址)
2、2、3 初始化:
- 为类的静态变量赋予正确的初始值,执行类构造器方法
的过程。该方法是编译器自动收集类中所有类变量的赋值动作和静态代码块中的语句合并而来的。
()
实例化过程:
类加载完成 + 以下过程
- 创建对象:一旦类加载和初始化完成,就可以创建该类的对象实例了。对象实例化的过程包括:
分配内存空间:在堆内存中为对象分配内存空间,内存大小取决于对象的大小和结构。
初始化对象:将对象的实例变量(即非静态变量)设置为默认值,如果有显式的初始化操作,则会执行对应的初始化代码。
调用构造方法:在内存中分配了足够的空间后,会调用对象的构造方法进行初始化。构造方法负责对对象进行初始化操作,可以设置对象的初始状态和执行其他必要的操作。
- 返回引用:对象实例化完成后,会返回对象的引用,以便能够在程序中使用该对象。
类什么时候初始化:
new
关键字创建对象。main
函数。引用该类的静态常量,但注意只有已经指定字面量的常量不会导致初始化,对于需要计算才能得出结果的常量会导致类加载。
//不会导致类初始化,被动使用
public final static int NUMBER = 5 ;
//会导致类加载
public final static int RANDOM = new Random().nextInt() ;
构造某个类的数组时不会导致该类的初始化。
Student[] students = new Student[10] ;
package java.lang;
/** * @author subeiLY * @create 2021-06-08 08:06 */
public class String {
/* 双亲委派机制:安全
1.APP-->EXC-->BOOT(最终执行) BOOT EXC APP */
public String toString() {
return "Hello";
}
public static void main(String[] args) {
String s = new String();
System.out.println(s.getClass());
s.toString();
}
/*
1.类加载器收到类加载的请求
2.将这个请求向上委托给父类加载器去完成,一直向上委托,知道启动类加载
3.启动加载器检查是否能够加载当前这个类,能加载就结束,使用当前的加载器,
否则,抛出异常,适知子加载器进行加载
4.重复步骤3 */
}
双亲委派机制
如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请 求委托给父类的加载器去执行.
如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终 将到达顶层的启动类加载器.
如果父类加载器可以完成类的加载任务,就成功返回,倘若父类加载器无法完 成加载任务,子加载器才会尝试自己去加载,这就是双亲委派机制.
如果均加载失败,就会抛出 ClassNotFoundException 异常。
优点:
安全:可避免用户自己编写的类替换 Java 的核心类,如 java.lang.String.
避免类重复加载:当父亲已经加载了该类时,就没有必要子 ClassLoader 再加载一次
如何打破双亲委派机制
Java 虚拟机的类加载器本身可以满足加载的要求,但是也允许开发者自定义类加载器。
在 ClassLoader 类中涉及类加载的方法有两个,loadClass(String name), findClass(String name),这两个方法并没有被 final 修饰,也就表示其他子类可以重写.
重写 loadClass 方法(是实现双亲委派逻辑的地方,修改他会破坏双亲委派机制, 不推荐)
重写 findClass 方法 (推荐)
我们可以通过自定义类加载重写方法打破双亲委派机制, 再例如 tomcat 等都有自己定义的类加载器.
关于双亲委派机制的博客:
双亲委派模型中,类加载器之间的父子关系一般不会以继承(Inheritance)的关系来实现,而是都使用组合(Composition)关系来复用父加载器的代码的。
实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中, 主要就是以下几个步骤:
1、先检查类是否已经被加载过
2、若没有加载则调用父加载器的loadClass()方法进行加载
3、若父加载器为空则默认使用启动类加载器作为父加载器。
4、如果父类加载失败,抛出ClassNotFoundException异常后,再调用自己的findClass()方法进行加载。
如何主动破坏双亲委派机制?
知道了双亲委派模型的实现,那么想要破坏双亲委派机制就很简单了。
因为他的双亲委派过程都是在loadClass方法中实现的,那么想要破坏这种机制,那么就自定义一个类加载器,重写其中的loadClass方法,使其不进行双亲委派即可。
双亲委派被破坏的例子
双亲委派机制的破坏不是什么稀奇的事情,很多框架、容器等都会破坏这种机制来实现某些功能。
- 第一种被破坏的情况是在双亲委派出现之前。
由于双亲委派模型是在JDK1.2之后才被引入的,而在这之前已经有用户自定义类加载器在用了。所以,这些是没有遵守双亲委派原则的。
第二种,是JNDI、JDBC等需要加载SPI接口实现类的情况。
DriverManager是被根加载器加载的,那么在加载时遇到以上代码,会尝试加载所有Driver的实现类,但是这些实现类基本都是第三方提供的,根据双亲委派原则,第三方的类不能被根加载器加载。
于是,就在JDBC中通过引入ThreadContextClassLoader(线程上下文加载器,默认情况下是AppClassLoader)的方式破坏了双亲委派原则。
第三种是为了实现热插拔热部署工具。为了让代码动态生效而无需重启,实现方式时把模块连同类加载器一起换掉就实现了代码的热替换。
第四种时tomcat等web容器的出现。
Tomcat是web容器,那么一个web容器可能需要部署多个应用程序。
不同的应用程序可能会依赖同一个第三方类库的不同版本,但是不同版本的类库中某一个类的全路径名可能是一样的。
如多个应用都要依赖hollis.jar,但是A应用需要依赖1.0.0版本,但是B应用需要依赖1.0.1版本。这两个版本中都有一个类是com.hollis.Test.class。
如果采用默认的双亲委派类加载机制,那么是无法加载多个相同的类。
所以,Tomcat破坏双亲委派原则,提供隔离的机制,为每个web容器单独提供一个WebAppClassLoader加载器。
第五种时OSGI、Jigsaw等模块化技术的应用。
概念:当某个类加载器需要加载某个.class文件时,它首先把这个任务委托给他的上级类加载器,递归这个操作,如果上级的类加载器没有加载,自己才会去加载这个类。
例子:当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器,首先会在AppClassLoader中检查是否加载过,如果有那就无需再加载了。如果没有,那么会拿到父加载器,然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过,如果没有再往上。注意这个类似递归的过程,直到到达Bootstrap classLoader之前,都是在检查是否加载过,并不会选择自己去加载。直到BootstrapClassLoader,已经没有父加载器了,这时候开始考虑自己是否能加载了,如果自己无法加载,会下沉到子加载器去加载,一直到最底层,如果没有任何加载器能加载,就会抛出ClassNotFoundException。
从上到下第一个ExtClassLoader 改为 BootstrapClassLoader
作用:
比如:如果有人想替换系统级别的类:String.java。篡改它的实现,在这种机制下这些系统的类已经被Bootstrap classLoader加载过了(为什么?因为当一个类需要加载的时候,最先去尝试加载的就是BootstrapClassLoader),所以其他类加载器并没有机会再去加载,从一定程度上防止了危险代码的植入。
Java安全模型的核心就是Java沙箱(sandbox),什么是沙箱?沙箱是一个限制程序运行的环境。沙箱机制就是将Java代码限定在虚拟机(JVM)特定的运行范围中,并且严格限制代码对本地系统资源访问,通过这样的措施来保证对代码的有效隔离,防止对本地系统造成破坏。沙箱主要限制系统资源访问,那系统资源包括什么?CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。
所有的Java程序运行都可以指定沙箱,可以定制安全策略。
在]ava中将执行程序分成本地代码和远程代码两种,本地代码默认视为可信任的,而远程代码则被看作是不受信的。对于授信的本地代码,可以访问一切本地资源。而对于非授信的远程代码在早期的ava实现中,安全依赖于沙箱(Sandbox)机制。如下图所示JDK1.0安全模型。
但如此严格的安全机制也给程序的功能扩展带来障碍,比如当用户希望远程代码访问本地系统的文件时候,就无法实现。因此在后续的Java1.1 版本中,针对安全机制做了改进,增加了安全策略,允许用户指定代码对本地资源的访问权限。如下图所示JDK1.1安全模型。
在Java1.2版本中,再次改进了安全机制,增加了代码签名。不论本地代码或是远程代码,都会按照用户的安全策略设定,由类加载器加载到虚拟机中权限不同的运行空间,来实现差异化的代码执行权限控制。如下图所示JDK1.2安全模型。
当前最新的安全机制实现,则引入了域(Domain)的概念。虚拟机会把所有代码加载到不同的系统域和应用域,系统域部分专门负责与关键资源进行交互,而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域(Protected Domain),对应不一样的权限(Permission)。存在于不同域中的类文件就具有了当前域的全部权限,如下图所示最新的安全模型(jdk 1.6)。
组成沙箱的基本组件:
字节码校验器(bytecode verifier)
︰确保Java类文件遵循lava语言规范。这样可以帮助java程序实现内存保护。但并不是所有的类文件都会经过字节码校验,比如核心类。
类装载器(class loader)
:其中类装载器在3个方面对Java沙箱起作用:
。它防止恶意代码去干涉善意的代码;
。它守护了被信任的类库边界;
。它将代码归入保护域,确定了代码可以进行哪些操作。
虚拟机为不同的类加载器载入的类提供不同的命名空间,命名空间由一系列唯一的名称组成,每一个被装载的类将有一个名字,这个命名空间是由Java虚拟机为每一个类装载器维护的,它们互相之间甚至不可见。
类装载器采用的机制是双亲委派模式。
1.从最内层VM自带类加载器开始加载,外层恶意同名类得不到加载从而无法使用;
2.由于严格通过包来区分了访问域,外层恶意的类通过内置代码也无法获得权限访问到内层类,破坏代码就自然无法生效。
存取控制器(access controller)
︰存取控制器可以控制核心API对操作系统的存取权限,而这个控制的策略设定,可以由用户指定。安全管理器(security manager)
︰是核心API和操作系统之间的主要接口。实现权限控制,比存取控制器优先级高。安全软件包(security package)
: java.security下的类和扩展包下的类,允许用户为自己的应用增加新的安全特性,包括:
Java 本地方法(Native Methods)是一种允许 Java 程序调用本地(即非 Java)代码的机制。本地方法是使用特殊关键字 native
声明的 Java 方法,其实现由非 Java 语言编写,通常是由 C 或 C++ 编写的。
Java 本地方法通常用于以下几种情况:
使用本地方法时,需要在 Java 中声明本地方法,并在本地方法库中提供相应的实现。Java 虚拟机在执行本地方法时会调用本地方法库中对应的函数。
跨平台兼容性、安全性问题以及调试困难等。因此,应该谨慎使用本地方法,并优先考虑在纯 Java 环境中实现功能。
public static void main(String[] args) {
new Thread(()->{ },"your thread name").start();
}
public synchronized void start() {
if (threadStatus != 0)
throw new IllegalThreadStateException();
group.add(this);
boolean started = false;
try {
start0(); // 调用了一个start0方法
started = true;
} finally {
try {
if (!started) {
group.threadStartFailed(this);
}
} catch (Throwable ignore) {
}
}
}
// 这个Thread是一个类,这个方法定义在这里是不是很诡异!看这个关键字native;
private native void start0();
凡是带了native关键字的,说明 java的作用范围达不到,去调用底层C语言的库!
JNI:Java Native Interface(Java本地方法接口)
凡是带了native关键字的方法就会进入本地方法栈;
Native Method Stack 本地方法栈
本地接口的作用是融合不同的编程语言为Java所用,它的初衷是融合C/C++程序,Java在诞生的时候是C/C++横行的时候,想要立足,必须有调用C、C++的程序,于是就在内存中专门开辟了一块区域处理标记为native的代码,它的具体做法是 在 Native Method Stack 中登记native方法,在 执行引擎( ExecutionEngine )执行的时候加载Native Libraies。
目前该方法使用的越来越少了,除非是与硬件有关的应用,比如通过Java程序驱动打印机或者Java系统管理生产设备,在企业级应用中已经比较少见。因为现在的异构领域间通信很发达,比如可以使用Socket通信,也可以使用Web Service等等,不多做介绍!
程序计数器:Program Counter Register
PC寄存器(Program Counter Register)是计算机体系结构中的一个重要概念,特别是在处理器的执行过程中。它通常用于指示处理器当前正在执行的指令的位置或下一条要执行的指令的位置。
它是一块很小的内存空间,几乎可以忽略不计,也是运行速度最快的存储区域.
在 JVM 规范中,每个线程都有它自己的程序计数器,是线程私有的,生命周期与线程生命周期保持一致.
程序计数器会存储当前线程正在执行的 Java 方法的 JVM 指令地址.
它是程序控制流的指示器,分支,循环,跳转,异常处理,线程恢复等基础功能都需要依赖这个计数器来完成.
它是唯一一个在java虚拟机规范中没有规定任何OutOfMemoryError情况的区域
早期也叫 Java 栈,描述的是 Java 方法执行的内存模型,每个方法在执行的同时都会创建一个线帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息,每个方法从调用直至执行完成的过程,都对应着一个线帧在虚拟机栈中入栈到出栈的过程。
栈的特点
栈是一种快速有效的分配存储方式,访问速度仅次于程序计数器.
JVM 直接对 java 栈的操作只有两个:调用方法 入栈 .执行结束后 出栈 .
对于栈来说不存在垃圾回收问题.
栈中会出现异常,当线程请求的栈深度大于虚拟机所允许的深度时 , 会出现StackOverflowError.
栈的运行原理
栈的内部结构
与虚拟机栈的作用是一样的,只不过虚拟机栈是服务 Java 方法的,而本地方法栈是为虚拟机调用 Native 方法服务的。
方法区基本理解
存储加载的类信息和元数据,包括类的结构信息、方法、字段等。
存储静态变量,如 static 变量。
存储常量,包括 static final 常量。
存储运行时常量池,即类加载时将字面量和符号引用转换为直接引用的内存区域。
在类加载过程中,虚拟机会将这些字面量和符号引用在运行时常量池中进行动态转换,即将它们转换为直接引用。这个过程中,如果需要解析符号引用所代表的目标,则会在运行时常量池中进行符号解析,找到对应的目标。这样,运行时常量池最终存储的是符号引用解析后的直接引用,这些直接引用指向了实际的类、字段、方法等目标。
当 JVM 启动时,方法区被创建。
它的物理内存空间可以与 Java 堆一样不连续。
方法区的大小可以选择固定或可扩展,与堆空间类似。
方法区的大小决定了系统可以保存多少个类,如果定义了太多类导致方法区溢出,虚拟机会抛出内存溢出错误。
关闭 JVM 将释放方法区的内存。
方法区,栈,堆的交互关系
方法区大小设置
Java 方法区的大小不是固定的,而是可以根据应用的需要进行动态调整。在 Java 8 及以后的版本中,方法区被替代为元空间(Metaspace),它的大小可以通过参数 -XX:MetaspaceSize
和 -XX:MaxMetaspaceSize
来指定,代替了原来的 -XX:PermSize
和 -XX:MaxPermSize
参数。
默认情况下,元空间大小依赖于平台。在 Windows 系统下,默认的 -XX:MetaspaceSize
是 21MB,而 -XX:MaxMetaspaceSize
的值为 -1,表示没有限制。
元空间的初始值(即 -XX:MetaspaceSize
)为 21MB,也被称为高水位线。一旦元空间的使用量达到这个值,就会触发 Full GC。为了减少 Full GC 的频率,可以将 -XX:MetaspaceSize
设置为较高的值。
方法区的内部结构
方法区存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存以及运行时常量池等。
运行时常量池是其中的一部分,是一张表格,虚拟机指令根据其中的内容找到要执行的类名、方法名、参数类型、字面量(常量)等信息。
编译期间生成的各种字面量(常量)和符号引用都存放在运行时常量池中。
可通过反编译字节码文件查看其中的内容,使用参数 -p
可确保能够查看私有权限类型的字段或方法。
javap -v -p Hello.class > Hello.txt
// Hello.java
public class Hello {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
// Hello.txt
Classfile /D:/Desktop/test/Hello.class
Last modified 2024-5-26; size 416 bytes
MD5 checksum e5f397cd2507c3d6e46867c5e9c957c6
Compiled from "Hello.java"
public class Hello
minor version: 0
major version: 55
flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
#1 = Methodref #6.#15 // java/lang/Object."":()V
#2 = Fieldref #16.#17 // java/lang/System.out:Ljava/io/PrintStream;
#3 = String #18 // Hello World!
#4 = Methodref #19.#20 // java/io/PrintStream.println:(Ljava/lang/String;)V
#5 = Class #21 // Hello
#6 = Class #22 // java/lang/Object
#7 = Utf8 <init>
#8 = Utf8 ()V
#9 = Utf8 Code
#10 = Utf8 LineNumberTable
#11 = Utf8 main
#12 = Utf8 ([Ljava/lang/String;)V
#13 = Utf8 SourceFile
#14 = Utf8 Hello.java
#15 = NameAndType #7:#8 // "":()V
#16 = Class #23 // java/lang/System
#17 = NameAndType #24:#25 // out:Ljava/io/PrintStream;
#18 = Utf8 Hello World!
#19 = Class #26 // java/io/PrintStream
#20 = NameAndType #27:#28 // println:(Ljava/lang/String;)V
#21 = Utf8 Hello
#22 = Utf8 java/lang/Object
#23 = Utf8 java/lang/System
#24 = Utf8 out
#25 = Utf8 Ljava/io/PrintStream;
#26 = Utf8 java/io/PrintStream
#27 = Utf8 println
#28 = Utf8 (Ljava/lang/String;)V
{
public Hello();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."":()V
4: return
LineNumberTable:
line 1: 0
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=1, args_size=1
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String Hello World!
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
LineNumberTable:
line 3: 0
line 4: 8
}
SourceFile: "Hello.java"
方法区的垃圾回收
方法区(例如 Hotspot 虚拟机中的元空间或者永久代)并非没有垃圾收集行为。尽管《Java 虚拟机规范》对方法区的约束非常宽松,甚至可以不要求虚拟机在方法区中实现垃圾收集,但实际情况并非如此。方法区的垃圾收集虽然难以达到令人满意的效果,特别是在类卸载方面,条件相当苛刻,但有时却是必要的。
方法区的垃圾收集主要涉及两部分内容:清理运行时常量池中废弃的常量和不再使用的类型,也称为类卸载。
判定一个常量是否“废弃”相对较简单,但判定一个类型是否属于“不再被使用的类”则更为苛刻,需要同时满足以下三个条件:
java.lang.Class
对象没有在任何地方被引用,无法通过反射访问该类的方法。
存储类的结构信息、静态变量、常量、方法字节码等数据
方法区主要包含以下内容:
类信息(Class Information):方法区存储了加载的类的元数据信息,包括类的名称、父类的名称、类的修饰符、方法和字段的描述符等。这些信息对于JVM在运行时动态加载、链接和执行类非常重要。
静态变量(Static Variables):类的静态变量被存储在方法区中。这些变量在类加载时被分配内存,并在整个程序执行期间保持不变。静态变量的生命周期与类的生命周期相同。
常量池(Constant Pool),JDK7之前:方法区中包含了常量池,用于存储类中的字面常量、符号引用等信息。常量池中的内容包括类和接口的全限定名、字段和方法的名称和描述符、字符串常量等。
方法字节码(Method Bytecode), .class文件:类中的方法字节码被存储在方法区中。这些字节码被JVM解释执行或者编译成本地机器代码执行。
运行时常量池(Runtime Constant Pool):与常量池对应的是运行时常量池,它是常量池的一部分,用于存储编译时生成的字面常量和符号引用,在类加载后被JVM转换为运行时数据结构。
过度使用静态变量、大量的类加载、频繁的字符串常量等操作都可能导致方法区内存溢出的问题。
概述:
-Xms:10m
(堆起始大小)和 -Xmx:30m
(堆最大内存大小)。堆内存区域划分:
Java8 及之后堆内存分为 :新生区(新生代)+老年区(老年代)
新生区分为 Eden(伊甸园)区和 Survivor(幸存者)区
为什么分区(代)?
将对象根据存活概率进行分类,对存活时间长的对象,放到固定区,从而减少扫描垃圾时间及 GC 频率。
针对分类进行不同的垃圾回收算法,对算法扬长避短。
对象创建内存分配过程
在 JVM 中,为新对象分配内存是一个复杂而严谨的任务。设计者需要考虑内存分配的位置、算法以及与内存回收相关的问题,包括内存碎片的产生。整个过程如下:
-XX:MaxTenuringThreshold=
设置。Java.lang.OutOfMemoryError:Java heap space
。新生区与老年区配置比例
在 Java 虚拟机中,可以通过调整堆结构的配置来优化内存使用,其中包括新生代与老年代的占比以及伊甸园和幸存者空间的比例。
默认情况下,新生代与老年代在堆结构中的占比由参数 -XX:NewRatio 控制,默认值为 2。这表示新生代占 1,老年代占 2,新生代占整个堆的 1/3。如果需要调整,可以设置为其他值,例如 -XX:NewRatio=4,表示新生代占 1,老年代占 4,新生代占整个堆的 1/5。通过调整老年代的大小,可以优化项目中生命周期较长对象的存储。
在 HotSpot 虚拟机中,默认情况下,伊甸园区(Eden)和两个幸存者空间(Survivor)的比例为 8:1:1。可以通过选项 -XX:SurvivorRatio 进行调整。例如,设置 -XX:SurvivorRatio=8,表示调整幸存者空间的比例,此时新生区的对象默认生命周期超过 15 次,将会被转移到老年代进行养老。
分代收集思想 Minor GC、Major GC、Full GC
在 JVM 进行垃圾回收(GC)时,并非每次都会同时回收新生代和老年代,通常大部分情况下只会回收新生代。HotSpot VM 实现了两种主要类型的垃圾回收,即部分收集和整堆收集:
Full GC(Full Garbage Collection)会回收整个Java堆(Heap),包括新生代(Young Generation)、老年代(Old Generation)以及永久代(如果是经典的Java 8及之前版本)或元空间(如果是Java 8及之后的版本)中的对象。
System.gc();
方法时。堆空间的参数设置
官网地址
| 参数 |描述 |
| :–: | :–: |
| -XX:+PrintFlagsInitial | 查看所有参数的默认初始值 |
| -XX:+PrintFlagsFinal | 查看所有参数的最终值(修改后的值) |
| -Xms | 初始堆空间内存(默认为物理内存的 1/64) |
| -Xmx | 最大堆空间内存(默认为物理内存的 1/4) |
| -Xmn | 设置新生代的大小(初始值及最大值) |
| -XX:NewRatio | 配置新生代与老年代在堆结构的占比 |
| -XX:SurvivorRatio | 设置新生代中 Eden 和 S0/S1 空间比例 |
| -XX:MaxTenuringTreshold| 设置新生代垃圾的最大年龄 |
| XX:+PrintGCDetails | 输出详细的 GC 处理日志 |
注意: 字符串常量池所在区域的变化?为啥? \red{字符串常量池所在区域的变化?为啥?} 字符串常量池所在区域的变化?为啥?
{–1)提高回收效率,避免永久代溢出;2)更好的GC控制}
JDK1.7 之前,运行时常量池包含的字符串常量池和静态变量存放在方法区, 此时 HotSpot 虚拟机对方法区的实现为永久代。
JDK1.7 字符串常量池和静态变量被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区, 也就是 HotSpot 中的永久代 。
JDK1.8 HotSpot 移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池和静态变量还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace)
字符串常量池有什么作用?
字符串重用,避免重复创建。
字符串常量池为什么要调整位置(
)
提高GC效率,避免永久代溢出(因为JDK7方法区的实现还是永久代)
JDK7 及以后的版本中将字符串常量池放到了堆空间中。因为方法区的回收效率很低,在 Full GC 的时候才会执行永久代的垃圾回收,而 Full GC 是老年代的空间不足、方法区不足时才会触发。
这就导致字符串常量池回收效率不高,而我们开发中会有大量的字符串被创建,回收效率低,导致永久代内存不足。放到堆里,能及时回收内存。
将字符串常量池移到堆空间中,使得它可以享受到堆空间自动调整大小的优势,避免了永久代内存溢出的问题。
永久代的垃圾收集行为与新生代和老年代不同,这增加了 GC 管理的复杂性。通过将字符串常量池移到堆空间中,可以统一 GC 对整个堆空间的管理,简化了 GC 管理的逻辑。
新生区是类诞生,成长,消亡的区域,一个类在这里产生,应用,最后被垃圾回收器收集,结束生命。
新生区又分为两部分:伊甸区(Eden Space)和幸存者区(Survivor Space),所有的类都是在伊甸区被new出来的,幸存区有两个:0区 和 1区,当伊甸园的空间用完时,程序又需要创建对象,JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)。将伊甸园中的剩余对象移动到幸存0区,若幸存0区也满了,再对该区进行垃圾回收,然后移动到1区,那如果1区也满了呢?(这里幸存0区和1区是一个互相交替的过程)再移动到养老区,若养老区也满了,那么这个时候将产生MajorGC(Full GC),进行养老区的内存清理,若养老区执行了Full GC后发现依然无法进行对象的保存,就会产生OOM异常 “OutOfMemoryError ”。如果出现 java.lang.OutOfMemoryError:java heap space异常,说明Java虚拟机的堆内存不够,原因如下:
1、Java虚拟机的堆内存设置不够,可以通过参数 -Xms(初始值大小),-Xmx(最大大小)来调整。
2、代码中创建了大量大对象,并且长时间不能被垃圾收集器收集(存在被引用)或者死循环。
熟悉三区结构后方可学习JVM垃圾回收机制
实际而言,方法区(Method Area)和堆一样,是各个线程共享的内存区域,它用于存储虚拟机加载的:类信息+普通常量+静态常量+编译器编译后的代码,虽然JVM规范将方法区描述为堆的一个逻辑部分,但它却还有一个别名,叫做Non-Heap(非堆),目的就是要和堆分开。
对于HotSpot虚拟机,很多开发者习惯将方法区称之为 “永久代(Parmanent Gen)”,但严格本质上说两者不同,或者说使用永久代实现方法区而已,永久代是方法区(相当于是一个接口interface)的一个实现,Jdk1.7的版本中,已经将原本放在永久代的字符串常量池移走。
常量池(Constant Pool)是方法区的一部分,Class文件除了有类的版本,字段,方法,接口描述信息外,还有一项信息就是常量池,这部分内容将在类加载后进入方法区的运行时常量池中存放!
runtime.totalMemory()
:
- 这个方法返回Java虚拟机当前已经使用的内存量。
- 它表示当前已经分配给Java虚拟机的内存量,包括已使用的和尚未使用的部分。
- 在Java程序运行期间,随着内存的分配和释放,这个值可能会不断变化。
runtime.maxMemory()
:
- 这个方法返回Java虚拟机试图使用的最大内存量。
- 它表示Java虚拟机能够从操作系统获取的最大内存量。
- 当Java程序运行时,Java虚拟机会根据需要动态调整可用内存的大小,但不会超过这个最大内存量。
runtime.freeMemory()
这个方法返回Java虚拟机当前空闲的内存量,即还没有被分配给程序使用的内存。
它表示Java虚拟机中尚未被分配的、可用于新对象分配的内存量。
在Java程序运行期间,这个值可能会随着程序的内存分配和释放而不断变化。
测试1
代码测试
默认情况下:分配的总内存是电脑内存的1/4,初始化的内存是电脑的1/64
public class Test {
public static void main(String[] args) {
Runtime runtime = Runtime.getRuntime();
System.out.println("runtime.availableProcessors(): " + runtime.availableProcessors());
double maxMemory = (double) runtime.maxMemory();
double totalMemory = (double) runtime.totalMemory();
double freeMemory = (double) runtime.freeMemory();
double usedMemory = totalMemory - freeMemory;
System.out.println("runtime.maxMemory(): " + maxMemory + "bytes, " + (maxMemory / 1024) + "KB, " + (maxMemory / 1024 / 1024) + "MB, " + (maxMemory / 1024 / 1024 / 1024) + "GB");
System.out.println("runtime.totalMemory(): " + totalMemory + "bytes, " + (totalMemory / 1024) + "KB, " + (totalMemory / 1024 / 1024) + "MB");
System.out.println("runtime.freeMemory(): " + freeMemory + "bytes, " + (freeMemory / 1024) + "KB, " + (freeMemory / 1024 / 1024) + "MB");
System.out.println("usedMemory: " + usedMemory + "bytes, " + (usedMemory / 1024) + "KB, " + (usedMemory / 1024 / 1024) + "MB");
}
}
runtime.availableProcessors(): 16
runtime.maxMemory(): 3.754426368E9bytes, 3666432.0KB, 3580.5MB, 3.49658203125GB
runtime.totalMemory(): 2.53231104E8bytes, 247296.0KB, 241.5MB
runtime.freeMemory(): 2.47940152E8bytes, 242129.0546875KB, 236.45415496826172MB
usedMemory: 5290952.0bytes, 5166.9453125KB, 5.045845031738281MB
JVM参数缩写的含义–帮助记忆
JVM的参数缩写很容易混淆,理解每个参数的具体含义可以帮助记忆。VM选项有三种:
- : 标准VM选项,VM规范的选项
-X: 非标准VM选项,不保证所有VM支持
-XX: 高级选项,高级特性,但属于不稳定的选项对于第二类参数,其语义分别是
-Xms
: 堆的初始化初始化大小,助记:memory startup
-Xmx
: 堆的最大内存数,等同于-XX:MaxHeapSize,助记:memory maximum
-Xmn
: 堆中新生代初始及最大大小,如果需要进一步细化,初始化大小用-XX:NewSize,最大大小用-XX:MaxNewSize,助记:memory nursery/new
-Xss
: 线程栈大小,等同于-XX:ThreadStackSize,助记:stack size
发现,默认的情况下分配的内存是总内存的 1/4,而初始化的内存为 1/64 !
-Xms1024m -Xmx1024m -XX:+PrintGCDetails
305664 K ( P S Y o u n g G e n ) + 699392 K ( P a r O l d G e n ) = 1005056 K B = 981.5 M B 305664K(PSYoungGen) + 699392K(ParOldGen) = 1005056KB = 981.5MB 305664K(PSYoungGen)+699392K(ParOldGen)=1005056KB=981.5MB
测试2
代码:
package github.JVM.Demo02;
import java.util.Random;
/** * @author subeiLY * @create 2021-06-08 10:22 */
public class Demo02 {
public static void main(String[] args) {
String str = "suneiLY";
while (true) {
str += str + new Random().nextInt(88888888)
+ new Random().nextInt(999999999);
}
}
}
-Xms8m -Xmx8m -XX:+PrintGCDetails
这是一个young 区域撑爆的JAVA 内存日志,其中 PSYoungGen 表示 youngGen分区的变化, 1536k 表示 GC 之前的大小, 488k 表示GC 之后的大小。
整个Young区域的大小从 1536K 到 672K , young代的总大小为 7680K。
user – 总计本次 GC 总线程所占用的总 CPU 时间。
sys – OS 调用 or 等待系统时间。
real – 应用暂停时间。
如果GC 线程是 Serial Garbage Collector 串行搜集器的方式的话(只有一条GC线程,), real time 等于user 和 system 时间之和。
通过日志发现Young的区域到最后 GC 之前后都是0,old 区域 无法释放,最后报堆溢出错误。
其他文章链接
什么是垃圾
不再被程序所引用的对象或数据
为什么需要GC
简化内存管理
防止内存泄漏
降低内存碎片化,提高内存利用率
应该关心哪些区域的回收
垃圾收集器可以针对不同区域进行回收,包括年轻代、老年代、全栈(包括本地方法栈和虚拟机栈)以及方法区(元空间)等。在这些区域中,Java 堆通常是垃圾收集器的主要工作重点。
从回收频率来看,通常有以下情况:
频繁收集 Young 区:年轻代中的对象通常具有较短的生命周期,因此需要经常进行回收。年轻代的垃圾收集通常使用较轻量的垃圾收集算法,如复制算法,以提高回收效率。
较少收集 Old 区:老年代中的对象通常具有较长的生命周期,因此需要较少的回收。老年代的垃圾收集通常使用更复杂的垃圾收集算法,如标记-清除算法或标记-整理算法,以提高效率并减少对应用程序的影响。
基本不收集元空间(方法区):元空间(方法区)通常用于存储类的结构信息、常量池、静态变量等,它的内存管理由 JVM 自行管理,并不像 Java 堆那样频繁进行对象的分配和回收。在某些情况下,可能会触发类的卸载,但是这种情况相对较少,因此元空间的回收频率通常很低。
方法区和永久代以及元空间有什么关系
永久代以及元空间是 HotSpot 虚拟机对虚拟机规范中方法区的两种实现方式
为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace)
避免永久代内存溢出
减少 Full GC概率
Dump 转储
在运行java程序的时候,有时候想测试运行时占用内存情况,这时候就需要使用测试工具查看了。在eclipse里面有 Eclipse Memory Analyzer tool(MAT)插件可以测试,而在idea中也有这么一个插件,就是JProfiler,一款性能瓶颈分析工具!
作用:
分析Dump文件,快速定位内存泄漏;
获得堆中对象的统计数据
获得对象相互引用的关系
采用树形展现对象间相互引用的情况
安装JProfiler
// 注册码仅供大家参考
L-Larry_Lau@163.com#23874-hrwpdp1sh1wrn#0620
L-Larry_Lau@163.com#36573-fdkscp15axjj6#25257
L-Larry_Lau@163.com#5481-ucjn4a16rvd98#6038
L-Larry_Lau@163.com#99016-hli5ay1ylizjj#27215
L-Larry_Lau@163.com#40775-3wle0g1uin5c1#0674
package github.JVM.Demo02;
import java.util.ArrayList;
/** * @author subeiLY * @create 2021-06-08 11:13 */
public class Demo03 {
byte[] byteArray = new byte[1*1024*1024]; // 1M = 1024K
public static void main(String[] args) {
ArrayList<Demo03> list = new ArrayList<>();
int count = 0;
try {
while (true) {
list.add(new Demo03()); // 问题所在
count = count + 1;
}
} catch (Error e) {
System.out.println("count:" + count);
e.printStackTrace();
}
}
}
-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError
使用 Jprofiler 工具分析查看
双击这个文件默认使用 Jprofiler 进行 Open大的对象!
大对象
Thread Dump – 线程转储
垃圾标记阶段: 主要是为了判断对象是否是垃圾对象
判断方法: 引用计数算法和可达性分析算法
每个对象有一个引用计数器,当对象被引用一次则计数器加1,当对象引用失效一次,则计数器减1,对于计数器为0的对象意味着是垃圾对象,可以被GC回收。
目前虚拟机基本都是采用可达性算法,从GC Roots 作为起点开始搜索,那么整个连通图中的对象边都是活对象,对于GC Roots 无法到达的对象变成了垃圾回收对象,随时可被GC回收。
优点
实现简单,垃圾对象便于辨识;
判定效率高,回收没有延迟性。
缺点
它需要单独的字段存储计数器,这样的做法增加了存储空间的开销。
每次赋值都需要更新计数器,伴随着加法和减法操作,这增加了时间开销。
引用计数器有一个严重的问题,即无法处理循环引用的情况。这是一条致命缺陷,导致在.Java 的垃圾回收器中没有使用这类算法。
可达性分析算法,也称为根搜索算法或追踪性垃圾收集,是一种用于垃圾收集的算法。相对于引用计数算法而言,可达性分析算法具有以下优势:
解决循环引用问题:可达性分析算法能够有效地解决引用计数算法中可能出现的循环引用问题。在循环引用的情况下,引用计数算法可能导致对象永远无法被回收,从而导致内存泄漏。而可达性分析算法通过搜索对象之间的引用关系,可以准确地确定对象是否可达,避免了这一问题的发生。
实现简单高效:可达性分析算法实现相对简单,并且执行效率较高。该算法的核心思想是从一组根对象开始,通过遍历对象之间的引用关系,标记出所有可达的对象,然后将未被标记的对象视为垃圾进行回收。这种算法能够有效地识别和回收不再被程序引用的对象,从而释放内存空间。
被Java和C#选择:Java和C#等现代编程语言选择了可达性分析算法作为其垃圾收集的主要算法。这是因为可达性分析算法能够更好地应对复杂的内存管理场景,保证程序的内存使用效率和稳定性。追踪性垃圾收集(Tracing Garbage Collection)就是可达性分析算法的一种实现方式。
可达性分析实现思路
所谓"GCRoots”根就是一组必须活跃的引用
其基本思路如下:
GC Roots 可以是哪些元素?
虚拟机栈中引用的对象:包括各个线程被调用的方法中使用到的参数、局部变量等。当线程执行一个方法时,虚拟机栈会为该方法创建一个栈帧,栈帧中包含了该方法的局部变量表,其中存放了对对象的引用。
方法区中类静态属性引用的对象:例如,Java 类的引用类型静态变量。类的静态变量存放在方法区中,如果某个静态变量引用了一个对象,则该对象会被视为 GC Roots。
所有被同步锁 synchronized 持有的对象:当一个对象被某个线程持有了同步锁,即进入了同步代码块或同步方法,那么该对象被认为是 GC Roots。
Java 虚拟机内部的引用:这包括基本数据类型对应的 Class 对象,以及一些常驻的异常对象,如 NullPointerException、OutOfMemoryError 等,以及系统类加载器等。
对象的 Finalization 机制
finalize() 方法机制:
finalize()
方法是对象销毁前的回调方法。- Java 提供了对象终止(finalization)机制,允许开发人员提供对象被销毁之前的自定义处理逻辑。
- 当垃圾回收器发现没有引用指向一个对象时,即将垃圾回收此对象之前,总会先调用该对象的
finalize()
方法,每个对象的finalize()
方法只会被调用一次。finalize()
方法允许在子类中被重写,用于在对象被回收时进行资源释放,比如关闭文件、套接字和数据库连接等。Object 类中
finalize()
源码:protected void finalize() throws Throwable { }
注意事项:
- 永远不要主动调用某个对象的
finalize()
方法,应该交给垃圾回收机制调用。- 原因包括:
- 在
finalize()
时可能会导致对象复活。finalize()
方法的执行时间不确定,完全由 GC 线程决定,极端情况下,若不发生 GC,则finalize()
方法将没有执行机会。- 一个糟糕的
finalize()
方法会严重影响 GC 的性能,比如死循环。生存还是死亡?
由于
finalize()
方法的存在,虚拟机中的对象一般处于三种可能的状态:
- 可触及的:从根节点开始,可以到达这个对象。
- 可复活的:对象的所有引用都被释放,但是对象有可能在
finalize()
中复活。- 不可触及的:对象的
finalize()
被调用,并且没有复活,那么就会进入不可触及状态。具体过程:
- 判定一个对象是否可回收,至少要经历两次标记过程:
- 如果对象到 GC Roots 没有引用链,则进行第一次标记。
- 进行筛选,判断此对象是否有必要执行
finalize()
方法:
- 如果对象没有重写
finalize()
方法,或者finalize()
方法已经被虚拟机调用过,则视为“没有必要执行”,对象被判定为不可触及的。- 如果对象重写了
finalize()
方法,且还未执行过,那么会被插入到队列中,由 Finalizer 线程触发其finalize()
方法执行。finalize()
方法是对象逃脱死亡的最后机会,稍后 GC 会对队列中的对象进行第二次标记。- 如果对象在
finalize()
方法中与引用链上的任何一个对象建立了联系,那么会被移出“即将回收”集合,之后对象会再次出现没有引用存在的情况,这时finalize()
方法不会再次调用,对象会直接变成不可触及的状态。
什么是复制算法?
执行过程
对象分配阶段: 初始时,所有的新对象都会被分配到 Eden 区。
Minor GC 触发: 当 Eden 区填满时,会触发 Minor GC(也称为新生代 GC)。
存活对象复制: 在 Minor GC 过程中,GC 首先会检查所有存活的对象,并将它们复制到 Survivor 区中的一个。如果一个对象经过一次 Minor GC 后仍然存活,它就会被复制到另一个 Survivor 区,而不是被清除。通常来说,每次 Minor GC 后,存活的对象都会被复制到一个新的 Survivor 区。
年龄增加: 经过多次 Minor GC 后,存活的对象会逐渐增加年龄。一般来说,每经过一次 Minor GC,对象的年龄就会增加一岁。当一个对象的年龄达到一定阈值(通常是 15 岁),它就会被晋升到老年代(Old Generation)。
Major GC 触发: 在老年代空间不足或进行 Full GC(全局垃圾回收)时,会触发 Major GC(老年代 GC)。这时,会对整个堆内存进行清理和整理。
优点
- 解决了内存碎片问题由于每次回收后存活对象都会被移动到一个新的区域,因此不会产生内存碎片。
- 简单高效实现简单,不需要进行复杂的内存整理操作(标记,清除),同时也可以高效地回收大量的短生命周期对象。
缺点
- 双倍内存消耗由于需要将存活对象复制到另一个区域,因此需要额外的内存空间。
- 无法处理长生命周期对象对于长时间存活的对象,需要经过多次 Minor GC 后才会被晋升到老年代,这可能会导致老年代的内存占用过高。
应用场景
如果系统中的垃圾对象很多,复制算法需要复制的存活对象数量并不会太大,效率较高
老年代大量的对象存活,那么复制的对象将会有很多,效率会很低
在新生代,对常规应用的垃圾回收,一次通常可以回收 70% - 99% 的内存空间。回收性价比很高。所以现在的商业虚拟机都是用这种收集算法回收新生代
Minor GC 会把Eden中的所有活的对象都移到Survivor区域中,如果Survivor区中放不下,那么剩下的活的对象就被移动到Old generation中,也就是说,一旦收集后,Eden就是变成空的了
当对象在Eden(包括一个Survivor区域,这里假设是From区域)出生后,在经过一次Minor GC后,如果对象还存活,并且能够被另外一块Survivor区域所容纳 (上面已经假设为from区域,这里应为to区域,即to区域有足够的内存空间来存储Eden 和 From 区域中存活的对象),则使用复制算法将这些仍然还活着的对象复制到另外一块Survivor区域(即 to 区域)中,然后清理所使用过的Eden 以及Survivor 区域(即form区域),并且将这些对象的年龄设置为1,以后对象在Survivor区,每熬过一次MinorGC,就将这个对象的年龄 + 1,当这个对象的年龄达到某一个值的时候(默认是15岁,通过- XX:MaxTenuringThreshold 设定参数)这些对象就会成为老年代。
-XX:MaxTenuringThreshold
任期门槛=>设置对象在新生代中存活的次数
面试题:如何判断哪个是to区呢?一句话:谁空谁是to
原理解释:
年轻代中的GC,主要是复制算法(Copying)
HotSpot JVM 把年轻代分为了三部分:一个 Eden 区 和 2 个Survivor区(from区 和 to区)。默认比例为 8:1:1,一般情况下,新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后,如果仍然存活,将会被移到Survivor区,对象在Survivor中每熬过一次Minor GC , 年龄就会增加1岁,当它的年龄增加到一定程度时,就会被移动到年老代中,因为年轻代中的对象基本上 都是朝生夕死,所以在年轻代的垃圾回收算法使用的是复制算法!复制算法的思想就是将内存分为两块,每次只用其中一块,当这一块内存用完,就将还活着的对象复制到另外一块上面。复制算法不会产 生内存碎片!
因为Eden区对象一般存活率较低,一般的,使用两块10%的内存作为空闲和活动区域,而另外80%的内存,则是用来给新建对象分配内存的。一旦发生GC,将10%的from活动区间与另外80%中存活的Eden 对象转移到10%的to空闲区域,接下来,将之前的90%的内存,全部释放,以此类推;
好处:没有内存碎片;坏处:浪费内存空间。
劣势:
如何选择Eden区复制到Survivor区的对象?---- 标记清除
标记存活对象: GC 会从根对象开始,通过可达性分析(Reachability Analysis)标记所有在程序执行过程中仍然是活动的对象。这些根对象可能是线程栈中的引用、静态变量、本地变量表中的引用等。所有与这些根对象直接或间接相连的对象都会被标记为存活对象。
复制到 Survivor 区: 在标记阶段结束后,GC 会遍历 Eden 区中的所有对象,将其中标记为存活的对象复制到 Survivor 区的其中一个。通常情况下,复制后的对象是按照它们在 Eden 区中的顺序复制到 Survivor 区的,但具体实现可能有所不同。
清空 Eden 区: 复制完所有存活对象后,Eden 区中所有未被复制的对象都会被认定为垃圾,并且整个 Eden 区将被清空,以便为后续的对象分配提供空间。
年龄增加: 存活在 Survivor 区的对象的年龄会增加。每次经过一次 Minor GC,存活对象会被复制到另一个 Survivor 区,并且它们的年龄会增加。当达到一定的年龄阈值后,对象会被晋升到老年代。
标记清除(Mark-Sweep)
回收时,对需要存活的对象进行标记;
回收不是绿色的对象。
当堆中的有效内存空间被耗尽的时候,就会停止整个程序(也被称为stop the world),然后进行两项工作,第一项则是标记,第二项则是清除。
标记:从引用根节点开始标记所有被引用的对象,标记的过程其实就是遍历所有的GC Roots ,然后将所有GC Roots 可达的对象,标记为存活的对象。
清除: 遍历整个堆,把未标记的对象清除。
缺点:
这个算法需要暂停整个应用,会产生内存碎片。
两次扫描(标记+清除),严重浪费时间。
用通俗的话解释一下 标记/清除算法,就是当程序运行期间,若可以使用的内存被耗尽的时候,GC线程就会被触发并将程序暂停,随后将依旧存活的对象标记一遍,最终再将堆中所有没被标记的对象全部清 除掉,接下来便让程序恢复运行。
劣势:
首先、它的缺点就是效率比较低(递归与全堆对象遍历),而且在进行GC的时候,需要停止应用 程序,这会导致用户体验非常差劲
其次、主要的缺点则是这种方式清理出来的空闲内存是不连续的,这点不难理解,我们的死亡对象 都是随机的出现在内存的各个角落,现在把他们清除之后,内存的布局自然乱七八糟,而为了应付 这一点,JVM就不得不维持一个内存空间的空闲列表,这又是一种开销。而且在分配数组对象的时 候,寻找连续的内存空间会不太好找。
Q: 可达性分析(Reachability Analysis)具体过程?
A: 可达性分析是垃圾回收算法中用于确定对象是否可访问(或者说“可达”)的一种技术。它的基本思想是从一组称为“根”的起始对象开始,递归地查找所有通过引用链与根对象相连接的对象,并将它们标记为可达的。而无法通过这些引用链到达的对象,则被视为不可达的,即可被回收的垃圾对象。
具体的可达性分析过程如下:
- 标记根对象: 可达性分析从一组称为根的对象开始。这些根对象通常包括:
- 程序的活动线程的栈中引用的对象;
- 静态变量引用的对象;
- 特定于应用程序的任何其它对象,被认为是程序的入口点。
递归遍历: 从根对象开始,递归地遍历所有与根对象直接或间接相关的对象。这一步骤通常使用深度优先搜索(DFS)或广度优先搜索(BFS)等算法来实现。
标记可达对象: 在遍历的过程中,将所有访问到的对象标记为可达。如果一个对象已经被标记为可达,那么它的所有引用对象也会被继续遍历和标记。
清除不可达对象: 一旦所有可达的对象都被标记完毕,剩余的未被标记的对象即为不可达对象,即垃圾对象。这些对象可以被安全地回收,以释放其所占用的内存空间。
Q: 存活对象定义?
A: 在可达性分析过程中,存活对象指的是通过根对象可达的对象,即那些可以被程序使用到的对象。垃圾对象则是不可达的对象,即那些程序不再使用的对象,可以被垃圾回收器回收的对象。
Q: 引用根节点是啥?
A: 引用根节点是指可达性分析开始时所使用的起始对象集合。这些根节点通常包括程序中活动线程的栈帧中的引用、静态变量引用的对象、以及其他特定于应用程序的入口点对象。通过从这些根节点出发,可达性分析可以遍历整个对象图,并确定哪些对象是可达的,哪些对象是不可达的。
什么是标记压缩?
原理:
在整理压缩阶段,不再对标记的对象作回收,而是通过所有存活对象都像一端移动,然后直接清除边界以外的内存。可以看到,标记的存活对象将会被整理,按照内存地址依次排列,而未被标记的内存会被 清理掉,如此一来,当我们需要给新对象分配内存时,JVM只需要持有一个内存的起始地址即可,这比维护一个空闲列表显然少了许多开销。
标记、整理算法 不仅可以弥补 标记、清除算法当中,内存区域分散的缺点,也消除了复制算法当中,内存减半的高额代价;
原理
标记压缩是一种垃圾回收算法,主要用于老年代(Old Generation)的内存区域,旨在解决长生命周期对象的内存管理问题。与标记清除算法不同,标记压缩算法在回收垃圾对象后会对存活对象进行整理,以减少内存碎片化。
该算法一般包括以下步骤:
标记存活对象: 与标记清除算法相似,标记压缩算法首先通过可达性分析标记所有存活的对象。
压缩存活对象: 在标记阶段结束后,存活对象通常会在堆内存中是不连续的,这可能导致内存碎片的产生。为了解决这个问题,标记压缩算法会将所有存活对象向堆内存的一端移动,使它们成为连续的块。这个过程被称为压缩(Compaction)。
更新引用: 在移动存活对象的过程中,需要更新所有指向这些对象的引用,以确保它们仍然指向正确的内存地址。
清除未标记的对象: 在压缩存活对象后,所有未被标记的对象被认为是垃圾,并且可以被安全地回收。
优点
- 减少内存碎片化:(相较于标记清除算法的改进)通过将存活对象整理成连续的块,可以降低内存碎片的产生,提高内存利用率。
- 改善内存分配性能:(相较于标记清除算法的改进)连续的内存块有利于快速、高效地分配内存空间。
- 减少所需使用的内存(相较于复制算法的改进)消除了复制算法当中,内存减半的高额代价。
缺点
- 需要额外的移动操作:将存活对象整理成连续的块需要额外的内存移动操作,可能会增加垃圾回收的时间成本。
- 不适用于所有场景:对于内存分配频繁、存活对象较多的情况,压缩操作可能会带来较大的性能开销。
尽管标记压缩算法在某些情况下效果显著,但它通常用于老年代的垃圾回收,而在新生代通常采用复制算法。
内存效率:复制算法 > 标记清除算法 > 标记压缩算法 (时间复杂度);
内存整齐度:复制算法 = 标记压缩算法 < 标记清除算法;
内存利用率:标记压缩算法 = 标记清除算法 > 复制算法;
复制 | 标记清除 | 标记整理 | |
---|---|---|---|
速率 | 最快 | 中等 | 最慢 |
空间开销 | 多,活动对象的两倍空间 | 少 | 少 |
内存碎片 | 无 | 有 | 无 |
移动对象 | 有 | 无 | 有 |
难道就没有一种最优算法吗?
答案: 无,没有最好的算法,只有最合适的算法 。 -----------> 分代收集算法
分代收集算法
为什么要使用分代收集?
- 不同对象的生命周期不同,需要采取不同的收集方式以提高回收效率。
- 长生命周期的对象:Http 请求中的 Session 对象、线程、Socket 连接
- 短生命周期的对象:String 对象
- 分代收集根据对象的生命周期将 Java 堆分为新生代和老年代,以便根据各自特点使用不同的回收算法,提高垃圾回收效率。
年轻代(Young Gen)
- 区域相对老年代较小,对象生命周期短、存活率低,回收频繁。
- 适合使用复制算法进行回收整理,速度最快。
- 复制算法内存利用率不高的问题通过 HotSpot 中的两个 survivor 空间设计得到缓解。
老年代(Tenured Gen)
- 区域较大,对象生命周期长、存活率高,回收不及年轻代频繁。
- 大量存活率高的对象存在,复制算法不合适。
- 一般采用标记-清除或标记-清除与标记-压缩混合实现。
分代收集的优势
- 分代收集考虑到不同对象的生命周期,提高了垃圾回收的效率。
- 几乎所有的垃圾回收器都采用分代的思想,区分新生代和老年代,以提高回收效率。
复制算法内存利用率不高的问题通过 HotSpot 中的两个 survivor 空间设计得到缓解,为什么能得到缓解?
复制算法(Copying Algorithm)核心思想是将内存分为两块,每次只使用其中一块,当这一块的内存用完后,将其中存活的对象复制到另一块内存中,同时清理掉当前内存中的垃圾对象,以此来达到内存整理的目的。
复制算法的一个问题是,它会导致内存利用率不高,因为每次只能使用其中一块内存,另一块内存则被浪费掉。
为了缓解这个问题,HotSpot 中采用了两个 survivor 空间的设计。在新生代中,将其中一块内存细分为两个相等大小的区域,分别称为 Eden 区和 From 区(另一块内存则是 To 区)。每次进行内存回收时,存活的对象会被复制到 To 区,并清理掉 Eden 区和 From 区中的垃圾对象,而下一次内存回收时,会交换 Eden 区和 From 区的角色,即存活的对象会被复制到原来的 From 区,而清理的操作则会在另外一块区域进行。
这样,就可以使得两个 survivor 空间都得到了充分利用,从而缓解了复制算法内存利用率不高的问题。
System.gc(); Runtime.getRuntime().gc();
- 在默认情况下,通过调用 System.gc() 或者 Runtime.getRuntime().gc(),会显式触发 Full GC(全垃圾回收),同时对老年代和新生代进行回收,尝试释放被丢弃对象占用的内存。
- 尽管调用 System.gc(),但它附带一个免责声明,即无法保证对垃圾收集器的调用会立即生效。
- JVM(Java 虚拟机)的实现者可以通过 System.gc() 调用来决定 JVM 的 GC 行为。一般情况下,垃圾回收应该是自动进行的,无须手动触发,否则会显得过于麻烦。
- 在一些特殊情况下,我们可以在运行之间调用 System.gc(),但这通常被视为是不推荐的做法。
内存溢出
定义: 内存溢出(Out of Memory,OOM)是指程序在申请内存时,没有足够的内存空间供其使用,导致申请失败或者操作系统无法为其分配所需内存,从而导致程序崩溃。
原因: 内存溢出通常发生在程序占用的内存增长速度超过了垃圾回收的速度,或者程序持续申请内存导致系统无法满足需求时。
示例: 当应用程序在运行过程中,分配的内存不断增加,直至达到系统所能提供的极限时,就会发生内存溢出。常见情况包括不合理的内存使用、内存泄漏等。
处理方式: 避免内存溢出的方法包括优化代码,减少内存使用量,释放不再使用的对象等。另外,通过监控和调整堆内存大小、调整垃圾回收策略等方式也可以缓解内存溢出问题。
内存泄漏:
定义: 内存泄漏指的是程序在运行过程中,不再需要使用的内存却没有被正确释放或回收,导致系统无法再次使用这些内存,最终耗尽可用内存,导致程序性能下降或崩溃。
原因: 内存泄漏通常是由于程序中的对象持续存在而未被正确释放,或者持有对其他对象的引用,导致这些对象无法被垃圾回收器回收。
示例: 常见的内存泄漏包括未关闭的资源(如数据库连接、文件流等)、长生命周期的对象持有短生命周期对象的引用、静态集合类未及时清理等。
处理方式: 避免内存泄漏的方法包括及时释放不再使用的资源、避免循环引用、使用弱引用或软引用等方式管理对象生命周期,以及通过工具和代码审查等手段检测和修复潜在的内存泄漏问题。
Stop-the-World (STW)
定义: Stop-the-World(STW)是指在进行垃圾回收(GC)时,应用程序的所有线程都会被暂停,没有任何响应,以确保垃圾回收器可以安全地执行其工作。这个暂停的过程就是STW。
必要性:
- 保证一致性: 在进行可达性分析等垃圾回收算法时,需要在一个能确保系统一致性的快照中进行分析。一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上,以防止分析过程中对象引用关系不断变化,导致分析结果不准确,出现漏标、错标等问题。
- 恢复应用程序线程: 被STW中断的应用程序线程会在完成GC之后恢复。频繁的STW会让用户感觉到应用程序卡顿,类似于网络速度不快导致视频卡顿的感觉,因此需要尽量减少STW的发生,以提升用户体验。
优化和减少STW的方法:
- 优化GC算法: 不断优化GC算法,提高回收效率,尽可能缩短STW的暂停时间,减少对应用程序的影响。
- 增强并行和并发处理: 使用并行GC和并发GC等技术,尽可能在不中断应用程序线程的情况下进行垃圾回收,减少STW的发生。
- 调整GC策略和参数: 根据应用程序的特点和需求,合理调整GC策略和参数,以达到最佳的性能和用户体验。
JVM自动处理: STW是由JVM在后台自动发起和完成的,对用户来说是不可见的,JVM会自动将应用程序的工作线程全部暂停,执行必要的垃圾回收操作,然后恢复应用程序线程的正常运行。
分类
按线程数:
按工作模式:
按内存区间:
性能指标
吞吐量(Throughput)
运行用户代码的时间占总运行时间的比例,反映系统的处理能力。
总运行时间:程序的运行时间+ 内存回收的时间
垃圾收集开销: 垃圾收集所用时间与总运行时间的比例,反映垃圾回收对系统性能的影响。
暂停时间(Pause Time)
HotSpot 垃圾收集器
图中展示了 7 种作用于不同分代的收集器,如果两个收集器之间存在连线,则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。
收集器名称 | 线程性质 | 垃圾收集算法 | 是否需要STW |
---|---|---|---|
Serial 收集器 | 单线程 | 复制算法 | 是 |
ParNew 收集器 | 多线程 | 复制算法 | 是 |
Parallel Scavenge 收集器 | 多线程 | 复制算法 | 是 |
Serial Old 收集器 | 单线程 | 标记-整理算法 | 是 |
Parallel Old 收集器 | 多线程 | 标记-整理算法 | 是 |
CMS(Concurrent Mark-Sweep)收集器 | 多线程 | 标记-清除算法 | 否 |
G1 收集器 | 多线程 | 标记-整理/清除算法 | 是 |
新生代收集器:
老年代收集器:
混合收集器:
CMS(Concurrent Mark Sweep,并发标记清除)收集器是一种以最短回收停顿时间为目标的垃圾收集器。它通过允许用户线程和垃圾收集线程并发执行来实现垃圾收集过程中的低停顿。下面我们来详细了解CMS收集器的工作过程和其优缺点:
CMS收集器的工作过程
初始标记(Initial Mark):在这个阶段,垃圾收集器会暂停所有用户线程(Stop The World),然后使用一条初始标记线程对所有与GC Roots直接关联的对象进行标记。
并发标记(Concurrent Mark):在这个阶段,垃圾收集线程会与用户线程并发执行。它进行可达性分析,标记出所有废弃对象,即可达对象。
重新标记(Remark):重新标记阶段也需要暂停用户线程,但是使用多条标记线程并发执行,标记出并发标记过程中新出现的废弃对象。
并发清除(Concurrent Sweep):在这个阶段,只使用一条GC线程,与用户线程并发执行,清除刚才标记的对象。这个阶段的耗时较长。
CMS收集器的优点:
CMS收集器的弊端:
内存碎片:由于CMS是基于标记-清除算法实现的,容易产生内存碎片,影响内存的连续分配和性能。
并发阶段的性能损耗:尽管CMS在并发阶段不会导致用户线程停顿,但会占用一部分线程资源,导致应用程序变慢,总吞吐量会降低。
无法处理浮动垃圾:CMS收集器无法处理浮动垃圾(floating garbage),这可能导致堆空间的不断增长。
三色标记算法
三色标记算法是一种用于改善Java虚拟机(JVM)垃圾回收性能的算法,最初从CMS(Concurrent Mark-Sweep)垃圾收集器引入并发标记的概念。它通过引入并发标记来解决在垃圾收集过程中引用关系链可能会改变的问题。
该算法将对象的状态分为三种颜色:黑色、灰色和白色。
三色标记的过程如下:
然而,并发标记的过程中,用户线程仍在运行,可能导致漏标和错标的情况。
漏标
漏标指的是在扫描过程中,用户线程修改了对象的引用关系,使得本应该被回收的对象被误标记为存活,最终导致垃圾回收不及时。
例子:
假设 GC 已经在遍历对象 B 了,而此时用户线程执行了 A.B=null 的操作,切断了 A 到 B 的引用;本来执行了 A.B=null 之后,B、D、E 都可以被回收了,但是由于 B 已经变为灰色,它仍会被当做存活对象,继续遍历下去。最终的结果就是本轮 GC 不会回收 B、D、E,留到下次 GC 时回收,也算是浮动垃圾的一部分。
错标
错标指的是在扫描过程中,用户线程修改了对象的引用关系,使得本应该被保留的对象被错误标记为垃圾,最终导致程序运行错误。
例子:
假设 GC 线程已经遍历到 B 了,此时用户线程执行了以下操作:
B.D=null;//B 到 D 的引用被切断
A.xx=D;//A 到 D 的引用被建立
B 到 D 的引用被切断,且 A 到 D 的引用被建立。
此时 GC 线程继续工作,由于 B 不再引用 D 了,尽管 A 又引用了 D,但是因为 A 已经标记为黑色,GC 不会再遍历 A 了,所以 D 会被标记为白色,最后被当做垃圾回收。
解决错标的问题——原始快照和增量更新
错标的结果比漏表严重的多,浮动垃圾可以下次 GC 清理,而把不该回收的对象回收掉,将会造成程序运行错误。
错标只有在满足下面两种情况下才会发生:
灰色对象指向白色对象的引用全部被断开
黑色对象建立指向白色对象的引用
解决错标的问题的方法有两种:原始快照和增量更新:
原始快照:当灰色对象指向白色对象的引用被断开时,记录这些引用关系。当扫描结束后,以这些灰色对象为根,重新扫描一次。
增量更新:当黑色对象建立指向白色对象的引用时,记录这些新的引用关系。当扫描结束后,以这些记录中的黑色对象为根,重新扫描一次。相当于一旦黑色对象建立了指向白色对象的引用,就将其标记为灰色对象。
总结
CMS 为了让 GC 线程和用户线程一起工作,回收的算法和过程比以前旧的收集器要复杂很多。究其原因,就是因为 GC 标记对象的同时,用户线程还在修改对象的引用关系。因此 CMS 引入了三色算法,将对象标记为黑、灰、白三种颜色的对象,将用户线程修改的引用关系记录下来,以便在重新标记阶段可以修正对象的引用。
虽然 CMS 从来没有被 JDK 当做默认的垃圾收集器,存在很多的缺点,但是它开启了「GC 并发收集」的先河,为后面的收集器提供了思路。
既然我们已经有了前面几个强大的 GC,为什么还要发布 Garbage First(G1)GC?
原因就在于应用程序所应对的业务越来越庞大、复杂,用户越来越多,没有GC 就不能保证应用程序正常进行,而经常造成 STW 的 GC 又跟不上实际的需求,所以才会不断地尝试对 GC 进行优化。G1(Garbage-First)垃圾回收器是在 Java7 update 4 之后引入的一个新的垃圾回收器,是当今收集器技术发展的最前沿成果之一.
与此同时,为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降低暂停时间(pause time),同时兼顾良好的吞吐量。
官方给 G1 设定的目标是在延迟可控的情况下获得尽可能高的吞吐量,所以才担当起“全功能收集器”的重任与期望。
G1 是一款面向服务端应用的垃圾收集器。
为什么名字叫做 Garbage First(G1)呢?
因为 G1 是一个并行回收器,它把堆内存分割为很多不相关的区域(Region)(物理上不连续的逻辑上连续的)。使用不同的 Region 来表示 Eden、幸存者0 区,幸存者 1 区,老年代等。
G1 GC 有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region.
由于这种方式的侧重点在于回收垃圾价值最大的区间(Region),所以我们给 G1 一个名字:垃圾优先(Garbage First)。
垃圾回收过程
如下图所示,G1 收集器收集器收集过程有初始标记、并发标记、最终标记、筛选回收,和 CMS 收集器前几步的收集过程很相似:
初始标记:标记出 GC Roots 直接关联的对象,这个阶段速度较快,需要停止用户线程,单线程执行。
并发标记:从 GC Root 开始对堆中的对象进行可达新分析,找出存活对象,这个阶段耗时较长,但可以和用户线程并发执行。
最终标记:修正在并发标记阶段引用户程序执行而产生变动的标记记录。
筛选回收:筛选回收阶段会对各个 Region 的回收价值和成本进行排序,根据用户所期望的 GC 停顿时间来指定回收计划(用最少的时间来回收包含垃圾最多的区域.这就是 Garbage First 的由来——第一时间清理垃圾最多的区块),这里为了提高回收效率,并没有采用和用户线程并发执行的方式,而是停顿用户线程。
优点
可预测的停顿时间:G1致力于提供可预测的停顿时间,这对于需要高可用性和低延迟的应用程序非常重要。
高效的内存利用:通过区域化的内存管理和混合收集,G1能够更加高效地利用内存,从而降低了内存碎片化的风险。
并发标记:G1的并发标记机制可以减少应用程序的停顿时间,提高了系统的吞吐量和响应速度。
自适应调整:G1能够根据实际情况动态调整自身的行为,以适应不同的系统资源和应用程序负载。
适用场景
要求尽可能可控 GC 停顿时间;内存占用较大的应用。
相关设置
默认垃圾回收器信息:
命令:
-XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=263937920 -XX:MaxHeapSize=4223006720 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC java version "1.8.0_351" Java(TM) SE Runtime Environment (build 1.8.0_351-b10) Java HotSpot(TM) 64-Bit Server VM (build 25.351-b10, mixed mode)
JDK 8 默认的垃圾回收器:
- 年轻代使用 Parallel Scavenge GC
- 老年代使用 Parallel Old GC
垃圾回收详细信息打印:
- 命令:
-XX:+PrintGCDetails -version
设置默认垃圾回收器:
Serial 回收器:
-XX:+UseSerialGC
- 年轻代使用 Serial GC
- 老年代使用 Serial Old GC
ParNew 回收器:
-XX:+UseParNewGC
- 年轻代使用 ParNew GC
- 不影响老年代
CMS 回收器:
-XX:+UseConcMarkSweepGC
- 老年代使用 CMS GC
G1 回收器:
-XX:+UseG1GC
- 手动指定使用 G1 收集器执行内存回收任务
G1 回收器配置:
-XX:G1HeapRegionSize
- 设置每个 Region 的大小
Java 虚拟机(JVM)执行引擎是 Java 虚拟机的核心组件之一,负责将 Java 字节码转换为机器码并执行程序。执行引擎通常包含解释器和即时编译器两种执行方式。
解释器逐条解释执行 Java 字节码,将字节码翻译成对应平台的机器指令,然后由处理器执行。解释器的优点是简单、易于实现,适用于快速启动和简单测试。然而,解释执行通常速度较慢,因为它需要动态地将每条字节码翻译为机器码。
即时编译器将字节码编译成本地机器码,以提高执行速度。JIT 编译器可以选择性地将频繁执行的热点代码编译成机器码,而不是每次都解释执行。这种方式可以显著提高程序的性能,尤其是对于密集计算型和性能敏感的应用程序。
在实际中,JVM 的执行引擎通常会结合解释器和即时编译器两种执行方式,称为混合模式执行。在程序启动时,解释器可以快速地启动并执行字节码,同时即时编译器会监视程序的执行情况,并且根据一定的触发条件对热点代码进行即时编译,从而提高程序的整体性能。
另外,现代的 JVM 还可以使用 Ahead-Of-Time(AOT)编译器,预先将整个应用程序编译成本地机器码,以减少启动时间和减少运行时的开销。这种方式适用于一些对启动时间和运行时性能要求较高的场景,例如移动设备、嵌入式系统等。
综上所述,JVM 执行引擎通过解释器和即时编译器的组合,以及可能的 AOT 编译器,实现了 Java 程序的高效执行,并且在性能和启动时间之间做出了权衡。
前端编译
VS 执行引擎的解释、编译执行
什么是解释器?什么是 JIT 编译器?有什么不同的地方?
解释器(Interpreter): 字节码(逐条) --> 机器码
即时编译器(Just-In-Time Compiler,JIT): 字节码(一次性) --> 机器码
区别
执行方式: 解释器逐行解释源代码并立即执行,而 JIT 编译器在运行时将源代码或中间表示编译成机器代码,然后执行编译后的机器代码。
性能: 通常情况下,JIT 编译器的性能优于解释器,因为它将代码编译成机器代码,避免了解释器逐行解释的性能开销。JIT 编译器的优化也能够更好地利用硬件特性和程序的执行路径,从而进一步提高性能。
启动时间: 解释器通常比 JIT 编译器具有更快的启动时间,因为解释器不需要额外的编译步骤。然而,一旦 JIT 编译器完成了编译,后续执行会更快。
内存使用: 解释器通常需要更少的内存,因为它只需要存储源代码或中间表示,并逐行解释执行。相比之下,JIT 编译器需要存储编译后的机器代码,可能会占用更多的内存空间。
为什么 Java 是半编译半解释型语言?
解释器与 JIT 编译器的作用和原理
解释器和 JIT 编译器的协同作用
内存结构(不是JMM):
在Java内存模型中,描述了在多线程代码中,哪些行为是正确的、合法的,以及多线程之间如何进行通信,代码中变量的读写行为如何反应到内存、CPU缓存的底层细节。
在Java中包含了几个关键字:volatile、final和synchronized,帮助程序员把代码中的并发需求描述给编译器。Java内存模型中定义了它们的行为,确保正确同步的Java代码在所有的处理器架构上都能正确执行。
缓存一致性
但是随着cpu的发展,内存的读写速度也远远赶不上cpu。因此cpu厂商在每颗cpu上加上高速缓存,用于缓解这种情况。现在cpu和内存的交互大致如下。
cpu上加入了高速缓存这样做解决了处理器和内存的矛盾(一快一慢),但是引来的新的问题 - 缓存一致性
在多核cpu中,每个处理器都有各自的高速缓存(L1,L2,L3),而主内存确只有一个
如何保证数据一致性——缓存一致性协议
JMM(Java 内存模型)主要定义了对于一个共享变量,当另一个线程对这个共享变量执行写操作后,这个线程对这个共享变量的可见性。
CPU缓存模型
指令重排序:
编译器优化重排(JVM、JIT 编译器等) —> 指令并行重排 —> 内存系统重排
指令重排序可以保证串行语义一致,但是没有义务保证多线程间的语义也一致
编译器和处理器(指令并行重排和内存系统重排)的处理
对于编译器,通过禁止特定类型的编译器重排序的方式来禁止重排序
对于处理器,通过插入内存屏障(Memory Barrier,或有时叫做内存栅栏,Memory Fence)的方式来禁止特定类型的处理器重排序
内存屏障(Memory Barrier)
确保对共享内存的操作顺序和可见性
读屏障(Read Barrier)
写屏障(Write Barrier)
Java 内存区域和内存模型是完全不一样的两个东西:
作用:缓存一致性协议,用于定义数据读写的规则(遵守,找到这个规则)。
JMM定义了线程工作内存和主内存之间的抽象关系∶线程之间的共享变量存储在主内存(Main Memory)中,每个线程都有一个私有的本地内存(Local Memory)。
Java 内存模型定义来以下八种同步操作
锁定(lock): 作用于主内存中的变量,将他标记为一个线程独享变量。
解锁(unlock): 作用于主内存中的变量,解除变量的锁定状态,被解除锁定状态的变量才能被其他线程锁定。
read(读取):作用于主内存的变量,它把一个变量的值从主内存传输到线程的工作内存中,以便随后的 load 动作使用。
load(载入):把 read 操作从主内存中得到的变量值放入工作内存的变量的副本中。
use(使用):把工作内存中的一个变量的值传给执行引擎,每当虚拟机遇到一个使用到变量的指令时都会使用该指令。
assign(赋值):作用于工作内存的变量,它把一个从执行引擎接收到的值赋给工作内存的变量,每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store(存储):作用于工作内存的变量,它把工作内存中一个变量的值传送到主内存中,以便随后的 write 操作使用。
write(写入):作用于主内存的变量,它把 store 操作从工作内存中得到的变量的值放入主内存的变量中。
JMM对这八种指令的使用,制定了如下规则:(java内存模型JMM理解整理 - 阿姆斯特朗回旋炮 - 博客园)
JMM对这八种操作规则和对volatile的一些特殊规则就能确定哪里操作是线程安全,哪些操作是线程不安全的了。但是这些规则实在复杂,很难在实践中直接分析。所以一般我们也不会通过上述规则进行分析。更多的时候,使用java的happen-before规则来进行分析。
happens-before 原则
区分事件发生的前后顺序, 更想表达的意义是前一个操作的结果对于后一个操作是可见的,无论这两个操作是否在同一个线程里
设计思想
为了对编译器和处理器的约束尽可能少,只要不改变程序的执行结果(单线程程序和正确执行的多线程程序),编译器和处理器怎么进行重排序优化都行。
对于会改变程序执行结果的重排序,JMM 要求编译器和处理器必须禁止这种重排序。
happens-before 常见规则(8条)
如果两个操作不满足上述任意一个 happens-before 规则,那么这两个操作就没有顺序的保障,JVM 可以对这两个操作进行重排序。
程序顺序规则:一个线程内,按照代码顺序,书写在前面的操作 happens-before 于书写在后面的操作;
解锁规则:解锁 happens-before 于加锁;
volatile 变量规则:对一个 volatile 变量的写操作 happens-before 于后面对这个 volatile 变量的读操作。说白了就是对 volatile 变量的写操作的结果对于发生于其后的任何操作都是可见的。
传递规则:如果 A happens-before B,且 B happens-before C,那么 A happens-before C;
线程启动规则:Thread 对象的 start()
方法 happens-before 于此线程的每一个动作。
并发编程三个重要特性
-XX:MetaspaceSize
设置为较高的值。Java方法区、永久代、元空间、常量池详解_java永久地址-CSDN博客
狂神说笔记——JVM入门07 - subeiLY - 博客园
java内存模型JMM理解整理 - 阿姆斯特朗回旋炮 - 博客园
JVM(Java虚拟机)-史上最全、最详细JVM笔记-CSDN博客
JVM 方法区和元空间什么关系?为什么要将永久代替换为元空间?-CSDN博客
JVM 垃圾清理 标记-清除算法 常量池移除问题 · Issue #747 · Snailclimb/JavaGuide · GitHub