JVM学习笔记
- 一.学习前言
- 二.类加载子系统
- 三.运行时数据区概述即线程
-
- 1.运行时数据区结构
- 2.数据区与线程的关系
- 3.线程
- 4.后台线程
- 5.程序计数器(PC寄存器)
- 6.虚拟机栈
- 7.本地方法接口
- 8.本地方法栈
- 9.堆
- 10.方法区
- 11.对象的实例化与内存分配
- 12.直接内存
- 四.执行引擎
- 五.StringTable
- 六.垃圾收集器
一.学习前言
1.Java与JVM
Java是跨平台的语言,JVM是跨语言的平台(Scala,Jython,Groovy等)
JVM具有自动内存管理,自动垃圾回收功能
2.JVM整体结构
类装载器子系统将class文件加载到数据区形成一个大的class对象,过程为加载,链接,初始化;方法区和堆是多线程共享的,Java栈,本地方法栈,程序计数器是各个线程独有一份。执行引擎(编译为机器语言)中有解释器,JIT即时编译器(后端编译器)和垃圾回收器,JIT可以缓存代码指令,但缺点是启动的时候会产生卡顿,主流的虚拟机是二者结合起来系统使用。
3.JVM架构总结
由于跨平台性的设计,Java的指令都是根据栈来设计的,不同平台CPU架构不同,所以不能设计为基于寄存器的,优点是跨平台,指令集小,编译器容易实现,缺点是性能下降,实现同样的功能需要更多的指令。
4.一些主流虚拟机
HotSpot,JRockit(Oracle),J9(IBM),KVM(小型设备),Azul,Liquid(与硬件高度耦合,性能极高),Harmony(Apache,大量在Android SDK中使用),Microsoft JVM(版权问题),Taobao JVM(创新的off-heap技术,将生命周期较长的对象从heap内移到heap外的GCIH中,不受GC管理,降低GC频率,提高效率;GCIH中的对象还能在多个JAVA虚拟机进程中实现共享,硬件上严重依赖intel的CPU),Dalvik VM(非JAVA虚拟机规范,基于寄存器架构,执行dex文件(可以通过class文件转换而来),效率较高,可以直接使用大部分的JAVA API,Android 5.0以前所使用的虚拟机),Graal VM(HotSpot未来最大可能的替代品,Oracle号称可以运行所有语言),本次学习主要以HotSpot作为默认虚拟机
二.类加载子系统
1.内存结构概述
2.类加载器的角色
- class文件存在本地硬盘上,作为一个模板,最终这个模板在执行的时候要加载到JVM中来根据这个模板实例化出n个一摸一样的实例
- class文件加载到JVM中,被称为DNA元数据模板,放在方法区中
- 在class文件 -> JVM -> 最终成为元数据模板的过程中,需要一个运输工具,就是ClassLoader,扮演一个快递员的角色。
3.类加载过程
加载
- 通过一个类的全限定名获取此类的二进制流
- 将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构
- 在内存中生成代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口
加载class文件的方式
- 从本地系统中直接加载
- 通过网络获取,典型场景:web Applet
- 从zip压缩包中读取,成为日后jar,war的基础
- 运行时计算生成,使用最多的是:动态代理技术
- 由其他文件生成,典型场景有:JSP应用
- 从专有数据库中提取class文件,比较少见
- 从加密文件中获取,典型的防class文件被反编译的保护措施
链接
-
验证(Verify)
- 目的在于确保class文件的字节流中包含的信息符合当前虚拟机的需求,保证被加载类的正确性,不会危害虚拟机自身安全,如class文件开头形式为CA FE BA BE(咖啡宝贝)
- 主要包括四种验证,文件格式验证,元数据验证,字节码验证,符号引用验证
-
准备(Prepare)
- 为类变量分配内存并且设置该类变量的默认初始值,即零值,如:private static int a = 1;在该阶段a被赋予0,在初始化阶段才赋予1.
- 这里不包含用final修饰的static,因为final在编译的时候就会分配了,准备阶段会显示初始化,即直接赋值。
- 这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一起分配到堆中。
-
解析(Resolve)
- 将常量池内的符号引用转换为直接引用的过程
- 事实上,解析操作往往会伴随着JVM在执行完初始化之后再执行
- 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针,相对偏移量或一个间接定位到目标的句柄
- 解析动作主要针对类或接口,字段,类方法,接口方法,方法类型等。对应常量池的CONSTANT_Class_info,CONSTANT_Fieldref_info,CONSTANT_Methodref_info等。
初始化
- 初始化阶段就是执行类构造方法<clinit>()的过程
- 此方法不需要定义,是javac编译器自动收集类中的所有类变量的赋值动作的静态代码块中的语句合并而来,如果没有此操作则不会生成
- 构造器方法中指令按语句在源文件中出现的顺序执行。 注意:由于在初始化之前有 p r e p a r e 阶段,会将变量声明并赋默认值,所以在静态代码块中修改变量可以在声明的前面,但是不能在声明的前面使用变量,即非法的前向引用 \color{red}{注意:由于在初始化之前有prepare阶段,会将变量声明并赋默认值,所以在静态代码块中修改变量可以在声明的前面,但是不能在声明的前面使用变量,即非法的前向引用} 注意:由于在初始化之前有prepare阶段,会将变量声明并赋默认值,所以在静态代码块中修改变量可以在声明的前面,但是不能在声明的前面使用变量,即非法的前向引用
- <clinit>()不同于类的构造器。(关联:构造器是虚拟机视角下的<init>())
- 若该类具有父类,JVM会保证在子类的<clinit>()执行前,父类的<clinit>()已经执行完毕。
public class Test{
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){
System.out.println(Son.B);
}
}
首先加载Test类(父类Object已加载),执行main方法,加载Son类时先加载其父类Father,在<clinit>()中按照代码流程赋值A为2,在Son的<clinit>()中将B赋值为2
- 虚拟机必须保证一个类的<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 t1 = new Thread(r,"线程2");
t1.start();
t2.start();
}
}
class DeadThread(){
static{
if(true){
System.out.println(Thread.currentThread().getName() + "初始化当前类");
while(true)
}
}
}
运行结果只有一个线程进行初始化该类,当该线程无法完成初始化之后另一个线程也会被阻塞
- 任何一个类声明之后,内部至少存在一个类的构造器(<init>(),即如果不显示的声明一个构造函数,JVM会默认生成一个无参的构造函数)
4.类加载器分类
- JVM支持两种类型的类加载器,分别为引导类加载器(Bootstrap ClassLoader)和自定义加载类(User-Defined ClassLoader)
- 从概念上来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类加载器,但是JAVA虚拟机没有这么定义,而是将所有派生于抽象类ClassLoader的类加载器划分为自定义加载器
- 无论类加载器如何划分,在程序中我们最常见的类加载器始终只有3个:
Bootstrap ClassLoader是通过C/C++实现的,其他都是通过Java实现的
获取类加载器
public class ClassLoaderTest{
public static void main(String[] args){
//获取系统类加载器
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
//获取其上层:扩展类加载器
ClassLoader extClassLoader = systemClassLoader.getParent();
//获取其上层:获取不到引导类加载器
ClassLoader bootstrapClassLoader = ext.getParent();//null
//对于用户自定义来说:默认使用系统类加载器加载
ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();//与systemClassLoader一样
//null,是通过引导类加载器加载,Java的核心类库都是
ClassLoader stringClassLoader = String.class.getClassLoader();
}
}
虚拟机自带的加载器
-
启动类加载器(引导类加载器,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等开头的类
-
扩展类加载器(Extension ClassLoader)
- Java语言编写,由sun.misc.Laucher$ExtClassLoader实现
- 派生于ClassLoader类
- 父类加载器为Bootstrp ClassLoader
- 从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下加载类文件,如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。
-
应用程序类加载器(系统类加载器,AppClassLoader)
- java语言编写,由sun.misc.Launcher$AppClassLoader实现
- 派生于ClassLoader类
- 父类加载器为扩展类加载器
- 它负责加载环境变量classpath或系统属性,java.class.path指定路径下的类库
- 该类加载是程序中默认的类加载器,一般来说,Java应用的类都是由它来加载完成的
- 通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器
用户自定义类加载器
- 在Java日常应用程序的开发中,类加载器几乎是由以上三种类加载器互相配合执行的,在必要时,我们还可以自定义类加载器,来定制类的加载方式
-
为什么要自定义类加载器
- 隔离加载类(不同中间件,依赖名字相同的冲突类,需要不同加载器隔离)
- 修改类加载方式
- 扩展加载源
- 防止源码泄露
用户自定义加载器实现步骤
- 开发人员可以通过继承java.lang.ClassLoader类的方式,实现自己的类加载器,以满足一些特殊的需要
- 在JDK1.2之前,在自定义类加载器时,总会去继承ClassLoader并且重写loadClass()方法,从而实现自定义的类加载,但是在JDK1.2之后已不再建议用户去覆盖loadClass(),而是建议把自定义的类加载器逻辑写在findClass()方法中
- 在编写自定义类加载时,如果没有太过于复杂的需求,可以直接继承URLClassLoader类,这样就可以避免自己去编写findClass()方法及其获取字节流的方式,简化自定义类加载器。
5.双亲委派机制
简述
Java虚拟机对class文件采用的时按需加载的方式,也就是说当需要使用该类的时候才会将它的class文件加载到内存生成class对象,而且加载某个类的class文件时,Java虚拟机采用的是双亲委派模式,即把请求交由父类处理,它是一种任务委派模式
工作原理
- 如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行;
- 如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将达到顶层的启动类加载器
- 如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式
优点
- 避免类的重复加载
- 保护程序的安全,防止核心API被随意篡改
- 自定义类:java.lang.String
- 自定义类:java.lang.Test
沙箱安全机制
自定义String类,但是在加载自定义String类的时候会率先使用引导类加载器加载,而引导类加载器在加载过程中会先加载JDK自带的文件(rt.jar包中的java\lang\String.class),报错信息说没有main方法,就是因为加载的是rt.jar中的String类,这样可以保证对java核心源代码的保护,这就是沙箱安全机制
6.其他
同一个类的判定
- 类的完整类名必须一致,包括包名
- 加载这个类的ClassLoader(指ClassLoader实例对象)必须相同
换句话来说,在JVM中,即使这两个类对象来源于同一个class文件,被同一个虚拟机加载,但只要加载他们的ClassLoader实例对象不一样,那么这两个类也是不相等的
对类加载器的引用
JVM必须知道一个类型是由启动加载器还是由用户类加载器加载的,如果一个类型是用户类加载器加载的,那么JVM会将这个类加载器的一个引用作为类型信息的一部分存储在方法区中,当解析一个类型到另一个类型的引用的时候,JVM必须保证这两个类型的类加载器相同的
Java程序对类的使用方式分为两种
-
主动使用
- 创建类的实例
- 访问某个类或者接口的静态变量,或者对该静态变量赋值
- 调用类的静态方法
- 反射(如Class.forName(“”))
- 初始化一个类的子类
- Java虚拟机启动时被表明为启动类的类
- JDK 7 开始提供的动态语言支持:java.lang.invoke.MethodHandle实例的解析结果REF_getStatic,REF_putStatic,REF_invokeStatic句柄对应的类没有初始化,则初始化
-
被动使用
除了以上七种情况,其他使用Java类的方式都是对类的被动使用,都不会导致类的初始化
三.运行时数据区概述即线程
1.运行时数据区结构
2.数据区与线程的关系
红色部分(堆,方法区,随着JVM启动而生成,JVM结束而销毁,整个运行过程独一份),灰色部分(栈,本地方法站,PCR随着线程生成而生成,线程结束而销毁,一个线程有一份)
3.线程
- 线程是一个程序里的运行单元,JVM允许一个应用有多个线程并行的执行
- 在HotSpot JVM里,每个线程都与操作系统的本地线程直接映射(当一个Java线程准备好执行之后,此时一个操作系统的本地线程也同时创建,Java线程执行终止之后,本地线程也会回收)
- 操作系统负责所有线程的安排调度到任何一个可用的CPU上,一旦本地线程初始化,它就会调用Java线程中的run()方法
4.后台线程
后台线程不包括调用main线程已经main中创建的线程。
- 虚拟机线程:这种线程的操作是需要JVM达到安全点才会出现,如执行STW进行垃圾收集,线程栈收集,线程挂起以及偏向锁撤离
- 周期任务线程:这种线程是时间周期事件的体现,如中断,他们一般用于周期性操作的调度执行
- GC线程:这种线程对在JVM里不同种类的垃圾收集行为提供了支持
- 编译线程:这种线程在运行时会将字节码编译成本地代码
- 信号调度线程:这种线程接收信号并发送给JVM,在它内部通过调用适当方法进行处理
5.程序计数器(PC寄存器)
概述
JVM中的程序计数命名源于CPU的寄存器,存储指令相关的现场信息,CPU只有把数据装在在寄存器中才能够运行,也可以称为程序钩子,这里,并非广义上所指的物理寄存器,JVM中的寄存器是对物理PC寄存器的一种抽象模拟
作用
PC寄存器用来存储指向下一条指令的地址,也即将要执行的指令代码,由执行引擎读取下一条指令
举例
两个常见问题
因为CPU需要不停的切换各个线程,这时候切换回来以后,就得知道接着从哪儿继续执行,JVM的字节解释器需要通过改变PC寄存器的值来明确下一条执行什么样的字节码指令
线程实质上是通过时间片轮转并发执行,每个线程要从上一次时间片继续执行,必须由一个记录自己执行位置的寄存器
6.虚拟机栈
Java虚拟机栈和作用
每个线程在创建的时候都会创建一个虚拟机栈,其内部保存一个个的栈帧,对应着一次次的Java方法调用,主管Java程序的运行,它保存方法的局部变量,部分结果,并参与方法的调用和返回
特点
- 栈是一种快速有效的分配存储方式,访问速度仅次于程序计数器
- JVM直接对Java栈的操作只有两个
- 每个方法执行,伴随着进栈
- 执行结束后的出栈工作
- 对于栈来说不存在垃圾回收问题
设置栈内存大小
我们可以使用参数-Xss选项来设置线程的最大栈空间,栈的大小直接决定了函数调用的最大可达深度
栈运行特点
- 不同线程中所包含的栈帧是不允许存在相互引用的,即不可能在一个栈帧之中引用另外一个线程的栈帧
- 如果当前方法调用了其他方法,方法返回之际,当前栈帧会传回此方法的执行结果给前一个栈帧,接着,虚拟机会丢弃当前栈帧,使得前一个栈帧重新成为当前栈帧
- Java方法有两种返回函数的方式,一种是正常的函数返回,使用return指令,另外一种是抛出异常,不管用那种方式,都会导致栈帧被弹出
栈帧的内部结构
局部变量表
- 局部变量表也被称为局部变量数组和本地变量表
- 定义为一个数组,主要用于存储方法参数和定义在方法体内的局部变量,这些数据类型包括各类基本数据类型,引用对象,以及returnAddress类型
- 由于局部变量表是建立在线程的栈上,是线程的私有数据,因此不存在数据安全问题
- 局部变量表所需要的容量大小是在编译期确定下来的,并保存在方法的Code属性的maximum local variables数据项中,在方法运行期间是不会改变局部变量表大小的
- 方法嵌套调用的次数由栈的大小决定(否则会报StackOverFlowError),一般来说,方法嵌套调用次数越多,对一个函数而言,它的参数和局部变量越多,使得局部变量表膨胀,它的栈帧就越大,以满足方法调用所需传递的信息增大的需求,进而函数调用就会占用更多的栈空间,导致其嵌套调用次数就会减少
- 局部变量表中的变量只在当前方法调用中有效。在方法执行时,虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后,随着方法栈帧的销毁,局部变量表也随之销毁
局部变量表字节码详解(Idea插件Jclasslib)
表示当前参数字节指令的行数
表示当前参数的长度
表示当前参数的下标
Start PC + Length 等于当前方法的作用域及方法字节码的总长度,当前方法长度为16
方法字节码练习
public class FunctionBinaryTest {
public static void main(String[] args) {
FunctionBinaryTest functionBinaryTest = new FunctionBinaryTest();
int a = 1;
String string = "123";
System.out.println(string);
System.out.println(functionBinaryTest.getInt());
}
public int getInt(){
int j = 2;
int k = 3;
return j