首页  思维导图  详情

深入理解Java虚拟机(第三版)

2022-05-01 23:05:54   3  举报





AI智能生成

为你推荐

查看更多



本人学习深入理解java虚拟机的一些学习新的

JVM

深入理解Java虚拟机

作者其他创作

大纲/内容

JIT代码缓存(Code Cache)

1.1 线程私有

1.3 不会出现OOM

1、程序计数器

2.1 线程私有

2.4 会出现两类异常

2、Java虚拟机栈

3.1 线程私有

3.2 服务于本地方法

3、本地方法栈

线程私有

4.1 线程共享

4.4 Java对象也可以再栈上分配

4.5 参数： -Xmx和-Xms设定

4、Java堆

字符串常量池、运行时常量池

运行时常量池(Runtime Constant Pool)

5、方法区

线程共享

运行时数据区(Runtime Data Area)

1、直接内存并不是虚拟机运行时数据区的一部分

2、同规格DirectByteBuffer对象作为这块内存的引用进行操作

6、直接内存

运行时数据区域

1、在常量池中检查类的符号引用

2、采用的垃圾收集器带有压缩整理功能

3、Serial、ParNew等收集器

指针碰撞

2、采用的垃圾收集器不带有压缩整理功能

3、CMS基于Mark-Sweep算法收集器

空闲列表

1、CAS配上失败重试的方式

配置：-XX：+/-UseTLAB参数来定

2、本地线程分配缓冲(Thread Local Allocation Buffer， TLAB)

并发问题

2、堆中分配内存

3、初始化对象

4、对象头设置

此时该对象才算完全构造出来

5、执行实例构造函数<init>()方法

对象的创建过程

官方称之为 \"Mark Word\

1、运行时数据

通过这个指针确定该对象是哪个类的实例

并不是所有的虚拟机实现都必须在对象数据上保留类型指针

2、类型指针

3、对齐填充

1、对象头(Header)

2、实例数据(Instance Data)

3、对齐填充(Padding)

对象的内存布局

定义：通过栈上的reference数据来操作堆上的具体对象

使用句柄访问

使用直接指针访问

访问方式

对象的访问定位

HotSpot虚拟机对象

1、哪些内存需要回收

2、什么时候回收

3、如何回收

GC要解决的事情

定义

优点

无法解决对象之间互相引用的问题

缺点

引用计数法

通过一系类称之为\"GC Roots\

方法区中静态属性引用的对象

方法区中常量引用的对象

本地方法栈中JNI引用的对象

被同步锁持有的对象

GC Roots

可达性分析算法

强引用

软引用

弱引用

虚引用

引用的分类

任何对象的finalize()方法都只能被JVM自动调用一次

finallize()方法

该类所有的实例都被回收

加载该类的类加载器已被回收

该类对应的Class对象没有被其他地方引用

不再使用的类型

回收方法区

子主题

分代收集理论

首先标记出所有需要回收的对象，统一回收掉所有被标记的对象

优点：实现简单

缺点：

特点

标记-清除算法

标记-复制算法

标记-整理算法

分带收集理论

垃圾收集算法

哪些对象可以回收

垃圾收集器与内存分配策略

自动内存管理

Java程序设计语言

第三方Java类库

Java类库API

Class文件格式

不同硬件平台的Java虚拟机

组成部分

Java小程序Applets小内存平台

Java Card

支持java运行在移动端上的平台

Java ME

支持桌面级应用的平台

Java SE

支持使用多层架构的的企业应用平台的Java平台

Java EE

产品线

Java技术体系

Java发展史

相当的原始，虚拟机的鼻祖: Sun Classic

使用范围最广的JVM： HotSpot

面向移动和嵌入式市场: Mobile VM

BEA System 公司的 JRockit

IBM 的 IBM J9

...

Java虚拟机

Greel VM

无语言倾向

Graal编译器

先进的即时编译器

向Native迈进

Java体系提供更多的接口

Java虚拟机不断优化增强

语言语法持续增强

展望Java技术的未来

一、走进Java

魔数(Magic Number)

版本号(Version)

常量池容量计数值(constant_pool_count)

字面量

被模块导出或者开放的包(Package)

类和接口的全限定名(Full Qualified Name)

字段的名称和描述符(Descriptor)

方法的名称和描述符

方法句柄和方法类型(Method Handler、Method Type、Invoke Dynamic)

动态调用点和动态常量

符号引用

表项与TAG值

常量池(Constant Pool)

访问标志(Access Flags)

类索引(This)、父类索引(Super Class)与接口索引集合(Interfaces)

全限定名

简单名称

描述符

字段表集合(Field Info)

方法表集合

字节码指令

显示异常处理表

StackMap Table

Code

Exceptions

LineNumberTable

SourceFile

ConstantValue

InnerClasses

Deprecated

Syntheic

Signature

BootstrapMethod

属性表集合

实例分析

文件格式

类文件结构

Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。

Java类型的加载、连接和初始化过程都是在程序运行期间完成的。

概述

类的生命周期

1、使用new关键字实例化对象的时候

2、读取或设置一个类型的静态字段(被final修饰、已在编译器把结果放入常量池的静态字段除外)的时候

3、调用一个类型的静态方法的时候

