深入理解Java虚拟机(第三版)
2022-05-01 23:05:54 3 举报AI智能生成
本人学习深入理解java虚拟机的一些学习新的
作者其他创作
大纲/内容
自动内存管理
运行时数据区域
JIT代码缓存(Code Cache)
运行时数据区(Runtime Data Area)
线程私有
1、程序计数器
1.1 线程私有
1.2 当前线程锁执行的字节码的行号指示器,
1.3 不会出现OOM
2、Java虚拟机栈
2.1 线程私有
2.2 Java方法执行的线程内存模型,每个方法被执行时 JVM会同步创建一个栈帧,
2.3 用于存储: 局部变量表, 操作数栈,动态链接, 方法出口等
2.4 会出现两类异常
若线程请求的栈深度超过JVM所允许的深度, 抛出StackOverflowError
栈扩展时无法申请到足够的内存, 抛出OutOfMemoryError
3、本地方法栈
3.1 线程私有
3.2 服务于本地方法
线程共享
4、Java堆
4.1 线程共享
4.2 JVM启动时创建, 存放对象的实例;
4.3 新生代, 老年代, 永久代, Eden, Survivor ... 把Java堆细分只要是为了更好地回收内存, 或者更快的分配内存
4.4 Java对象也可以再栈上分配
4.5 参数： -Xmx和-Xms设定
5、方法区
5.2 存储被JVM加载的类型信息, 常量, 静态变量，即时编辑器编译后的代码缓存等数据
字符串常量池、运行时常量池
运行时常量池(Runtime Constant Pool)
6、直接内存
1、直接内存并不是虚拟机运行时数据区的一部分
2、同规格DirectByteBuffer对象作为这块内存的引用进行操作
HotSpot虚拟机对象
对象的创建过程
1、在常量池中检查类的符号引用
2、堆中分配内存
指针碰撞
1、内存分配是规整的, 每次分配内存时, 使用指针位移的方式进行
2、采用的垃圾收集器带有压缩整理功能
3、Serial、ParNew等收集器
空闲列表
1、JVM维护一个列表, 记录堆内存哪些内存块是可用的, 每次分配完内存之后更新该列表
2、采用的垃圾收集器不带有压缩整理功能
3、CMS基于Mark-Sweep算法收集器
并发问题
1、CAS配上失败重试的方式
2、本地线程分配缓冲(Thread Local Allocation Buffer， TLAB)
配置：-XX：+/-UseTLAB参数来定
3、初始化对象
4、对象头设置
对象是哪个类的实例, 哈希码, GC分代年龄...; 至此JVM视角,一个对象已创建完成
从Java程序的视角, 构造函数尚未执行(Class文件中的<init>), 字段默认是0值, 此时程序对象还不能使用
5、执行实例构造函数<init>()方法
此时该对象才算完全构造出来
对象的内存布局
1、对象头(Header)
1、运行时数据
官方称之为 "Mark Word", 动态定义的数据结构, 包括: 哈希码, GC分代年龄,锁状态标志, 线程持有的锁, 偏向线程id, 偏向时间戳等等
2、类型指针
通过这个指针确定该对象是哪个类的实例
并不是所有的虚拟机实现都必须在对象数据上保留类型指针
3、对齐填充
如是数组,则还有个数组长度
2、实例数据(Instance Data)
程序代码中所定义的各种类型的字段内容, 无论是父类继承下来的字段还是本类自己的都会记录下来,按照默认的分配策略,相同宽度的字段总是分配到一起
3、对齐填充(Padding)
JVM要求对象的起始地址必须是8字节的整数倍, 所以如果对象实例数据没有对齐的话, 就需要通过对齐填充
对象的访问定位
定义：通过栈上的reference数据来操作堆上的具体对象
访问方式
使用句柄访问
Java堆中划分一块内存作为句柄池, reference保存的就是对象的句柄地址,而句柄保存的是实例地址和对应的类型数据地址
优势：reference中存放的是稳定的句柄, 对象被移动的时候, 修改的是句柄中实例对象的指针, reference不必修改
使用直接指针访问
栈上直接存放的就是堆中对象的内存地址, 这种方案就需要考虑类型数据如何存放
优势：访问速度快, 节省了一次指针定位的开销
垃圾收集器与内存分配策略
GC要解决的事情
1、哪些内存需要回收
2、什么时候回收
3、如何回收
哪些对象可以回收
引用计数法
定义
在对象中添加一个引用计数器,当该对象被引用一次,计数器就加1, 引用失效一次,计数器减1, 计数器为0那么该对象就没有被使用
优点
原理简单容易实现,判断效率也很高
缺点
无法解决对象之间互相引用的问题
可达性分析算法
定义
通过一系类称之为"GC Roots" 的对象作为起始节点根据引用关系进行遍历,没有被遍历到的对象则列为可被回收范围
GC Roots
JVM栈中引用的对象. 例如: 方法中使用的参数, 局部变量, 临时变量等
方法区中静态属性引用的对象
方法区中常量引用的对象
本地方法栈中JNI引用的对象
JVM内部的引用, 流入: 基本数据类型对应的Class对象, 系统类加载器
被同步锁持有的对象
反映JVM内部情况的JMXBean, JVMTI中注册回调, 本地代码缓存等
引用的分类
强引用
程序中普遍存在的引用赋值, 只要存在这种关系, 被引用的对象就不会被回收
软引用
一些有用但非必须对象, 将要发生内存溢出异常前,会把这些对象列入回收范围进行第二次回收
常常被用来实现缓存技术, 例如: 图片缓存, 网页缓存
弱引用
非必须对象, 只能生存到下一次GC发生为止
虚引用
无法通过一个虚引用获取一个对象的实例, 唯一的目的只是为了这个对象被GC时可以收到一个系统通知
finallize()方法
finalize()何时可以被执行, 1. 对象的finalize方法没有被复写; 2. 对象的finalize方法已经被JVM调用过. 这两种情况都视为 "没有必要执行"
对象经过可达性分析 进行第一次标记之后, 若需要执行finzlize()方法, 则该对象被放置在F-Queue队列中
稍后会被JVM自建的, 低优先级的Finalizer线程执行对象的finalize()方法,在该方法中可以进行自救(例如把自己的引用赋值给其他变量)
finalize()方法是对象逃脱被GC的最后一次机会, 随后收集器会对F-Queue中的对象进行第二次小规模的标记
任何对象的finalize()方法都只能被JVM自动调用一次
回收方法区
废弃的常量: 常量池中的对象没被引用, 那么GC该区域的时候, 判定要被回收的话, 则会被清理掉
不再使用的类型
该类所有的实例都被回收
加载该类的类加载器已被回收
该类对应的Class对象没有被其他地方引用
垃圾收集算法
分代收集理论
子主题
标记-清除算法
首先标记出所有需要回收的对象，统一回收掉所有被标记的对象
特点
优点：实现简单
缺点：
标记-复制算法
标记-整理算法
分带收集理论
一、走进Java
Java技术体系
组成部分
Java程序设计语言
第三方Java类库
Java类库API
Class文件格式
不同硬件平台的Java虚拟机
产品线
Java Card
Java小程序Applets小内存平台
Java ME
支持java运行在移动端上的平台
Java SE
支持桌面级应用的平台
Java EE
支持使用多层架构的的企业应用平台的Java平台
Java发展史
Java虚拟机
相当的原始，虚拟机的鼻祖: Sun Classic
使用范围最广的JVM： HotSpot
面向移动和嵌入式市场: Mobile VM
BEA System 公司的 JRockit
IBM 的 IBM J9
...
展望Java技术的未来
无语言倾向
Greel VM
任何语言通过解释器转化的中间表示层, 然后通过该虚拟机加载运行
先进的即时编译器
Graal编译器
采用更加先进的优化方案,及时编译热点代码等.
向Native迈进
JVM可直接加载预编译成二进制并调用, 降低了内存占用和启动时间, 实现"Run Programs Faster Anywhere"
Java虚拟机不断优化增强
Java体系提供更多的接口
jdk1.4时, 已开放了Java虚拟机信息监控接口 JVMPI 和 Java虚拟机调试接口 JVMDI
jdk5时, 抽象了Java虚拟机工具接口 JVMTI
jdk6时, JVMTI不断增强替换了原来的 JVMPI 和 JVMDI
jdk9时, 开放了Java言语级别的编译器接口 JVMCI
jdk10时, 重构了Java虚拟机垃圾收集器接口 JVMGI, 统一了内部垃圾收集器的公共行为
语言语法持续增强
如: jdk10中, 本地类型变量的推导; jdk13中, switch支持表达式, 字符串文本块; 基本类型的泛型支持
三、虚拟机执行子系统
类文件结构
文件格式
魔数(Magic Number)
版本号(Version)
常量池(Constant Pool)
常量池容量计数值(constant_pool_count)
字面量
符号引用
被模块导出或者开放的包(Package)
类和接口的全限定名(Full Qualified Name)
字段的名称和描述符(Descriptor)
方法的名称和描述符
方法句柄和方法类型(Method Handler、Method Type、Invoke Dynamic)
动态调用点和动态常量
表项与TAG值
访问标志(Access Flags)
类索引(This)、父类索引(Super Class)与接口索引集合(Interfaces)
字段表集合(Field Info)
全限定名
简单名称
描述符
方法表集合
属性表集合
Code
字节码指令
显示异常处理表
StackMap Table
Exceptions
LineNumberTable
SourceFile
ConstantValue
InnerClasses
Deprecated
Syntheic
Signature
BootstrapMethod
实例分析
字节码指令
虚拟机类加载机制
概述
Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。
Java类型的加载、连接和初始化过程都是在程序运行期间完成的。
类加载的时机
类的生命周期
类的生命周期
加载、验证、准备、初始化、卸载这5个阶段的顺序是确定的，类型的加载过程必须按照这种顺序按部就班地开始,而解析阶段不一定;它在某种情况下可以在初始化阶段开始之后再开始，这是为了Java语言的运行时绑定特性(也称为动态绑定或晚期绑定)
初始化开始的6种情况(有且仅有)
1、遇到new、getStatic、putStatic、invokeStatic这四个字节码指令时
1、使用new关键字实例化对象的时候
2、读取或设置一个类型的静态字段(被final修饰、已在编译器把结果放入常量池的静态字段除外)的时候
3、调用一个类型的静态方法的时候
2、使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化
3、当初始化类的时候，如果发现其父类没有初始化，则需要先触发其父类的初始化
4、当虚拟机启动时，用户需要指定一个要执行的主类(包含main()方法的那个类)，虚拟机会先初始化这个类
5、当使用JDK7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
6、当一个接口中定义了JDK8新接入的默认方法(被default关键字修饰的接口方法)时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。
类加载的过程
加载(Loading)
类加载
非数组类加载过程
获取二进制字节流
生成运行时数据结构(方法区)
生成Class对象(堆)
数组类加载过程
1、如果数组的组件类型(Component Type，指的是数组去掉一个纬度的类型，注意和前面的元素类型分开来)是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组C将被标识在加载该组件类型的类加载器的类名称空间上（一个类型必须与类加载器一起确定唯一性）。
2、如果数组的组件类型不是引用类型(例如int[]数组的组件类型是int)，Java虚拟机将会把数组C标记为与引导类加载器关联
3、数组类的可访问性与它的组件类型的可访问性一致，如果组件类型不是引用类型，他的数组类的可访问性将默认为public，可被所有的类和接口访问到。
获取类的二进制字节流的方式
1、从ZIP包中获取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。
2、从网络中获取，这种场景最典型的应用就是Web Applet
3、运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass()来为特定接口生成形式为"*$Proxy"的代理类的二进制节流
4、其它文件生成，典型场景是JSP应用，由JSP文件生成对应的Class文件
5、从数据库中读取，这种场景相对少见些，例如有些中间件服务器(如SAP Netweaver) 可以选择把程序安装到数据库中来完成程序代码在集群间的分发。
6、可以从加密文件中获取，这是典型的防止Class文件被反编译的保护措施，通过加载时解密Class文件来保障程序运行逻辑不被窥探。
加载阶段和连接阶段的过程是交叉进行的
验证（Verification）
验证的目的
防止访问数组边界以外的数据
防止将对象类型转型为并未实现的类型
防止跳转到不存在的代码行
四个阶段的校验动作
文件格式校验
元数据校验
字节码校验
符号引用校验(发生在解析阶段)
准备（Preparation）
1、内存分配
准备阶段两个容易混淆的概念
首先是这时候进行内存分配的仅包含类变量，而不是实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中
其次是这里所说的初始值"通常情况下"是数据类型的零值
2、创建数据结构
符号引用
非接口符号引用
接口符号引用
方法表
3、设置默认值
解析(Resulution)
将常量池内符号引用替换为直接引用的过程
直接引用：指针、偏移量或句柄，目标一定加载在内存中，与虚拟机内存布局有关
直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。
直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。
如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。
符号引用：符号表示的，目标不一定已加载在内存中，与虚拟机内存布局无关
符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。
符号引用与虚拟机实现的内存布局无关，引用的目标并不一定是已经加载到虚拟机内存当中的内容。
各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。
分类
类/接口的解析
不是数组类型：当前类的类加载器得到目标类的全限定名
数组类型：先加载数组元素类型
符号引用验证
字段解析
1、类只包含简单名称和字段描述符与目标相匹配的字段，则返回这个字段的直接引用
2、否则，如果类实现了接口，按照继承关系从下往上递归搜索各个接口重复1
3、否则，如果不是java.lang.Object，按照继承关系从下往上递归搜索各个父类重复1
4、否则，查找失败
类方法解析
接口方法解析
初始化（Initialization）
执行步骤
1、对类进行加载和链接
2、优先初始化父类
3、一次执行类初始化语句
<clinit>()方法
<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的。（静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问）
<clinit>()方法与类的构造函数（即在虚拟机视角中的实例构造器<clinit>()方法）不同，它不需要显式地调用父类构造器，Java虚拟机会保证在子类的<clinit>()执行前，父类的<clinit>()方法已经执行完毕。因此在Java虚拟机中第一个被执行的<clinit>()方法的类型肯定是java.lang.Object。
由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。此外，接口的实现类在初始化时也一样不会执行接口的<clinit>()。
Java虚拟机必须保证一个类的<clinit>()方法在多线程环境中被正确地加锁同步，如果多个线程同时去初始化一个类，那么只会有其中一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行完毕<clinit>()方法。
触发条件(有且仅有)
1、遇到new、getStatic、putStatic、invokeStatic这四个字节码指令时
1、使用new关键字实例化对象的时候
2、读取或设置一个类型的静态字段(被final修饰、已在编译器把结果放入常量池的静态字段除外)的时候
3、调用一个类型的静态方法的时候
2、使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化
3、当初始化类的时候，如果发现其父类没有初始化，则需要先触发其父类的初始化
4、当虚拟机启动时，用户需要指定一个要执行的主类(包含main()方法的那个类)，虚拟机会先初始化这个类
5、当使用JDK7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
6、当一个接口中定义了JDK8新接入的默认方法(被default关键字修饰的接口方法)时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。
不会触发初始化
通过子引用父类的静态字段，不会导致子类的初始化
通过数组定义类引用类，不会触发此类的初始化
常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化
使用
卸载
类加载器
1、类与类加载器
对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。
比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。
2、双亲委派模型
站在Java虚拟机的角度来看，只存在两种不同的类加载器
1、启动类加载器(Bootstrap ClassLoader)，这个类加载器使用C++语言实现，是虚拟机自身的一部分
2、其它所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader
站在Java开发人员的角度来看
三层类加载器
启动类加载器(Bootstrap Class Loader)
这个类加载器负责加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。
启动类加载器无法被Java程序直接使用，用户在编写自定义类加载器时，如果需要把加载器请求委派给引导类加载器去处理，那直接使用null代替即可
扩展类加载器(Extension Class Loader)
这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。
它负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。
JDK的开发团队允许用户将具有通用性的类库放置在ext目录里以扩展Java SE的功能，在JDK 9之后，这种扩展机制被模块化带来的天然的扩展能力所取代。
由于扩展类加载器是由Java代码实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件。
应用程序类加载器(Application Class Loader)
这个类加载器由sun.misc.Launcher$AppClassLoader来实现。
由于应用程序类加载器是ClassLoader类中的getSystem-ClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。
它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。
类加载器双亲委派模型
双亲委派模型
双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。
这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。
双亲委派的过程
1.如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成；
2.每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中；
3.只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。
双亲委派的优点
类随着它的类加载器一起具备了一种带有优先级的层次关系。
双亲委派模型对于保证Java程序的稳定运作极为重要。
双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载）
3、破坏双亲委派模型
第1次“被破坏”：JDK1.2 以前，还未出现双亲委派模型
第2次"被破坏"
JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的），它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码。（父类调用子类）
线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
JNDI、JDBC、JCE、JAXB和JBI等类似
当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。
第3次“被破坏”：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等
不遵循模型
Tomcat
SPI
OSGI
替换JDK类
类的动态加载
从字节码到Class对象
生产字节码
自己实现动态代理
虚拟机字节码执行引擎
类加载及执行子系统的案例与实战
0 条评论
下一页
