文章目录
JVM笔记
1 Java技术体系
Java技术体系其实已经不仅仅是Java语言的专属,其实也包括可以运行在Java平台的其他语言,比如:
Kotlin、Clojure、JRuby、Groovy等语言。对于我们Java程序员而言,我们所指的是JCP官方定义的Java
体系。
JCP:Java Community Process,就是人们常说的“Java社区”,这是一个由业界多家技术巨头组成
的社区组织,用于定义和发展Java的技术规范。官网:https://jcp.org/en/home/index
1.1 JDK & JRE
Java程序设计语言、Java虚拟机、Java类库这三部分统称为JDK(Java Development Kit),JDK是用于
支持Java程序开发的最小环境。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
1.2 Java发展历史
- 1995年5月23日,Oak语言改名为Java,并且在SunWorld大会上正式发布Java 1.0版本。Java语言第一次提出了“Write Once,Run Anywhere”的口号。
- 1999年4月27日,HotSpot虚拟机诞生。Hot-Spot虚拟机刚发布时是作为JDK 1.2的附加程序提供
的,后来它成为JDK 1.3及之后所有JDK版本的默认Java虚拟机。 - 2004年9月30日,JDK 5发布,工程代号为Tiger(老虎),是Java语言的发展史上的又一里程碑事
件。JDK的版本不再是“1.x”的命名方式,而采用“JDK x”方式进行命名。 - JDK 8的第一个正式版本于2014年3月18日发布,从JDK 8开始,Oracle启用JEP(JDK
Enhancement Proposals)来定义和管理纳入新版JDK发布范围的功能特性。- JEP 126:对Lambda表达式的支持,这让Java语言拥有了流畅的函数式表达能力。
- JEP 104:内置Nashorn JavaScript引擎的支持,成为Java的嵌入式JavaScript引擎。
- JEP 150:新的时间、日期API。
- JEP 122:彻底移除HotSpot的永久代。
- ……
- JDK9于2017年9月21日发布。JDK 9发布后,Oracle随即宣布Java将会以持续交付的形式和更加敏捷的研发节奏向前推进,以后JDK将会在每年的3月和9月各发布一个大版本。每六个JDK大版本中才会被划出一个长期支持(Long Term Support,LTS)版,只有LTS版的JDK能够获得为期三年的支持和更新,普通版的JDK就只有短短六个月的生命周期。JDK 8和JDK 11是LTS版,再下一个就到2021年发布的JDK 17了。
- 2018年9月25日,JDK 11发布,这是一个LTS版本的JDK,包含17个JEP,其中有ZGC这样的革命性的垃圾收集器出现,也有把JDK 10中的类型推断加入Lambda语法这种可见的改进。2019年2月,在JDK 12发布前夕,Oracle果然如之前宣布那样在六个月之后就放弃了对上一个版本OpenJDK的维护,RedHat同时从Oracle手上接过OpenJDK 8和OpenJDK 11的管理权利和维护职责。
- 2019年3月20日,JDK 12发布,只包含8个JEP,其中主要有Switch表达式、Java微测试套件(JMH)等新功能,最引人注目的特性无疑是加入了由RedHat领导开发的Shenandoah垃圾收集器。Shenandoah作为首个由非Oracle开发的垃圾收集器,其目标又与Oracle在JDK 11中发布的ZGC几乎完全一致,两者天生就存在竞争。Oracle马上用实际行动抵制了这个新收集器,在JDK 11发布时才说应尽可能保证OracleJDK和OpenJDK的兼容一致,转眼就在OracleJDK 12里把Shenandoah的代码通过条件编译强行剔除掉,使其成为历史上唯一进入了OpenJDK发布清单,但在OracleJDK中无法使用的功能。
- 2020年 3 月 17 日,JDK14 正式 GA(General Available),新增了Records、switch表达式(JDK12和JDK 13中的预览特性,现在正式使用)、文本块等新特性。在JVM方面,弃用ParallelScavenge和SerialOld GC组合、删除CMS垃圾回收器。
1.3 各种JVM虚拟机
Java虚拟机是java运行的基石,不同的虚拟机对于java运行有着非常重要的影响,我们熟知的虚拟机有HotSpot、JRockit还有IBM J9虚拟机,在java发展史中除了这三个知名的虚拟机外,还有一些其他的虚拟机,下面我们一起来了解下。
1.3.1、Classic VM与Exact VM
1996年1月23日,Sun发布JDK 1.0,世界上第一款商用Java虚拟机Classic VM发布。这款虚拟机只能使用纯解释器方式来执行Java代码,如果要使用即时编译器那就必须进行外挂,但是假如外挂了即时编译器的话,即时编译器就会完全接管虚拟机的执行系统,解释器便不能再工作了。在JDK 1.2时,曾在Solaris平台上发布过一款名为Exact VM的虚拟机,它的编译执行系统已经具备现代高性能虚拟机雏形,如热点探测、两级即时编译器、编译器与解释器混合工作模式等。虽然Exact VM的技术相对Classic VM来说先进了许多,但是它的命运显得十分英雄气短,在商业应用上只存在了很短暂的时间就被外部引进的HotSpot VM所取代,甚至还没有来得及发布Windows和Linux
平台下的商用版本。
1.3.2、HotSpot VM
HotSpot VM 是Sun/OracleJDK和OpenJDK中的默认Java虚拟机,也是目前使用范围最广的Java虚拟机。在最初并非由Sun公司所开发,而是由一家名为“Longview Technologies”的小公司设计的。HotSpot既继承了Sun之前两款商用虚拟机的优点,也有许多自己新的技术优势,如它名称中的HotSpot指的就是它的热点代码探测技术。同虚拟机。Oracle收购Sun以后,建立了HotRockit项目来把原来BEA JRockit中的优秀特性融合到HotSpot之中。到了2014年的JDK 8时期,里面的HotSpot就已是两者融合的结果,HotSpot在这个过程里移除掉永久代,吸收了JRockit的Java Mission Control监控工具等功能。
1.3.3、BEA JRockit JVM
JRockit虚拟机曾经号称是“世界上速度最快的Java虚拟机”,它是BEA在2002年从Appeal VirtualMachines公司收购获得的Java虚拟机。
BEA将其发展为一款专门为服务器硬件和服务端应用场景高度优化的虚拟机,由于专注于服务端应用,它可以不太关注于程序启动速度,因此JRockit内部不包含解释器实现,全部代码都靠即时编译器编译后执行。
除此之外,JRockit的垃圾收集器和Java Mission Control故障处理套件等部分的实现,在当时众多的Java虚拟机中也处于领先水平。
JRockit随着BEA被Oracle收购,现已不再继续发展,永远停留在R28版本,这是JDK 6版JRockit的代号。
1.3.4、IBM J9 VM
IBM J9虚拟机并不是IBM公司唯一的Java虚拟机,不过目前IBM主力发展无疑就是J9。与BEA JRockit只专注于服务端应用不同,IBM J9虚拟机的市场定位与HotSpot比较接近,它是一款在设计上全面考虑服务端、桌面应用,再到嵌入式的多用途虚拟机。开发J9的目的是作为IBM公司各种Java产品的执行平台,在和IBM产品(如IBM WebSphere等)搭配以及在IBM AIX和z/OS这些平台上部署Java应用。从2016年起,IBM逐步将OMR项目和J9虚拟机进行开源,完全开源后便将它们捐献给了Eclipse基金会管理,并重新命名为Eclipse OMR和OpenJ9。
1.3.5、Apache Harmony VM
Apache Harmony是一个Apache软件基金会旗下以Apache License协议开源的实际兼容于JDK 5和JDK6的Java程序运行平台,它含有自己的虚拟机和Java类库API,用户可以在上面运行Eclipse、Tomcat、Maven等常用的Java程序。但是,它并没有通过TCK(Technology Compatibility Kit)认证。
当Sun公司把自家的JDK开源形成OpenJDK项目之后,Apache Harmony开源的优势被极大地抵消,以至于连Harmony项目的最大参与者IBM公司也宣布辞去Harmony项目管理主席的职位,转而参与OpenJDK的开发。
虽然Harmony没有真正地被大规模商业运用过,但是它的许多代码(主要是Java类库部分的代码)被吸纳进IBM的JDK 7实现以及Google Android SDK之中,尤其是对Android的发展起了很大推动作用。
1.3.6、Microsoft JVM
在Java语言诞生的初期,它的主要应用之一是在浏览器中运行Java Applets程序,微软为了在InternetExplorer 3浏览器中支持Java Applets应用而开发了自己的Java虚拟机,虽然这款虚拟机只有Windows平台的版本,“一次编译,到处运行”根本无从谈起,但却是当时Windows系统下性能最好的Java虚拟机。
在1997年10月,Sun公司正式以侵犯商标、不正当竞争等罪名控告微软,在随后对微软公司的垄断调查之中,这款虚拟机也曾作为证据之一被呈送法庭。官司的结果是微软向Sun公司(最终微软因垄断赔偿给Sun公司的总金额高达10亿美元)赔偿2000万美金,承诺终止其Java虚拟机的发展,并逐步在产品中移除Java虚拟机相关功能
2018年4月,Oracle Labs新公开了一项黑科技:Graal VM,从它的口号“Run Programs FasterAnywhere”就能感觉到一颗蓬勃的野心。
Graal VM 是一个在HotSpot虚拟机基础上增强而成的跨语言全栈虚拟机,可以作为“任何语言”的运行平台使用,这里“任何语言”包括了Java、Scala、Groovy、Kotlin等基于Java虚拟机之上的语言,还包括了C、C++、Rust等基于LLVM的语言,同时支持其他像JavaScript、Ruby、Python和R语言等。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
1.4 JDK8
1.4.1 The relation of JDK/JRE/JVM
Reference -> Developer Guides -> 定位到:https://docs.oracle.com/javase/8/docs/index.html
Oracle has two products that implement Java Platform Standard Edition (Java SE)8: Java SE Development Kit (JDK) 8 and Java SE Runtime Environment (JRE) 8.JDK 8 is a superset of JRE 8, and contains everything that is in JRE 8, plus tools such as the compilers and debuggers necessary for developing applets and applications. JRE 8 provides the libraries, the Java Virtual Machine (JVM), and other components to run applets and applications written in the Java programming language. Note that the JRE includes components not required by the Java SE specification, including both standard and non-standard Java components.
1.4.2 源码到类文件
源码:
class Person{
private String name;
private int age;
private static String address;
private final static String hobby="Programming";
public void say(){
System.out.println("person say...");
}
public int calc(int op1,int op2){
return op1+op2;
}
}
编译: javac Person.java —> Person.class
1.4.3 编译过程
Person.java -> 词法分析器 -> tokens流 -> 语法分析器 -> 语法树/抽象语法树 -> 语义分析器-> 注解抽象语法树 -> 字节码生成器 -> Person.class文件
1.4.4 类文件(Class文件)
官网The class File Format : https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html
cafe babe 0000 0034 0027 0a00 0600 1809
0019 001a 0800 1b0a 001c 001d 0700 1e07
001f 0100 046e 616d 6501 0012 4c6a 6176
612f 6c61 6e67 2f53 7472 696e 673b 0100
0361 6765 0100 0149 0100 0761 6464 7265
......
1.4.5 magic(魔数):
The magic item supplies the magic number identifying the class file format; it has the value 0xCAFEBABE
cafe babe
minor_version, major_version
0000 0034 对应10进制的52,代表JDK 8中的一个版本
constant_pool_count
0027 对应十进制39,代表常量池中39个常量
ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_info methods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
.class字节码文件
魔数与class文件版本
常量池
访问标志
类索引、父类索引、接口索引
字段表集合
方法表集合
属性表集合
1.5 类文件到虚拟机(类加载机制)
1.5.1 装载(Load)
查找和导入class文件
a-先找到类的文件所在的位置--:磁盘 全路径 --->类装载器(ClassLoader.find(String name)) -->寻找类
b-类的信息交给JVM -->类文件字节码流静态存储结构-->JVM里面的某一块区域【方法区】
c-类文件所对应的对象Class -->JVM --> 堆
(1)通过一个类的全限定名获取定义此类的二进制字节流
(2)将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
(3)在Java堆中生成一个代表这个类的java.lang.Class对象,作为对方法区中这些数据的访问入口
1.5.2 链接(Link)
1.5.2.1 验证(Verify) 【正确性】
保证被加载类的正确性
- 文件格式验证
- 元数据验证
- 字节码验证
- 符号引用验证
1.5.2.2 准备(Prepare)
为类的静态变量分配内存,并将其初始化为默认值 static int a = 10; 初始化默认值a=0
1.5.2.3 解析(Resolve)
把类中的符号引用转换为直接引用
符号引用:
借助class File Format 进行描述
直接引用:
地址: String str = 地址是什么
1.5.2.4 初始化(Initialize)
对类的静态变量,静态代码块执行初始化操作
为静态变量 赋值真正的值 static int a = 10; 初始化 a = 10
1.5.2.4 类加载机制图解
使用和卸载不算是类加载过程中的阶段,只是画完整了一下
1.5.3 类装载器ClassLoader
在装载(Load)阶段,其中第(1)步:通过类的全限定名获取其定义的二进制字节流,需要借助类装载器完成,顾名思义,就是用来装载Class文件的。
(1)通过一个类的全限定名获取定义此类的二进制字节流
1.5.3.1 分类
1)Bootstrap ClassLoader 负责加载$JAVA_HOME中 jre/lib/rt.jar 里所有的class或Xbootclassoath选项指定的jar包。由C++实现,不是ClassLoader子类。
2)Extension ClassLoader 负责加载java平台中扩展功能的一些jar包,包括$JAVA_HOME中jre/lib/*.jar 或 -Djava.ext.dirs指定目录下的jar包。
3)App ClassLoader 负责加载classpath中指定的jar包及 Djava.class.path 所指定目录下的类和jar包。
4)Custom ClassLoader 通过java.lang.ClassLoader的子类自定义加载class,属于应用程序根据自身需要自定义的ClassLoader,如tomcat、jboss都会根据j2ee规范自行实现ClassLoader。
1.5.3.2 图解
1.5.3.3 加载原则
检查某个类是否已经加载:顺序是自底向上,从Custom ClassLoader到BootStrap ClassLoader逐层检 查,只要某个Classloader已加载,就视为已加载此类,保证此类只所有ClassLoader加载一次。
加载的顺序:加载的顺序是自顶向下,也就是由上层来逐层尝试加载此类。
双亲委派机制:
定义:如果一个类加载器在接到加载类的请求时,它首先不会自己尝试去加载这个类,而是把 这个请求任务委托给父类加载器去完成,依次递归,如果父类加载器可以完成类加载任务,就 成功返回;只有父类加载器无法完成此加载任务时,才自己去加载。
优势:Java类随着加载它的类加载器一起具备了一种带有优先级的层次关系。比如,Java中的 Object类,它存放在rt.jar之中,无论哪一个类加载器要加载这个类,最终都是委派给处于模型 最顶端的启动类加载器进行加载,因此Object在各种类加载环境中都是同一个类。如果不采用 双亲委派模型,那么由各个类加载器自己取加载的话,那么系统中会存在多种不同的Object 类。
破坏:可以继承ClassLoader类,然后重写其中的loadClass方法,其他方式大家可以自己了解 拓展一下。
2 运行时数据区
运行时数据区(Run-Time Data Areas)
在装载阶段的第(2),(3)步可以发现有运行时数据,堆,方法区等名词
(2)将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
(3)在Java堆中生成一个代表这个类的java.lang.Class对象,作为对方法区中这些数据的访问入口
说白了就是类文件被类装载器装载进来之后,类中的内容(比如变量,常量,方法,对象等这些数 据得要有个去处,也就是要存储起来,存储的位置肯定是在JVM中有对应的空间)
2.1 官网概括
https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
Summary
The Java Virtual Machine defines various run-time data areas that are used during execution of a program. Some of these data areas are created on Java Virtual Machine start-up and are destroyed only when the Java Virtual Machine
exits. Other data areas are per thread. Per-thread data areas are created when a thread is created and destroyed when the thread exits.
图解
2.2 常规理解
2.2.1Method Area(方法区)
方法区是各个线程共享的内存区域,在虚拟机启动时创建。 用于存储已被虚拟机加载的类信息、常、静态变量、即时编译器编译后的代码等数据。
虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分,但是它却又一个别名叫做Non-Heap(非堆),目的是与Java堆区分开来。
当方法区无法满足内存分配需求时,将抛出OutOfMemoryError异常。
此时回看装载阶段的第2步:(2)将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
如果这时候把从Class文件到装载的第(1)和(2)步合并起来理解的话,可以画个图
值得说明的
(1)方法区在JDK 8中就是Metaspace,在JDK6或7中就是Perm Space
(2)Run-Time Constant Pool Class文件中除了有类的版本、字段、方法、接口等描述 信息外,还有一项信息就是常量池,用于存放编译时期生成的各种字面量和符号引用,这部分内容将在 类加载后进入方法区的运行时常量池中存放。
Each run-time constant pool is allocated from the Java Virtual Machine's method area (§2.5.4).s
2.2.2 Heap(堆)
Java堆是Java虚拟机所管理内存中最大的一块,在虚拟机启动时创建,被所有线程共享。 Java对象实例以及数组都在堆上分配。
The Java Virtual Machine has a heap that is shared among all Java Virtual Machine threads. The heap is the run-time data area from which memory for all class instances and arrays is allocated.
The heap is created on virtual machine start-up.
此时回看装载阶段的第3步:(3)在Java堆中生成一个代表这个类的java.lang.Class对象,作为对方 法区中这些数据的访问入口
此时装载(1)(2)(3)的图可以改动一下
2.2.3 Java Virtual Machine Stacks(虚拟机栈)
Java虚拟机栈:是线程私有的,它的生命周期与线程相同,虚拟机栈描述的是Java方法执行的内存模型,每个方法在执行的同时,都会创建一个栈帧(stack frame) 用于存储局部变量表、操作数栈、动态链接、方法出口等信息,每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
Each Java Virtual Machine thread has a private Java Virtual Machine stack, created at the same time as the thread. A Java Virtual Machine stack stores frames (§2.6).
局部变量表:存放了编译过程中可知的 各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference类型、returnAddress类型)。
操作数栈:以压栈和出栈的方式存储操作数的
动态链接:每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用,持有这个引用是为了支持方法调用过程中的动态连接(Dynamic Linking)。
方法出口:当一个方法开始执行后,只有两种方式可以退出,一种是遇到方法返回的字节码指令;一种是遇见异常,并且这个异常没有在方法体内得到处理。
画图理解栈和栈帧
实例分析:
class Person{
private String name="Jack";
private int age;
private final double salary=100;
private static String address;
private final static String hobby="Programming";
public void say(){
System.out.println("person say...");
}
public static int calc(int op1,int op2){
op1=3;
int result=op1+op2;
return result;
}
public static void order(){
}
public static void main(String[] args){
calc(1,2);
order();
}
}
此时你需要一个能够看懂反编译指令的宝典
比如官网的:https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
当然网上也有很多,大家可以自己查找
javap -c Person.class > Person.txt (对照源码读)
Compiled from "Person.java"
class Person {
...
public static int calc(int, int);
Code:
0: iconst_3 //将int类型常量3压入[操作数栈]
1: istore_0 //将int类型值存入[局部变量0]
2: iload_0 //从[局部变量0]中装载int类型值入栈
3: iload_1 //从[局部变量1]中装载int类型值入栈
4: iadd //将栈顶元素弹出栈,执行int类型的加法,结果入栈
【For example, the iadd instruction (§iadd) adds two int values together. It
requires that the int values to be added be the top two values of the operand stack, pushed there by previous instructions. Both of the int values are popped from the operand stack. They are added, and their sum is pushed back onto the operand stack. Subcomputations may be nested on the operand stack, resulting in values that can be used by the encompassing computation.】
5: istore_2 //将栈顶int类型值保存到[局部变量2]中
6: iload_2 //从[局部变量2]中装载int类型值入栈
7: ireturn //从方法中返回int类型的数据
...
}
如果在栈帧中有一个变量,类型为引用类型,比如Object obj=new Object(),这时候就是典型的栈中元素指向堆中的对象。
方法区指向堆
private static Object obj=new Object();
堆指向方法区
方法区中会包含类的信息,堆中会有对象,那怎么知道对象是哪个类创建的呢?
2.2.4 The pc Register(程序计数器)
我们都知道一个JVM进程中有多个线程在执行,而线程中的内容是否能够拥有执行权,是根据
CPU调度来的。
假如线程A正在执行到某个地方,突然失去了CPU的执行权,切换到线程B了,然后当线程A再获 得CPU执行权的时候,怎么能继续执行呢?这就是需要在线程中维护一个变量,记录线程执行到 的位置。
程序计数器占用的内存空间很小,由于Java虚拟机的多线程是通过线程轮流切换,并分配处理器执行时 间的方式来实现的,在任意时刻,一个处理器只会执行一条线程中的指令。因此,为了线程切换后能够 恢复到正确的执行位置,每条线程需要有一个独立的程序计数器(线程私有)。
如果线程正在执行Java方法,则计数器记录的是正在执行的虚拟机字节码指令的地址; 如果正在执行的是Native方法,则这个计数器为空。
The Java Virtual Machine can support many threads of execution at once (JLS
§17). Each Java Virtual Machine thread has its own pc (program counter) register. At any point, each Java Virtual Machine thread is executing the code of a single method, namely the current method (§2.6) for that thread. If that method is not native, the pc register contains the address of the Java Virtual Machine instruction currently being executed. If the method currently being executed by the thread is native, the value of the Java Virtual Machine's pc register is undefined. The Java Virtual Machine's pc register is wide enough to hold a returnAddress or a native pointer on the specific platform.
2.2.5 Native Method Stacks(本地方法栈)
如果当前线程执行的方法是Native类型的,这些方法就会在本地方法栈中执行。
Eden:S0:S1 = 8:1:1 因为创建的对象基本上都是“朝生西死”
Young GC (包含了Eden、S区):Minor GC
Old GC : Major GC , MajorGC 通常会伴随着Minor GC ,也就意味着会触发Full GC
Young + Old :full GC
(1) 尽量减少GC频率
(2) Full GC :STW 尽可能减少Full GC的频率(允许一定范围的Young GC)
S0和S1一定要保证一块是空的。
3 Java对象内存布局
一个Java对象在内存中包括3个部分:对象头、实例数据和对齐填充
3.1 内存模型
3.1.1 图解
一块是非堆区,一块是堆区。
堆区分为两大块,一个是Old区,一个是Young区。
Young区分为两大块,一个是Survivor区(S0+S1),一块是Eden区。 Eden:S0:S1=8:1:1
S0和S1一样大,也可以叫From和To。
画个图理解一下
根据之前对于Heap的介绍可以知道,一般对象和数组的创建会在堆中分配内存空间,关键是堆中有这么多区
域,那一个对象的创建到底在哪个区域呢?
3.2 对象创建所在区域
一般情况下,新创建的对象都会被分配到Eden区,一些特殊的大的对象会直接分配到Old区。
比如有对象A,B,C等创建在Eden区,但是Eden区的内存空间肯定有限,比如有100M,假如已经使用了
100M或者达到一个设定的临界值,这时候就需要对Eden内存空间进行清理,即垃圾收集(Garbage Collect),这样的GC我们称之为Minor GC,Minor GC指得是Young区的GC。经过GC之后,有些对象就会被清理掉,有些对象可能还存活着,对于存活着的对象需要将其复制到Survivor区,然后再清空Eden区中的这些对象。
3.3 Survivor区详解
由图解可以看出,Survivor区分为两块S0和S1,也可以叫做From和To 。在同一个时间点上,S0和S1只能有一个区有数据,另外一个是空的。
接着上面的GC来说,比如一开始只有Eden区和From中有对象,To 中是空的。
此时进行一次GC操作,From区中对象的年龄就会+1,我们知道Eden区中所有存活的对象会被复制到To 区,
From区中还能存活的对象会有两个去处。
若对象年龄达到之前设置好的年龄阈值,此时对象会被移动到Old区,如果Eden区和From区没有达到阈值的
对象会被复制到To 区。此时Eden区和From区已经被清空(被GC的对象肯定没了,没有被GC的对象都有了各
自的去处)。
这时候From和To 交换角色,之前的From变成了To ,之前的To 变成了From。
也就是说无论如何都要保证名为To 的Survivor区域是空的。
Minor GC会一直重复这样的过程,知道To 区被填满,然后会将所有对象复制到老年代中。
3.4 Old区详解
从上面的分析可以看出,一般Old区都是年龄比较大的对象,或者相对超过了某个阈值的对象。在Old区也会有GC的操作,Old区的GC我们称作为Major GC。
3.5 对象的一辈子理解
我是一个普通的Java对象,我出生在Eden区,在Eden区我还看到和我长的很像的小兄弟,我们在Eden区中玩了挺长时间。有一天Eden区中的人实在是太多了,我就被迫去了Survivor区的“From”区,自从去了Survivor区,我就开始漂了,有时候在Survivor的“From”区,有时候在Survivor的“To”区,居无定所。直到我18岁的时候,爸爸说我成人了,该去社会上闯闯了。于是我就去了年老代那边,年老代里,人很多,并且年龄都挺大的,我在这里也认识了很多人。在年老代里,我生活了20年(每次GC加一岁),然后被回收。
3.6 常见问题
- 如何理解Minor/Major/Full GC
Minor GC:新生代
Major GC:老年代
Full GC:新生代+老年代
- 为什么需要Survivor区?只有Eden不行吗?
如果没有Survivor,Eden区每进行一次Minor GC,并且没有年龄限制的话,存活的对象就会被送到老年代。
这样一来,老年代很快被填满,触发Major GC(因为Major GC一般伴随着Minor GC,也可以看做触发了Full GC)。
老年代的内存空间远大于新生代,进行一次Full GC消耗的时间比Minor GC长得多。
执行时间长有什么坏处?频发的Full GC消耗的时间很长,会影响大型程序的执行和响应速度。
可能你会说,那就对老年代的空间进行增加或者较少咯。假如增加老年代空间,更多存活对象才能填满老年代。虽然降低Full GC频率,但是随着老年代空间加大,一旦发生Full GC,执行所需要的时间更长。假如减少老年代空间,虽然Full GC所需时间减少,但是老年代很快被存活对象填满,Full GC频率增加。
所以Survivor的存在意义,就是减少被送到老年代的对象,进而减少Full GC的发生,Survivor的预筛选保证,只有经历16次Minor GC还能在新生代中存活的对象,才会被送到老年代。
- 为什么需要两个Survivor区?
最大的好处就是解决了碎片化。也就是说为什么一个Survivor区不行?第一部分中,我们知道了必须设置Survivor区。假设现在只有一个Survivor区,我们来模拟一下流程:
刚刚新建的对象在Eden中,一旦Eden满了,触发一次Minor GC,Eden中的存活对象就会被移动到Survivor区。这样继续循环下去,下一次Eden满了的时候,问题来了,此时进行Minor GC,Eden和Survivor各有一些存活对象,如果此时把Eden区的存活对象硬放到Survivor区,很明显这两部分对象所占有的内存是不连续的,也就导致了内存碎片化。
永远有一个Survivor space是空的,另一个非空的Survivor space无碎片。
- 新生代中Eden:S1:S2为什么是8:1:1?
新生代中的可用内存:复制算法用来担保的内存为9:1
可用内存中Eden:S1区为8:1
即新生代中Eden:S1:S2 = 8:1:1
4 体验与验证
4.1 使用jvisualvm查看
visualgc插件下载链接:
https://visualvm.github.io/pluginscenters.html —>选择对应版本链接—>Tools—>Visual GC若上述链接找不到合适的,大家也可以自己在网上下载对应的版本当然
4.2 堆内存溢出
@RestController
public class HeapController {
List<Person> list=new ArrayList<Person>();
@GetMapping("/heap")
public String heap() throws Exception{
while(true){
list.add(new Person());
Thread.sleep(1);
}
}
}
记得设置参数比如-Xmx20M -Xms20M
4.2.1 运行结果
访问->http://localhost:8080/heap
Exception in thread "http-nio-8080-exec-2" java.lang.OutOfMemoryError: GC overhead limit
exceeded
4.3 方法区内存溢出
比如向方法区中添加Class的信息
4.3.1 asm依赖和Class代码
<dependency>
<groupId>asm</groupId>
<artifactId>asm</artifactId>
<version>3.3.1</version>
</dependency>
public class MetaspaceUtil extends ClassLoader {
public static List<Class<?>> createClasses() {
List<Class<?>> classes = new ArrayList<Class<?>>();
for (int i = 0; i < 10000000; ++i) {
ClassWriter cw = new ClassWriter(0);
cw.visit(Opcodes.V1_1, Opcodes.ACC_PUBLIC, "Class" + i, null,
"java/lang/Object", null);
MethodVisitor mw = cw.visitMethod(Opcodes.ACC_PUBLIC, "<init>",
"()V", null, null);
mw.visitVarInsn(Opcodes.ALOAD, 0);
mw.visitMethodInsn(Opcodes.INVOKESPECIAL, "java/lang/Object",
"<init>", "()V");
mw.visitInsn(Opcodes.RETURN);
mw.visitMaxs(1, 1);
mw.visitEnd();
MetaspaceUtil test = new MetaspaceUtil();
byte[] code = cw.toByteArray();
Class<?> exampleClass = test.defineClass("Class" + i, code, 0, code.length);
classes.add(exampleClass);
}
return classes;
}
}
@RestController
public class NonHeapController {
List<Class<?>> list=new ArrayList<Class<?>>();
@GetMapping("/nonheap")
public String heap() throws Exception{
while(true){
list.addAll(MetaspaceUtil.createClasses());
Thread.sleep(5);
}
}
}
设置Metaspace的大小,比如-XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=50M
4.3.2 运行结果
访问->http://localhost:8080/nonheap
java.lang.OutOfMemoryError: Metaspace
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_191]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_191]
4.4 虚拟机栈
4.4.1 代码演示StackOverFlow
public class StackDemo {
public static long count=0;
public static void method(long i){
System.out.println(count++);
method(i);
}
public static void main(String[] args) {
method(1);
}
}
4.4.2 运行结果
4.4.3 理解和说明
Stack Space用来做方法的递归调用时压入Stack Frame(栈帧)。所以当递归调用太深的时候,就有可能耗尽Stack
Space,爆出StackOverflow的错误。
-Xss128k:设置每个线程的堆栈大小。JDK 5以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。根据应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。
线程栈的大小是个双刃剑,如果设置过小,可能会出现栈溢出,特别是在该线程内有递归、大的循环时出现溢出的可能性更
大,如果该值设置过大,就有影响到创建栈的数量,如果是多线程的应用,就会出现内存溢出的错误。