1、遇到new、getStatic、putStatic、invokeStatic这四个字节码指令时

2、使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化

3、当初始化类的时候，如果发现其父类没有初始化，则需要先触发其父类的初始化

4、当虚拟机启动时，用户需要指定一个要执行的主类(包含main()方法的那个类)，虚拟机会先初始化这个类

5、当使用JDK7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。

6、当一个接口中定义了JDK8新接入的默认方法(被default关键字修饰的接口方法)时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

初始化开始的6种情况(有且仅有)

主动引用

类加载的时机

获取二进制字节流

生成运行时数据结构(方法区)

生成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文件来保障程序运行逻辑不被窥探。

获取类的二进制字节流的方式

加载阶段和连接阶段的过程是交叉进行的

加载(Loading)

防止访问数组边界以外的数据

防止将对象类型转型为并未实现的类型

防止跳转到不存在的代码行

验证的目的

文件格式校验

元数据校验

字节码校验

符号引用校验(发生在解析阶段)

四个阶段的校验动作

验证（Verification）

首先是这时候进行内存分配的仅包含类变量，而不是实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中

其次是这里所说的初始值\"通常情况下\"是数据类型的零值

准备阶段两个容易混淆的概念

1、内存分配

非接口符号引用

接口符号引用

方法表

2、创建数据结构

3、设置默认值

准备（Preparation）

直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。

直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。

如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。

直接引用：指针、偏移量或句柄，目标一定加载在内存中，与虚拟机内存布局有关

符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。

符号引用与虚拟机实现的内存布局无关，引用的目标并不一定是已经加载到虚拟机内存当中的内容。

各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。

符号引用：符号表示的，目标不一定已加载在内存中，与虚拟机内存布局无关

将常量池内符号引用替换为直接引用的过程

不是数组类型：当前类的类加载器得到目标类的全限定名

数组类型：先加载数组元素类型

符号引用验证

类/接口的解析

1、类只包含简单名称和字段描述符与目标相匹配的字段，则返回这个字段的直接引用

2、否则，如果类实现了接口，按照继承关系从下往上递归搜索各个接口重复1

3、否则，如果不是java.lang.Object，按照继承关系从下往上递归搜索各个父类重复1

4、否则，查找失败

字段解析

类方法解析

接口方法解析

分类

解析(Resulution)

1、对类进行加载和链接

2、优先初始化父类

3、一次执行类初始化语句

执行步骤

<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的。（静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问）

<clinit>()方法与类的构造函数（即在虚拟机视角中的实例构造器<clinit>()方法）不同，它不需要显式地调用父类构造器，Java虚拟机会保证在子类的<clinit>()执行前，父类的<clinit>()方法已经执行完毕。因此在Java虚拟机中第一个被执行的<clinit>()方法的类型肯定是java.lang.Object。

由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。

<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。

接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。此外，接口的实现类在初始化时也一样不会执行接口的<clinit>()。

Java虚拟机必须保证一个类的<clinit>()方法在多线程环境中被正确地加锁同步，如果多个线程同时去初始化一个类，那么只会有其中一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行完毕<clinit>()方法。

<clinit>()方法

触发条件(有且仅有)

通过子引用父类的静态字段，不会导致子类的初始化

通过数组定义类引用类，不会触发此类的初始化

常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化

不会触发初始化

初始化（Initialization）

被动引用

使用

卸载

外框

类加载的过程

连接（Linking）

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

1、类与类加载器

1、启动类加载器(Bootstrap ClassLoader)，这个类加载器使用C++语言实现，是虚拟机自身的一部分

2、其它所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader

站在Java虚拟机的角度来看，只存在两种不同的类加载器

这个类加载器负责加载存放在<JAVA_HOME>\\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。

启动类加载器无法被Java程序直接使用，用户在编写自定义类加载器时，如果需要把加载器请求委派给引导类加载器去处理，那直接使用null代替即可

启动类加载器(Bootstrap Class Loader)

这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。

它负责加载<JAVA_HOME>\\lib\\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。

JDK的开发团队允许用户将具有通用性的类库放置在ext目录里以扩展Java SE的功能，在JDK 9之后，这种扩展机制被模块化带来的天然的扩展能力所取代。

由于扩展类加载器是由Java代码实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件。

扩展类加载器(Extension Class Loader)

这个类加载器由sun.misc.Launcher$AppClassLoader来实现。

由于应用程序类加载器是ClassLoader类中的getSystem-ClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。

它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。

应用程序类加载器(Application Class Loader)

三层类加载器

双亲委派模型

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。

这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。

类加载器双亲委派模型

1.如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成；

2.每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中；

3.只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

双亲委派的过程

类随着它的类加载器一起具备了一种带有优先级的层次关系。

双亲委派模型对于保证Java程序的稳定运作极为重要。

双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载）

双亲委派的优点

站在Java开发人员的角度来看

2、双亲委派模型

第1次“被破坏”：JDK1.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的加载提供了一种相对合理的解决方案。

第2次\"被破坏\"

第3次“被破坏”：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等

3、破坏双亲委派模型

Tomcat

SPI

OSGI

替换JDK类

不遵循模型

从字节码到Class对象

生产字节码

自己实现动态代理

类的动态加载