Deep understanding of the Java Virtual Machine
[TOC]
1 类加载器
1.1 类的加载过程
- 加载
1 | 1: 通过一个类的全限定名称获取此类的二进制字节流 |
- 链接
- 验证
- 文件格式的验证(openjdk/hotspot/src/share/vm/classfile/classFileParser.cpp)
- 元数据验证
- 字节码验证
- 符号引用验证
- 准备
- 解析
- 验证
- 初始化
1 | 执行类构造器方法<clinit>() |
对于初始化阶段 《Java虚拟机规划》 严格定义了有且只有六种情况必须对类进行初始化
- 遇到 new 、getstatic、putstatic或者invokestatic 这四条字节码指令时
- 使用java.lang.reflect包的方法对类型进行反射调用的时候
- 当类初始化的时候 如果发现其父类还没有进行初始化的时候 则需要先触发其父类的初始化
- 当虚拟机启动时用户需要指定一个要执行的主类 虚拟机首先会初始化这个类(即包含main方法的那个类)
- 当使用JDK 7新加入的动态语言支持时 如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic REF_putStatic REF_invokeStatic REF_newInvokeSpecial 四种类型的方法句柄 并且这个方法句柄对应的类没有进行过初始化
- 当接口中定义JDK 8中新加入的默认方法时 如果这个接口的实现类发生了初始化 那该接口要在其之前被初始化
1.2 类加载器的分类
- 引导类加载器(Bootstrap Class Loader) :
- 系统类加载器(System(Application) Class Loader) classpath
- 扩展类加载器(Extension Class Loader) jre目录下 lib/ext
- 自定义类加载器(User-Defined Class Loader)
将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器(不包括引导类加载器)
引导类加载器：使用C/C++代码实现, 嵌套在JVM内部
系统类加载器(AppClassLoader)：程序中通过默认的类加载器
OSGi模型
1.3 双亲委派机制
工作原理:
1 | 1>: 如果一个类加载器收到了类加载请求, 它并不会自己先去加载, 而是把这个请求委托给父类的加载器去执行 |
在JVM中表示两个class对象是否为同一个类存在的两个必要条件
- 类的完整类名必须一致, 包括包名
- 加载这个类的ClassLoader(指ClassLoader实例对象)必须相同
对类加载器的引用：
1 | JVM必须知道一个类型是由引导类加载器加载的还是由用户类加载器加载的. |
2 运行时数据区
方法区和堆有GC, 虚拟机栈和本地方法区以及程序计数器则没有GC
方法区和堆为所有线程所共享, 而虚拟机栈和本地方法区以及程序计数器则每个线程各有一份
2.1 PC寄存器
程序计数器也叫PC寄存器(Program Counter Register)
JVM中PC寄存器是对物理寄存器的一种抽象模拟
程序计数器是唯一一个在JVM中没有规定任何OutOfMemoryError情况的的区域
PC寄存器的作用：
1 | PC寄存器用来存储指向下一条指令的地址(偏移地址), 即将要执行的指令代码, 由执行引擎读取下一条指令. |
PC寄存器被设定为线程私有的原因:
1 | 在多线程环境中, 一个特定的时间段只会执行其中某一个线程的方法, CPU会不停地做任务切换, 这样必然会导致线程中断和恢复, 为了能够准确地记录各个线程正在执行地当前字节码指令地址, 最好的办法自然是为每一个线程都分配一个PC寄存器, 这样一来各个线程之间便可以进行独立计算, 从而不会出现相互干扰的情况. |
CPU时间片即CPU分配给各个程序的时间, 每个线程被分配一个时间段, 称作它的时间片
如果线程正在执行的是一个Java方法 pc记录的是正在执行的虚拟机字节码指令的地址 如果正在执行的是本地方法 pc的值应该为空
2.2 虚拟机栈
由于跨平台的设计, Java的指令都是根据栈来设计的, 因为不同平台CPU架构不同, 所以不能设计为基于寄存器的
虚拟机栈的 优点是: 指令集小, 编译器容易实现 缺点是性能下降, 实现同样的功能需要更多的指令
作用: 主管Java程序的运行, 它保存方法的局部变量、部分结果, 并参与方法的调用和返回
生命周期: 生命周期和线程一致
每个线程在创建时都会创建一个虚拟机栈, 其内部保存一个个的栈帧(Stack Frame), 对应着一次次Java方法调用
栈的特点：
- 栈是一种快速有效的分配存储方式, 访问速度仅次于PC寄存器
- JVM直接对虚拟机栈的操作只有两个
- 每个方法执行, 伴随着进栈(入栈、压栈)
- 执行结束后的出栈工作
- 对于栈来说不存在垃圾回收问题(但是存在OOM和SOF问题)
1 | -Xss1k/1m/1g 设置虚拟机栈内存的大小 |
栈运行原理:
- 不同线程中所包含的栈帧是不允许存在相互引用的, 即不可能在一个栈帧之中引用另外一个线程的帧.
- 如果当前方法调用了其他方法, 方法返回之际, 当前栈帧回传会此方法的执行结果给前一个栈帧, 接着, 虚拟机会丢弃当前栈帧, 使得前一个栈帧重新成为当前栈帧.
- Java方法有两种返回函数的方式, 一种是正常的函数返回, 使用return指令; 另一种是抛出异常. 不管使用哪种方式, 都会导致栈帧被弹出.
2.2.1 栈帧的内部结构
每个栈帧中储存着：
- 局部变量表(Local Variables)
- 操作数栈(Operand Stack)(或表达式栈)
- 动态链接(Dynamic Linking)(或指向运行时常量池的方法引用)
- 方法返回地址(Return Address)(或方法正常退出或者异常退出的定义)
- 一些附加信息
2.2.2 局部变量表
- 局部变量表也称之为局部变量数组或本地变量表
- 定义为一个数字数组, 主要用来储存方法参数和定义在方法体内的的局部变量, 这些数据类型包括各类基本数据类型、对象引用(reference类型 它并不等同于对象本身 可能是指向一个对象起始地址的引用指针 也可能指向一个代表对象的句柄或者其他与此对象相关的位置), 以及returnAddress(指向了一条字节码指令地址)类型
- 由于局部变量表是建立在线程的栈上, 是线程的私有数据, 因此不存在数据安全问题
- 局部变量表所需的容量大小是在编译期确定下来的, 并保存在方法的Code属性的maximun local variables数据项中。在方法运行期间是不会改变局部变量表的大小的
- 方法嵌套的次数由栈的大小决定。一般来说,栈越大, 方法嵌套调用次数越多。对一个函数而言,它的参数和局部变量越多, 使得局部变量表膨胀, 它的帧就越大, 以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间, 导致其嵌套调用次数就会减少
- 局部变量表只在当前方法调用中有效。在方法执行时, 虚拟机通过使用局部变量表完成参数值到参数列表的传递过程。当方法调用结束后, 随着方法栈的销毁,局部变量表也会销毁
- 局部变量表, 最基本的储存单是Slot(变量槽)
- 在《Java虚拟机规范》中对这个内存区域规定了两类异常状况: 如果线程请求的栈深度大于虚拟机所允许的深度 将抛出StackOverflowError异常; 如果Java 虚拟机栈容量可以动态扩展 当栈扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常
- HotSpot虚拟机的栈是不支持动态扩展的
2.2.2.1关于Slot的理解
1 | 1> JVM会为局部变量表中的每一个Slot都分配一个访问索引, 通过这个索引1即可成功访问到局部变量表中指定的局部变量值 |
栈帧中局部变量表中的槽位是可以重用的, 如果一个局部变量过了其作用域, 那么在其作用域之后申明的新的局部变量可能会复用过期局部变量的槽位, 从而达到节省资源的目的
2.2.2.2 总结
- 在栈帧中, 与性能调优最为密切的部分就是局部变量表, 在方法执行时, 虚拟机使用局部变量表完成方法的传递
- 局部变量中的变量也是重要的垃圾回收根节点, 只要被局部变量表中直接或者间接引用的对象都不会被回收
2.2.3 操作数栈
- 操作数栈, 主要用于保存计算的中间结果, 同时作为计算过程中变量临时的储存空间
- 操作数栈就是JVM执行引擎的一个工作区, 当一个方法开始执行的时候, 一个新的栈帧也会随之被创建出来, 这个方法的操作数栈是空的
- 每一个操作数栈都会拥有一个明确的栈深度用于储存数值, 其所需的最大深度在编译器就定义好了, 保存在方法的Code属性中, 为max_stack的值
- 栈中的任何一个元素都可以是任意的Java数据类型
- 32bit的类型占用一个栈单位深度
- 64bit的类型占用两个栈单位深度
- 操作数栈并非采用访问索引的方式来进行数据访问的, 而是只能通过标准的入栈和出栈操作来完成一次数据访问
- 如果被调用的方法带有返回值的话, 其返回值将会被压入当前栈帧的操作数栈中, 并更新PC寄存器中下一条需要执行的字节码指令
- 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配, 这由编译器在编译期间进行验证, 同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证
- 另外, 我们说Java虚拟机的解析引擎是基于栈的执行引擎, 其中的栈指的就是操作数栈
2.2.4 动态链接
- 每个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接
- 在Java源文件被编译到字节码文件中, 所有的变量和方法引用都作为符号引用(symbolic Reference) 保存在class文件的常量池里。比如描述一个方法调用了另外的其他方法时, 就是通过常量池中指向方法的符号引用来表示的, 那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用
2.2.4.1 为什么需要常量池
1 | 常量池的作用就是提供一些符号和常量, 便于指令的识别以及资源的共享和复用 |
2.2.4.2 方法的调用
在JVM中, 将符号引用转换为调用方法的直接引用与方法的绑定机制相关
- 静态链接(静态绑定): 当一个字节码文件被装进JVM内部时, 如果被调用的目标方法在编译期可知, 且运行期保持不变, 这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接
- 动态链接(动态绑定): 如果被调用的·1方法在编译期无法被确定下来, 也就是说, 只能够在程序运行期将调用方法的符号引用转换为直接引用, 由于这种引用转换过程具有动态性, 因此被称为动态链接
2.2.4.3 虚方法和非虚方法
- 普通调用指令
- invokestatic: 调用静态方法, 解阶段确定唯一方法版本
- invokespecial: 调用
方法、私有方法以及父类方法, 解析阶段确定唯一方法版本 - invokevirtual: 调用所有的虚方法
- invokeinterface: 调用接口方法
- 动态调用指令
- invokedunamic: 动态解析出需要调用的方法, 然后执行
前四条指令固化在虚拟机内部, 方法的调用执行不可人为干预, 而invokedynamic指令则支持由用户确定方法的版本。其中invokestatic指令和invokespecial指令调用的方法称为非虚方法, 其余的(final修饰的除外)称为虚方法
2.2.4.4 关于invokedynamic指令
invokedynamic指令于Java7添加, 是为了能够让Java支持动态类型语言而做的一种改进(使用Lamabda表达式可以直接生成)
Java7中增加的动态类型语言支持的本质是对Java虚拟机规范的修改, 而不是对Java语言规则的修改
动态类型语言和静态类型语言
动态类型语言和静态类型语言两者的区别就在于对类型的检查是在编译期还是在运行期, 满足前者就是静态类型语言, 反之是动态类型语言
静态类型语言是判断变量自身的类型信息; 动态类型语言是判断变量值的类型信息, 变量没有类型信息, 变量值才有类型信息
Java是静态类型的语言
2.2.5 方法返回地址
存放调用该方法的pc寄存器的值
- 无论方法正常退出还是异常退出都会回到该方法被调用的位置。方法正常退出时, 调用者的pc计数器的值作为返回地址, 即调用该方法的指令的下一条指令的地址, 而异常退出的, 返回地址是要通过异常表来确定, 栈帧中一般不会保存这部分信息
- 本质上, 方法的退出就是当前栈帧出栈的过程。此时, 需要恢复上层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等, 让调用者方法继续执行下去
- 正常完成出口和异常完成出口的区别在于: 通过异常完成出口退出的不会给它的上层调用者产生任何的返回值
- 执行引擎遇到任意一个方法返回的字节码指令(return),会有返回值传递给上层的方法调用者, 简称正常完成出口
- 一个正常方法调用完成之后究竟需要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定
- 在字节码指令中, 返回指令包含ireturn(当前返回值是boolean、byte、char、short、int类型时使用)、lreturn、freturn、dreturn以及areturn(引用类型)。另外还有一个return指令供声明为void的方法、实例初始化方法、类和接口的初始化方法使用
- 在方法执行过程中遇到了异常, 并且这个异常没有在方法内处理, 也就是没有在本地的异常表中没有搜索到匹配的异常处理器, 就会导致方法退出, 简称异常完成出口(方法执行过程中抛出异常时的异常处理, 储存在一个处理表中)
2.2.6 一附加信息
栈帧中还允许携带与ava虚拟机实现相关的一些附加信息, 比如对程序调试提供支持的信息
2.3 本地方法栈
- Java虚拟机栈用于管理Java方法的调用, 而本地方法栈用于管理本地方法的调用
- 本地方法栈, 也是线程私有的
- 允许被实现成固定或者是可扩展的内存大小
- 如果线程请求分配的栈容量超过本地方法栈允许的最大容量, Java虚拟机将会抛出一个StackOverflowError异常
- 如果本地方法栈可以动态扩展, 并且在尝试扩展的时候无法申请到足够的内存, 或者在创建线程时没有足够的内存去创建对应的本地方法栈, 那么Java虚拟机将会抛出一个OutofMemoryError异常
- 本地方法是使用C/C++语言实现的
- 加载本地方法的具体做法是Native Method Stack中登记native方法, 在Execution Engine执行时加载本地方法库
- 当某个线程调用一个本地方法时, 它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限
- 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区
- 它甚至可以本地处理器中的寄存器
- 直接从本地内存的堆中分配任意数量的内存
- 并不是所有的JVM都支持本地方法栈 因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构。如果JVM产品不打算支持native方法, 也可以无需实现本地方法栈
- 在HotSpot中, 直接将本地方法栈和虚拟机栈合二为一
2.4 堆
- 一个JVNM实例只存在一个堆内存, 堆也是Java内存管理的核心区域
- Java堆内存的JVM启动的时候即被创建, 其空间大小也就确定了。堆区是JVM管理的最大一块内存空间(堆内存的大小是可以调节的)
- 《JVM虚拟机规范》规定, 堆可以处于物理上不连续的内存空间, 但是在逻辑上它应该被视为连续的
- 所有的的线程共享Java堆, 在这里还可以划分为线程私有的缓冲区(Thread Local Allocation Buffer TLAB)
- 堆, 是GC(Garbage Collection 垃圾回收器) 执行垃圾回收的重点区域
- 在方法结束后, 堆中的对象不会马上被移除, 仅仅在垃圾收集的时候才会移出(GC的启动也需要消耗系统资源, 所以GC并不会频繁的启动)
1 | # 打印虚拟机参数(加号表示启用 减号表示不启用) |
1 | -Xms20m -Xmx20m(默认单位字节) -XX:+PrintGCDetails |
现代垃圾收集器都基于分代收集理论设计, 堆内存逻辑上细分为新生代(New)、老年代(Tenured, Old )以及元空间(Metaspace)(Java8之前叫作永久代)
2.4.1 堆空间大小的设置
-Xms 用于设置堆区的起始内存(年轻代 +老年代), 等价于-XX:InitialHeapSize
-Xmx 则用于设置堆区的最大内存(年轻代 +老年代), 等价于-XX:MaxHeapSize
一旦堆区中的内存大小超过了-Xmx所指定的最大内存时, 将会抛出OutofMemoryError异常
通常会将-Xms和-Xmx两个参数配置相同的值, 其目的在于为了能够在Java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小, 从而提高性能
默认堆空间的大小
- 初始内存大小:物理电脑内存 / 64
- 最大内存大小: 物理内存大小 / 4
查看设置堆空间的参数的详细信息
1
2
3
4
5# 方式一
1> jps
2> jstat -gc pid
#方式二
-XX:PrintGCDetails
2.4.2 年轻代和老年代
储存在JVM中Java对象可以被划分为两类
- 一类是生命周期较短的瞬时对象, 这类对象的创建和消亡都非常迅速
- 另外一类对象的生命周期却非常长, 在某些极端情况下还能够与JVM的生命周期保持一致
Java堆区进一步细分的话, 可以划分为年轻代(YoungGen)和老年代(OldGen)
其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间(有时也叫from区、to区 s0/s1 空的为to区)
配置年轻代和老年代在堆结构的占比
1
-XX:NewRatio=2 表示新生代占1 老年代占2, 新生代占整个堆的1/3
查看默认年轻代和老年代在堆结构的占比
1
2
3
4
5
6
7
8# 显示当前所有java进程pid
jps
# 查看默认年轻代和老年代在堆结构的占比为2(新生代占1.老年代占2)
jinfo -flag NewRatio pid
>>> -XX:NewRatio=2
# 查看Eden空间和另外两个Survivor空间缺省所占的比例(默认Eden空间占8份)
jinfo -flag SurvivorRatio 进程pid
>>> -XX:SurvivorRatio=8在HotSpot中, Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1
可以使用选项-XX:SurvivorRatio调整这个空间比例
几乎所有的Java对象都是在Eden区被new出来的
绝大部分的Java对象的销毁都是在年轻代进行的
可以使用选项-Xmn设置新生代最大内存大小
关于垃圾回收: 频繁的新生区收集, 很少在养老区收集, 几乎不在元空间收集
YGC:年轻代中的垃圾回收器
FGC:老年代中的垃圾回收器
2.4.3 MinorGC(YGC)、MajorGC、 FullGC
JVM在进行GC时, 并非每次都对上面三个内存(新生代、老年代、方法区)区域一起回收, 大部分回收的都是指新生代
针对HotSpot VM的实现, 它里面的GC按照回收区域又分为两大种类型: 一种是部分收集(Partial GC), 一种是整堆收集(Full GC)
- 部分收集: 指目标不是完整收集整个Java堆的垃圾收集
- 新生代收集(Minor GC / Young GC) : 只是新生代(Eden/S0, S1)的垃圾收集
- 老年代收集(Major GC / Old GC) : 只是老年代的垃圾收集
- 目前 , 只有CMS GC会有单独收集老年代的行为
- 注意, 很多时候Major GC会和 Full GC混淆使用, 需要具体分辨是老年代回收还是整堆回收
- 混合收集(Mixed GC) : 收集整个新生代以及部分老年代的垃圾回收
- 目前只有G1 GC会有这种行为
- 整堆收集(Full GC): 收集整个Java堆和方法区的垃圾收集
2.4.3 分代式GC策略的触发条件
年轻代GC(Minor GC)触发机制:
1
2
31> 当年轻代空间不足时, 就会触发Minor GC, 这里的年轻代满指的是Eden满, Survivor满不会引起GC(每次Minor GC会清理年轻代的内存)
2> 因为Java对象大多都具备朝生夕灭的特性, 所以Minor GC非常频繁, 一般回收速度也比较快
3> Minor GC会引发STW(Stop The World), 暂停其他用户的线程, 等待垃圾回收结束, 用户线程才恢复运行老年代(Major GC / Full GC)触发机制:
1
2
3
41> 指发生在老年代的GC, 对象从老年代消失, 即Major GC或者Full GC发生了
2> 出现了Major GC, 经常会伴随至少一次的Minor GC(但非绝对的, 在Parallel Scavenge收集器的收集策略中) 注: 也就是在老年代空间不足时, 会先尝试进行Major GC的策略选择过程触发Minor GC。如果之后空间还不足, 则触发Major GC
3> Major GC的速度一般会比Minor GC慢10倍以上, STW的时间更长
4> 如果Major GC后, 内存还不足, 就报OOMFull GC触发机制
1
2
3
41> 调用System.gc()时, 系统建议执行Full GC, 但是不必然执行
2> 老年代空间不足
3> 方法区空间不足
4> 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
2.4.5 堆空间分代思想
堆分代的唯一理由就是优化GC性能
经研究, 不同的对象的生命周期不同, 70%-90%的对象是临时对象
- 新生代: 有Eden、两块大小相同的Survivor构成, to总为空
- 老年代: 存放新生代中经历多次GC仍然存活的对象
2.4.6 内存分配策略
1 | 如果对象在Eden出生并经过第一次Minor GC后仍然存活, 并且能被Survivor容纳的话, 将被移动到Survivor空间中, 并将对象年龄设为1。对象在Survivor区中没每经过一次Minor GC, 年龄就增加一岁, 当它的年龄增加到一定程度(默认为15岁, 每个JVM, 每个GC都有所不同)时, 就会被晋升到老年代中。 |
优先分配到Eden
大对象直接分配到老年代(尽量避免程序中出现过多的大对象)
长期存活的对象分配到老年代
动态对象年龄判断
- 如果Survivor区中相同年龄的的所有对象大小的总和大于survivor空间的一半, 年龄大于或者等于该年龄的对象可以直接进入老年代, 无须等到MaxTenuringThreshold种要求的年龄
空间分配担保
1
-XX:HandlePromotionFailure(JDK7以后失效了)
2.4.7 TLAB(Thread Local Allocation Buffer)
什么是TLAB?
线程本地分配缓存区
从内存模型而不是垃圾回收的角度, 对Eden区继续进行划分, JVM为每个线程分配了一个私有的缓存区域, 它包含在Eden空间内
多线程同时分配内存时, 使用TLAB可以避免一系列的非线程安全问题, 同时还能够提升内存分配的吞吐量, 因此我们将这种内存的分配方式称之为快速分配策略
为什么需要TLAB
- 堆区是线程共享的区域, 任何线程都可以访问到堆区中的共享数据 由于对象实例的创建在JVM中非常频繁, 因此在并发环境中从堆区化分内存空间是线程不安全的
- 为避免多个线程操作同一地址, 需要使用加锁等机制, 进而影响分配速度
tips:
- 尽管不是所有的对象实例都能够在TLAB中成功分配内存, 但JVM确实是将TLAB作为内存分配的首选
- 在程序中, 可以通过选项
-XX:UseTLAB设置是否开启TLAB空间(JDK8及其之后默认开启) - 默认情况下, TLAB空间的内存非常小, 仅占有整个Eden空间的1%, 可以通过选项
-XX:TLABWasteTargetPercent设置TLAB - 一旦对象在TLAB空间分配内存失败, JVM就会尝试通过使用加锁机制来确保数据操作的原子性, 从而直接在Eden空间中分配内存
2.4.8 堆空间常用参数设置
1 | -XX:+PrintFalgsFinal 查看所有参数的最终值 |
2.4.9 逃逸分析
堆是分配对象存储的唯一选择吗?
随着JIT编译器的发展与逃逸分析技术逐渐成熟, 栈上分配、标量替换优化技术将会导致一些微秒的变化, 所有的对象不一定都分配到堆上
在Java虚拟机中, 对象是在Java堆中分配内存的, 这是一个普遍的常识。但是有一种特殊的情况, 那就是如果经过逃逸分析后发现, 一个对象并没有逃逸出方法的话, 那么就可能会优化成栈上分配, 这样就无需在堆上分配内存, 也无需进行垃圾回收了, 即堆外存储技术
如何将堆上地对象分配到栈上, 需要使用逃逸分析手段
1 | 逃逸分析是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法 |
1 | #逃逸分析的基本行为就是分析对象动态作用域: |
tip: 开发中能使用局部变量的, 就不要使用在方法外定义的变量
1 | #开启逃逸分析 |
2.4.9 .1 标量替换
标量(Scalar) 是指一个无法再分解成更小的数据的数据
Java中原始数据类型就是标量
相对的, 那些还可以分解的数据叫做聚合量
Java中对象就是聚合量
在JIT阶段, 如果经过逃逸分析, 发现一个对象不会被外界访问的话, 那么经过JIT优化, 就会把这个对象拆解成若干个其他成员变量来代替, 这个过程就是标量替换
1 | #标量参数替换设置 |
2.5 方法区
《Java虚拟机规范》说明方法区在逻辑上是属于堆的一部分, 但是对于Java虚拟机的实现之一的HotSpot而言, 方法区还有一个别名叫做Non-Heap(非堆), 目的就是要和堆分开, 所以, 方法区看作是一块独立于Java堆的内存空间
目前, 元空间(Metaspace)是方法区的具体落地实现
- 方法区(Method Area)与堆一样, 是各个先线程共享的区域
- 方法区在JVM启动的时候被创建, 并且它的实际物理内存空间中和Java堆区一样都可以是不连续的
- 方法区的大小和堆空间一样, 可以选择固定大小或者可扩展
- 方法区的大小决定了系统可以保存多少个类, 如果系统定义了太多的类, 导致方法区溢出, 虚拟机同样会抛出内存溢出错误
- 关闭JVM就会释放这个区域的内存
2.5.1 HotSpot中方法区的演进
- 在JDK7及以前, 习惯上把方法区称为永久代。JDK8开始, 使用元空间取代了永久代
- 本质上, 方法区和永久代并不等价。仅是对于HotSpot而言的(HotSpot中永久代就是方法区的实现) ,《Java虚拟机规范》中对于如何实现方法区, 不做统一要求, 例如 BEA JRocket / IBM J9中不存在永久代的概念
- 在JDK8完全废弃了永久代的概念, 改用与JRocket、J9一样在本地内存中实现的元空间(Metaspace)来代替
- 元空间的本质和永久代类似, 都是JVM规范中方法区的实现, 不过元空间与永久代最大的区别在于: 元空间不在虚拟机设置的内存中, 而是使用本地内存
- 永久代、元空间二者并不只是名字变化了, 内部的结构也调整了
- 根据《Java虚拟机规范》的规定, 如果方法区无法满足新的内存分配需求, 将抛出OOM异常
2.5.2 设置方法区大小的参数
1 | # 设置永久代空间的大小 |
1 | # 设置元空间的初始值大小 |
2.5.3 方法区的作用
它用于储存已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等
2.5.3.1 类型信息
对每个加载的类型(类class、接口interface、枚举enum、注解annotation), JVM必须在方法区中存储以下类型信息
- 这个类型的完整有效名称(包名.类名)
- 这个类型直接父类的完整有效名(对于interface和java.lang.Object都没有父类)
- 这个类型的修饰符(public, abstract, final的某个子集)
- 这个类型直接接口的一个有序列表
2.5.3.2 域(Field)信息
- JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序
- 域的相关信息包括: 域名称、域类型、域修饰符(public, private, protected, static, volatile, transient的某个子集)
2.5.3.3 方法(Method)信息
方法名称
方法的返回类型
方法参数的数量和类型
方法的修饰符(public, private, protected, static, final, synchronized, native, abstract的一个子集)
方法的字节码文件、操作数栈、局部变量表及大小(abstract和native方法除外)
异常表(abstract和native方法除外)
1
每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
2.5.3.4 class文件中常量池
一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口描述信息外, 还包含一项信息那就是常量池表(Constant Pool Table), 包含各种字面量和对类型、域和方法的符号引用
一个Java源文件中的类、接口, 编译后产生一个字节码文件, 而Java中的字节码需要数据支持, 通常这种数据会很大以至于不能直接存到字节码里, 换另一种方式, 可以存到常量支持池中, 这个字节码包含了指向常量池的引用, 并在动态链接的时候使用运行时常量池(相当于Maven仓库一样)
常量池可以看做是一张表, 虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型
2.5.3.5 运行时常量池
- class文件中的常量池经过类加载器放到方法区以后就叫做运行时常量池
- 运行时常量池(Runtime Constant Pool) 是方法区的一部分
- 常量池表(Constant Pool Table) 是Class文件的一部分, 用于存放编译期生成的各种字面量与符号引用, 这部分内容将在类加载后存放到方法区的运行时常量池中
- 运行时常量池, 在加载类和接口到虚拟机后, 就会创建对应的运行时常量池
- JVM为每个已加载的类型(类或者接口)都维护一个常量池。池中的数据项像数组项一样, 是通过索引访问的
- 运行时常量池中包含多种不同的常量, 包括编译期就已经明确的数值常量, 也包括到运行期解析后才能够获得的方法或者字段引用, 此时不再是常量池中的符号地址了, 这里换为真实地址
- 运行时常量池具有动态性
- 当创建类或者接口的运行时常量池时, 如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值, JVM将会抛出OOM
2.5.3.6 方法区的演进细节
只有在HotSpot中才有永久代, BEA的JRocket和IBM的J9都是不存在永久代的概念的。原则上如何实现方法区属于虚拟机实现的细节,不受《Java虚拟机规范》管束, 并不要求同一
| JDK6及之前 | 有永久代(permanent generation) , 字符串常量池、 静态变量存放在永久代上 |
|---|---|
| JDK7 | 有永久代, 但是已经逐步”去永久代”, 字符串常量池、静态变量移出, 保存在堆中(永久代仍然使用Java虚拟机内存) |
| JDK8及之后 | 无永久代, 类型信息、方法、字段、常量保存在本地内存的元空间(方法区), 但是字符串常量池、静态变量仍在堆中 |
随着Java8的到来, HotSpot VM中再也见不到了永久代了。但是这并不意味着类的元数据信息也消失了, 这些数据被移到了一个与堆不相连的本地内存区域, 这个区域叫做元空间(Metaspace)
由于类的元数据分配在本地内存中。元空间的最大分配内存空间就是系统可用的内存空间
永久代为什么要被元空间替换?
1 | 1> 为元空间设置空间大小是很难确定的, 在某些场景中, 如果动态加载类过多, 容易产生Perm区的OOM, 而元空间与永久代之间的最大区别在于: 元空间并不在虚拟机中, 而是使用本地内存, 因此, 默认情况下, 元空间的大小仅受本地内内存限制 |
2.5.3.7 方法区的垃圾回收
方法区的垃圾收集主要回收两部分内容: 常量池中废弃的常量和不再使用的类型
方法区内的常量池之中主要存放的两大类常量: 字面量和符号引用。字面量比较接近Java语言层次的常量概念, 如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念, 包括下面三类常量:
- 类和接口的全限定类名
- 字段的名称和描述符
- 方法的名称的描述符
HotSpot VM对常量池的回收策略是很明确的, 只要常量池中的常量没有被任何地方引用, 就可以被回收
回收废弃常量与回收Java堆中的对象非常类似
判断一个常量是否”废弃”还是相对简单, 而要判定一个类型是否”不再被使用的类”的条件就比较苛刻了:
- 该类的所有实例都已经被回收, 也就是Java堆中不存在该类及其任何派生类的实例
- 加载该类的类加载已经被回收, 这个条件除非是经过精心设计的可替换类加载器的场景, 如OSGI、JSP的重加载等, 否者是很难达成的
- 该类对应的java.lang.Class对象没有在任何地方被引用, 无法在任何地方通过反射方法访问该类的方法
Java虚拟机被允许对满足以上三个条件的无用类进行回收, 这里说的仅仅是”被允许”而并不是和对象一样, 没有了引用就必然会回收
在大量使用反射、动态代理、CGLib等字节码框架, 动态生成JSP以及OSGI这类频繁自定义类加载器的场景中, 通常都需要Java虚拟机具备类型卸载的能力, 以保证不会对方法区造成大的内存压力
2.5.3.8 字符串常量池的位置为什么要调整?
JDK7中将StringTable放到了堆空间中。因为永久代的回收效率很低, 在full gc时才会触发。而full gc是老年代的空间不足、永久代不足时才会触发, 这就导致StringTable回收效率不高, 而我们开发中会有大量的字符串被创建, 回收效率低, 导致永久代内存不足。放到堆里, 能够及时回收内存。
2.6 对象的创建
2.6.1 判断对象对应的类是否加载、链接、初始化
1 | 虚拟机遇到一条new指令。首先去检查这个指令的参数是否在Metaspace的常量池中定位到一个类的符号引用, 并且检查这个符号引用代表的类是否已经被加载、解析和初始化(即判断类元信息是否存在)。如果没有, 那么在双亲委派模式下, 使用当前类加载器ClassLoader+包名+类名为key进行查找对应的.class文件。如果没有文件,则抛出ClassNotFoundException异常, 如果找到, 则进行类加载, 并生成对应的Class类对象 |
2.6.2 为对象分配内
首先计算对象占用空间大小,接着在堆中划分一块内存给新对象,如果实例成员变量是引用变量,仅分配引用变量空间即可, 即4个字节大小
- 如果内存是规整的, 那么虚拟机将采用的是指针碰撞法(Bump The Pointer)来分配内存
1 | 指针碰撞法: 所有用过的内存在一边, 空闲的内存在另外一边, 中间放着一个指针作为分界点的指示器, 分配内存仅仅是把指针向空闲那边挪动一段与对象大小相等的距离罢了.如果垃圾收集器选择的是Serial, ParNew这种基于压缩算法的, 虚拟机采用这分配方式, 一般使用带有compact(整理)过程的收集器时, 使用指针碰撞. |
- 如果内存是不规整的, 虚拟机需要维护一个列表
1 | 如果内存不是规整的, 已使用的内存和未使用的内存相互交错, 那么虚拟机将采用的是空闲列表法来为对象分配内存 |
2.6.3 处理并发安全问题
- 采用CAS失败重试, 区域加锁保证更新的原子性
- 每个线程预先分配一块TLAB
2.6.4 初始化分配到的空间
所有属性设置默认值, 保证对象实例字段在不赋值时可以直接使用
- 属性的默认初始化
2.6.5 设置对象的对象头
将对象的所属类(即类的元数据信息), 对象hashCode和对象的GC信息, 锁信息等数据存储在对象的对象头中, 这个过程的具体设置方式取决于JVM实现
2.6.6 执行init方法进行初始化
1 | 在Java程序的视角看, 初始化才正式开始,初始化成员变量, 执行实例化代码块, 调用类的构造方法, 并把堆内对象的首地址赋值给引用变量. 因此一般来说(由字节码中是否跟随有invokespecial指令所决定), new指令之后会接着执行方法, 把对象按照程序员的意愿进行初始化, 这样一个真正可用的对象才算完全创建出来 |
- 显示初始化
- 代码块中的初始化
- 构造器中初始化
2.7 对象的内存布局
2.7.1对象头(Header)
- 运行时元数据(Mark Word)
- 哈希值
- GC分代年龄
- 锁状态标志(3位)
- 是否上锁
- 轻量级锁
- 重量级锁
- 是否被GC标记
- 是否偏向
- Lock Record Address
- 轻量级锁(指向栈中的锁记录)
- 检查Mark Word是否指向当前线程的栈
- Monitor Address
- Forwarding Address
- 线程持有的锁
- 偏向线程ID
- 偏向时间戳
- 类型指针: 指向类元数据InstanceClass, 确定该对象所属的类型(指向方法区对象数据类型的指针)
- 如果是数组, 还需记录数组的长度
2.7. 2 实例数据 (Instance Data)
它是对象真正存储的有效信息, 包括程序代码中定义的各种类型的字段(包括从父类继承下来的本身拥有的字段)
规则:
- 相同宽度的字段总是被分配在一起
- 父类中定义的变量会出现在子类之前
- 如果CompactFields参数为true(默认为true): 子类的窄变量可能插入到父类变量的空隙
2.7.3 对齐填充(Padding)
不是必须的, 也没有特别的含义, 仅仅起到占位符的作用
由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍, 即任何对象的大小都必须是8字节的整数倍, 如果对象实例数据部分没有对其的话, 就要通过字节填齐来补全
2.7.4 工具: JOL = Java Object Layout
1 | <dependencies> |
1 | public class ObjectLayout { |
前两个object header 为markword占用8个字节, 第三个object header 为类型指针(class pointer) 占用4个字节
1 | java.lang.Object object internals: |
2.7.5 关闭指针压缩
-XX:+PrintCommandLineFlags -version: 打印HotSpotVM 采用的自动优化参数
-XX:+UseCompressedClassPointers: 开启类指针压缩
-XX:+UseCompressedOops: 开启普通对象指针压缩
Java中默认开启指针压缩, 使用虚拟机参数-XX:-UseCompressedClassPointers来关闭此选项。 关闭后类型指针(class pointer)占用8个字节, 即第三个和第四个object header
1 | java.lang.Object object internals: |
2.8 对象访问定位
访问对象的方式主要有两种:
- 句柄访问
1 | 句柄访问的缺点: 1> 需要在内存中开辟额外的空间供句柄池存储数据 2> 访问对象需要经过多次地址寻址 |
- 直接指针(HotSpot采用)
使用直接指针来访问最大的好处就是速度更快,它节省了一次指针定位的时间开销
2.9 直接内存(堆外内存)
- 直接内存不是虚拟机运行时数据区的一部分, 也不是《Java虚拟机规范》中定义的内存区域
- 直接内存是Java堆外的、直接向系统申请的内存空间
- 来源于NIO, 通过存在堆中的DirectByteBuffer操作Native内存
- 通常访问直接内存的速度会优先于Java堆, 即读写性能高
- 出于性能考虑, 读写频繁的场所可能会考虑使用直接内存
- Java的NIO库允许Java程序使用直接内存, 用于数据缓冲
- 直接内存也会出现OOM
- Java中使用DirectByteBuffer类来操作直接内存
- 由于直接内存在Java堆外, 因此它的大小不会直接受限于
-Xmx指定的最大堆大小, 但是系统内存是有限的, Java堆和直接内存的总和依然受限于操作系统能给出的最大内存 - 直接内存的缺点:
- 分配回收成本较高
- 不受JVM内存回收管理
- 直接内存大小可以通过
-XX:MaxDirectMemorySize设置 - 如果不指定, 默认与堆的最大值
-Xmx参数值保持一致
2.10 Java内存状况分析
1 | jconsole |
3 执行引擎
执行引擎是Java虚拟机核心的组成部分之一
“虚拟机”是一个相对于”物理机”的概念, 这两种机器都有代码执行的能力, 其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面的, 而虚拟机的执行引擎则是由软件自行实现的, 因此可以不受物理条件制约地定制指令集与执行引擎的结构体系, 能够执行那些不被硬件直接支持的指令集格式
JVM的主要任务是负责装载字节码到其内部, 但是字节码并不能够直接运行在操作系统上, 因为字节码指令并非等价于本地机器指令, 它内部包含的仅仅只是一些能够被JVM所识别的字节码指令、符号表以及其他辅助信息,而执行引擎(Execution Engine)的主要任务就是将字节码指令解释/编译为对应平台上的本地机器指令才可以, JVM中的执行引擎充当了将高级语言翻译为机器语言的译者
3.1 执行引擎的工作过程
- 执行引擎在执行过程中执行的字节码指令完全依赖于PC寄存器
- 每当执行完一项指令操作后, PC寄存器就会更新下一条需要被执行的指令地址
- 当然方法在执行的过程中, 执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到储存在Java堆中的对象实例信息, 以及通过对象头中的元数据指针定位到目标对象的类型信息
- 所有的Java虚拟机的执行引擎输入、输出都是一致的: 输入的是字节码二进制流, 处理过程是字节码解析执行的等效过程, 输出的是执行结果
3.2 Java代码编译和执行过程
- 解释器(Interpreter): 当Java虚拟机启动时会根据预定义的规范对字节码采用逐行解释的方法执行, 将每条字节码文件中的内容”翻译”为对应平台的本地机器指令执行
- JIT(Just In Time Compile) 编译器: 就是虚拟机将源代码直接编译成和本地机器平台相关的机器语言
- Java是半编译半解释型的语言。之前Java仅有解释执行, 后来Java也发展出可以直接生成本地代码的编译器。现在JVM在执行Java代码的时候, 通常都会将解释执行和编译执行二者结合起来进行
3.3 指令&汇编
3.3.1 指令
指令就是把机器码特定的0和1序列, 简化成对应的指令, 由于不同的硬件平台, 执行同一个操作, 对应的机器码可能不同, 所以不同的硬件平台的同一种指令(比如mov), 对应的机器码也可能不同
3.3.2 指令集
不同的硬件平台,各自支持的指令是有差别的,因此每个平台所支持的指令称之为对应平台的指令集
3.3.3 汇编语言
- 由于指令的可读性还是太差,于是产了汇编语言
- 在汇编语言中,使用助记符(Mnemonics)代替机器指令的操作码,用地址符号(Symbol)或者标号(Label)代替指令或者操作数的地址
- 在不同的硬件平台,汇编语言对应着不同的机器语言指令集,通过汇编过程转换成机器指令(由于计算机只认识指令码,所以用汇编语言编写的程序还必须翻译成机器指令码,计算机才能识别和识别)
3.4 JIT编译器
HotSpot VM是目前市面上高性能虚拟机的代表作之一,它采用解释器与即时编译器并存的架构。在Java VM运行的时候,解释器和即时编译器能够相互协作,各自取长补短,尽力去选择最合适的方式来权衡编译本地代码的时间和直接解释执行代码的时间
JRocket VM内部就不含解释器, 字节码全部都依靠即时编译器编译后执行(这就是为什么JRocket VM速度很快的原因)
为什么JIT编译这么快,HotSpot VM仍然使用解释器呢?
当程序启动后,解释器可以马上发挥作用,省去了编译的时间,立即执行。而编译器要想发挥作用,把代码编译成本地代码,需要一定的执行时间,但编译为本地代码,执行效率高
所以尽管JRocket VM中程序的执行性能会非常高效,但是在程序启动时必然需要花费更长的时间来进行编译。对于服务端应用来说,启动并非是关注点,但是对于那些看重启动时间的应用场景而言,或许就需要采用解释器与即时编译并存的架构来换取一个平衡点。在此模式下,当Java虚拟机启动时,解释器可以首先发挥作用,而不必等待即时编译器全部编译完成后再执行,这样可以省去许多不必要的编译时间。随着时间的推移,编译器发挥作用,把越来越多的代码编译成本地代码,获得更高的执行效率
Java语言的”编译期”其实是一段”不确定”的操作过程,因为它可能是指一个前端编译器——把.java文件转变为.class文件的过程,也可能指虚拟机的后端运行期编译器(JIT编译器, Just In Time Compiler)把字节码转变为机器码的过程,还可能是指使用静态提前编译器(AOT编译器 Ahead of Time Compiler)直接把.java文件编译为本地机器代码的过程
JIT编译器: HotSpot VM的 C1、 C2编译器
AOT编译器: GNU Compiler for Java(GCJ)、 Excelsior JET
3.4.1 热点代码及探测方式
是否需要启动JIT编译器将字节码直接编译为对应平台的本地机器指令,则需要根据代码被调用执行频率而定。那些需要被编译为本地代码的字节码,也被称之为”热点代码”,JIT编译器在运行时会针对那些频繁被调用的”热点代码”, JIT编译器在运行时会针对那些频繁被调用的”热点代码”做出深度优化,将其直接编译为对应平台德玩本地机器指令,以此提升Java程序执行性能
- 一个被多次调用的方法,或者是一个方法体内部循环次数较多的循环体都可以被称之为”热点代码”,因此都可以通过JIT编译器编译为本地机器指令。由于这种编译方式发生在方法的执行过程中,因此也被称为栈上替换,简称为OSR(On Stack Replacement)编译
- HotSpot VM采用的热点探测方式是基于计数器的热点探测
- 采用基于计数器的热点探测,HotSpot VM将会为每一个方法都建立2个不同类型的计数器,分别为方法调用计数器(Invocation Counter)和回边计数器(Back Edge)
- 方法调用计数器用于统计方法的调用次数
- 回边计数器则用于统计循环体执行的循环次数
- 方法调用计数器
1 | # 热度衰减 |
1 | - 如果不做任何设置,方法调用计数器统计的并不是方法被调用的绝对次数,而是一个相对的执行频率,即一段时间之内方法被调用的次数,当超过一定的时间限度,如果方法的调用次数仍然不足以让它提交给即时编译器编译,那么这个方法的调用计数器就会被减少一半,这个过程称之为方法调用计数器热度的衰减(Counter Decay),而这段时间就称为此方法统计的半衰周期(Counter Half Life Time) |
- 回边计数器: 它的作用是统计一个方法中循环体代码执行的次数,在字节码中遇到控制流向跳转的指令称为”回边”(Back Edge)。建立回边计数器的目的就是为了触发OSR编译
3.5 执行模式 & C1、C2编译器
3.5.1 设置HotSpot的执行模式
1 | # 开启解释执行模式 |
3.5.2 HotSpot VM中JIT分类
在HotSpot VM中内嵌有两个JIT编译器, 分别为Client Compile和Server Compile, 但大多数情况下简称为C1编译器和C2编译器
- -client: 指定Java虚拟机运行在Client模式下, 并使用C1编译器(#C1编译器对字节码进行简单和可靠的优化, 耗时短, 以达到更快的编译速度)
- -server: 指定Java虚拟机运行在Server模式下, 并使用C2编译器(#C2进行耗时较长的优化, 以及激进优化, 但优化的代码执行效率更高)
3.5.3 C1和C2编译器不同的优化策略
- C1编译器上主要有方法内联、去虚拟化、冗余消除
1 | - 方法内联: 将引用的函数代码编译到引用点处, 这样可以减少栈帧的生成, 减少参数传递以及跳转的过程 |
- C2的优化主要是在全局层面, 逃逸分析是优化的基础
1 | - 标量替换: 用标量值代替聚合对象的属性值 |
一般来说,JIT编译出的机器码性能比解释器高,C2编译器启动时长比C1编译器慢,系统稳定执行后,C2编译器执行速度远远快于C1编译器
3.6 Graal & AOT编译器
自JDK10起, HotSpot加入了一个全新的即时编译器: Graal编译器
1 | # 激活Graal的虚拟机参数 |
JDK9引入了AOT编译器(静态提前编译器, Ahead Of Compiler)
JDK9引入了实验性AOT编译工具jaotc 它借助了Graal编译器, 将所输入的Java类文件转换为机器码, 并存放至生成的动态共享库之中
所谓的AOT编译, 是与即使编译相对立的一个概念 即时编译是指在程序运行过程中将字节码转换为可在硬件上直接运行的机器码, 并部署至托管环境中的过程。 而AOT编译指的是在程序运行之前, 便将字节码转换为机器码的过程
优点:
- Java虚拟机加载已经预编译成二进制库, 可以直接运行, 不必等待即使编译器的预热
缺点:
- 破坏了Java一次编译, 到处运行的特点,必须为每个不同硬件、OS编译对应的发行包
- 降低了Java链接过程中的动态性, 加载的代码在编译期就必须全部已知
- 还需要持续优化中,最初只支持Linux x64 java base
4 String的基本特性
- 字符串常量池中是不会储存相同内容的字符串
- 字符串常量池存储在堆中(jdk8及其之后), 而jdk7及其之前是存储在永久代中
- String 的String Pool是一个固定大小的Hashtable,如果放进String Pool的String非常多,就会造成Hash冲突严重,从而导致链表会很长,而链表很长会直接造成的影响就是当调用String.intern()时性能下降
- 可以使用
-XX:StingTableSize设置StringTable的长度 - uintx StringTableSize=10 is outside the allowed range [ 128 … 16777216 ]
1 | # 默认字符串常池的大小(JDK12) |
Java语言规范里要求完全相同的字符串常量, 应该包含同样的Unicode字符序列(包含同一份码点序列的常量), 并且必须是指向同一个String类实例
4.1 intern() 的总结
- JDK6中, 将这个字符串对象尝试放入到串池中。如果串池中没有,则并不会放入,返回已有的串池中对象的地址。如果没有会把此对象复制一份放入串池,并返回串池中的对象地址
- JDK7起,将这个字符串对象尝试放入到串池。如果串池中有,则并不会放入。返回已有的串池中的对象地址。如果没有则会把对象的引用地址复制一份,放入串池,并返回串池中的引用地址
1 | # -Xlog:gc* 代替 -XX:+PrintGCDetails |
5 垃圾回收
什么是垃圾?
垃圾是指在运行程序中没有任何指针指向的对象
5.1 垃圾标记阶段
- 在堆中存放着几乎所有的Java对象实例,在GC执行垃圾回收之前,首先需要区分出内存中哪些是存活对象,哪些是已经死亡的对象,只有被标记为已经死亡的对象,GC才会在执行垃圾回收时,释放掉其所占有的内存空间,因此这个过程可以成为垃圾回收阶段
- 当一个对象已经不再被任何的存活对象继续引用时,就可以宣告为已经死亡
- 判断对象存活一般有两种方式: 引用计数算法和可达性分析算法
5.1.1 引用计数算法(标记阶段)
- 引用计数算法(Reference Counting)对每个对象保存一个整型的引用计数器属性,用于记录对象被引用的情况
- 优点: 实现简单,垃圾对象便于辨识; 判定效率高, 回收没有延迟性
- 缺点:
- 它需要单独的字段储存计数器,这样的做法增加了储存开销
- 每次赋值都需要更新计数器,伴随着加法和减法操作,这增加了时间开销
- 引用计数器有一个严重的问题,即无法处理循环引用的情况,导致在Java的垃圾回收器中没有使用这类算法
5.1.2 标记-清除算法(清除阶段)
最早出现也是最基础的算法(Mark - Sweep) 于1960年由Lisp之父John McCarthy提出
分为两个阶段: 首先标记出需要回收的对象,在标记完成后,统一回收掉所有被标记的对象,也可以反过来,标记存活的对象,统一回收所有未被标记的对象 标记过程就是对象是否属于垃圾的判定过程
5.1.3 可达性分析算法(根搜索算法、追踪性垃圾收集)(标记阶段)
- 相对于引用计数算法而言,可达性分析算法不仅同样具备实现简单和执行高效等特点, 更重要的是该算法可以有效解决在引用计数算法中循环引用的问题,防止内存泄漏的发生
5.2 GC Roots
在Java语言中, GC Roots包括以下几类元素
- 虚拟机栈中引用的对象: 各个线程被调用的方法中使用到的参数、局部变量、临时变量等
- 本地方法栈内JNI引用的对象
- 方法区中类静态属性引用的对象 比如Java类的引用类型静态变量
- 方法区中常量引用的对象 比如字符串常量池里的引用
- 所有被同步锁synchronized持有的对象
- Java虚拟机内部的引用: 基本数据类型对应的Class对象,一些常驻的异常对象(NullPointerException、OutOfMemoryError), 系统类加载器
- 反映java虚拟机内部的JMXBean、JVM中注册的回调、本地代码缓存等
- 如果要使用可达性分析算法来判断内存是否可以回收, 那么分析工必须在一个能保障一致性的快照中进行 这点不满足的话分析结果的准确性就无法保证
除了固定的GC Roots集合以外 还可以有其他对象临时性地加入 比如 分代收集和局部回收(Partial GC)
5.3 对象的finalization机制
Java语言提供了对象终止机制来允许开发人员提供对象被销毁之前的自定义处理逻辑
- 当垃圾回收器发现没有引用指向一个对象 即垃圾回收此对象之前 总会先调用这个对象的finalize()方法
- finalize()方法允许在子类中被重写 用于在对象被回收时进行资源释放
永远不要主动调用某个对象的finalize()方法 应该交给垃圾回收机制调用
- 在finalize()时可能会导致对象复活
- finalize() 方法的执行时间是没有保障的 他完全由GC线程决定 极端情况下 若不发生GC 则finalize()方法将没有执行机会
- 一个糟糕的finalize()会严重影响GC的性能
Java虚拟机中的对象可能的三种状态
- 可触及的: 从根节点开始 可以到达这个对象
- 可复活的: 对象的所有引用都被释放 但是对象有可能在finalize()中复活
- 不可触及的: 对象的finalize()被调用 并且没有复活 那么就会进入不可触及状态 不可触及的对象不可能被复活 因为finalize()方法只会被调用一次
一个无法触及的对象有可能在某一个条件下复活自己
判断一个对象是否可回收 至少要经历两次标记过程
- 如果对象到GC Roots没有引用链 则进行第一次标记
- 进行筛选 判断此对象是否有必要执行finalize() 方法
- 如果对象没有重写finalize方法 或者finalize方法已经被虚拟机调用过了 则虚拟机认为该对象没有必要执行finalize方法 此对象被判定为不可触及的
- 如果对象重写了finalize方法且还未执行过 那么 对象都被插入到F-Queue队列中: 由虚拟机自动创建的、低优先级的Finalizer线程触发其finalize方法执行
- finalize方法是对象逃脱死亡的最后机会, 稍后GC会对F-Queue队列中的对象进行第二次标记 如果对象在finalize方法中与引用链上的任何一个对象建立了联系 那么在第二次标记时 对象会被移除”即将回收”集合 之后 若对象再次出现没有引用存在的情况 在这个情况下 finalize方法不会被再次调用 对象会直接变成不可触及的状态 也就是说 一个对象的finalize方法只会被调用一次
目前在JVM中比较常见的三种垃圾回收算法是标记清除算法(Mark-Sweep)、复制算法(Copying)、标记压缩算法(Mark-Compact)
5.4 垃圾清除阶段
5.4.1 标记清除算法(Mark-Sweep)
执行过程: 当堆中的有效内存空间被耗尽时 就会停止整个程序(STW) 然后进行两项工作 第一项是标记 第二项则是清除
- 标记: Collector从引用根节点开始遍历 标记所有被引用的对象 一般是在对象的Header中记录为可达对象
- 清除: Collector对堆内存从头到尾进行线性的遍历 如果发现某个对象在其Header中没有标记为可达对象 则将其回收
缺点:
- 效率不算高
- 在进行GC的时候 需要停止整个应用程序
- 这种方式清理出来的空闲内存是不连续的, 产生内存碎片 需要维护一个空闲列表
何为清除:
- 所谓的清除并不是真的置空 而是把需要清除的对象地址保存在空闲的地址列表里 下次有新对象需要加载时 判断垃圾的位置空间是否够用 如果够用直接覆盖
5.4.2 复制算法(Copying)
核心思想
将活着的内存空间分为两块 每次只使用其中一块 在垃圾回收时将正在使用的内存中存活的对象赋值到未被使用的内存中 之后清除正在使用的内存块的所有对象 交换两个内存的角色 最后完成垃圾回收
优点
- 没有标记和清除过程 实现简单 运行高效
- 可以保证空间的连续性 不会出现碎片问题
缺点
- 需要两倍的内存空间
- 对于G1这种拆分成大量region的GC 复制而不是移动 意味着GC需要维护region之间对象引用的关系 不管是内存占用或者是时间开销也不小
如果系统中的非垃圾对象很多 那么复制算法会复制很多存活的对象 代价很大
应用场景
在新生代 对常规应用的垃圾回收 一次通常可以回收70%-99%的内存空间 回收性价比很高
5.4.3 标记-压缩(标记-整理 Mark-Compact) 算法
背景
复制算法的高效性是建立在存活对象少、垃圾对象多的前提下 这种情况下新生代经常发生 但是在老年代中 更常见的情况是大部分对象都是存活对象 如果依然使用复制算法 由于存活对象较多 复制的成本也将很高 因此 基于老年代垃圾回收的特性 需要使用其他的算法
执行过程
第一阶段和标记清除-算法一样 从根节点开始标记所有被引用对象
第二阶段将所有的存活对象压缩到内存的一端 按顺序排放 之后清除边界外所有的空间
优点
- 消除了标记-清除算法当中 内存区域分散的缺点 再给新对象分配内存时 JVM只需持有一个内存的起始地址即可
- 消除了复制算法中 内存减半的高额代价
缺点
- 从效率上来说 标记-整理算法要低于复制算法
- 移动对象的同时 如果对象被其他对象引用 则还需调整引用的地址
- 移动过程中 需要全程暂停用户应用程序(STW)
| / | Mark-Sweep | Mark-Compact | Copying |
|---|---|---|---|
| 速度 | 中等 | 最慢 | 最快 |
| 空间开销 | 少(但会堆积碎片) | 少(不堆积碎片) | 通常需要存活对象的2倍大小(不堆积碎片) |
| 移动对象 | 否 | 否 | 否 |
5.5 分代收集算法
5.6 增量收集算法
基本思想
如果一次将所有的垃圾进行处理 需要造成系统长时间的停顿 那么就可以让垃圾回收线程和应用程序交替执行 每次 垃圾回收只会收集一小片区域的内存空间 接着切换到应用程序线程 来回切换 直到垃圾回收完成
增量收集算法的基础仍然是传统的标记-清除和复制算法 增量收集算法通过对线程间冲突的妥善处理 允许垃圾收集线程以分阶段的方式完成标记、清理和复制工作
缺点
使用这种方式 由于在垃圾回收过程中 间断性地还执行了应用程序代码 所以能够减少系统的停顿时间 但是 因为线程切换和上下文转换的消耗 会使得垃圾回收的总体成本上升 造成系统的吞吐量的下降
5.7 分区算法
一般来说 在相同条件下 对空间越大 一次GC时需要的时间就越长 有关GC产生的停顿也越长 为了更好地控制GC产生的停顿时间 将一块大的内存区域分割成多个小块 根据目标的停顿时间 每次合理地回收若干个小区间 而不是整个堆空间 从而减少一次GC所产生地停顿
分代算法将按照对象的生命周期长短划分为两个部分 分区算法将整个堆空间划分成连续的不同小区间region
每一个小区间都独立使用、独立回收 这种算法的好处是可以控制一次回收多少个小区间
5.8 System.gc()
在默认情况下 通过System.gc() 或者Runtime.getRuntime().gc()的调用 会显示触发Full GC 同时对老年代和新生代进行回收 尝试释放被丢弃对象占用的内存
然而System.gc() 无法保证对垃圾收集器的调用
5.9 内存溢出
内存溢出(OOM): 没有内存空间 并且垃圾收集器也无法提供更过内存
在抛出OutOfMemoryError之前 通常垃圾回收器会被触发 当然也不是在任何情况下垃圾回收器都会被触发 当分配一个超大数组且超过堆的最大值时 JVM可以判断出垃圾回收器并不能解决这个问题 所以直接抛出OOM
5.10 内存泄漏
举例
- 单例模式 单例的生命周期和应用程序是一样的 如果持有对外部对象的引用的话 那么这个对象是不能被回收的 会导致内存泄漏的产生
- 一些提供close的资源未关闭导致的内存泄漏 比如数据库连接 网络连接 或者io连接必须手动close
5.11 垃圾收集器
5.11.1 Serial 收集器
一个单线程工作的收集器
单线程的意义并不仅仅是说明它只会使用一个处理器或一条收集线程去完成垃圾收集工作 更重要的是强调在它进行垃圾收集时 必须暂停其他所有工作的线程 直到它收集结束
5.11.2 ParNew 收集器
实质上是Serial 收集器的多线程并行版本
5.11.3 Parallel Scavenge 收集器
Parallel Scavenge也是一款新生代收集器 同样是基于标记-复制算法实现的收集器 也是能够并行收集的多线程收集器
Parallel Scavenge的特点是它的关注点和其他收集器不同 CMS等收集器的关注点是尽可能地缩短垃圾回收时用户线程的停顿时间 而Parallel Scavenge 收集器的目标则是达到一个可控的吞吐量(Throughput) 所谓的吞吐量就是运行用户代码的时间与处理器总消耗时间(运行用户代码时间 + 运行垃圾收集时间)的比值
5.11.4 Serial Old 收集器
Serial Old 是Serial收集器的老年代版本 同样是一个单线程收集器 使用标记整理算法
这个收集器的主要意义也是供客户端模式下的HotSpot 虚拟机使用
如果在服务端模式下 也可能有两种用途
- 一种是在JDK 5 以及之前的版本中与Parallel Scavenge 收集器搭配使用
- 另外一种就是作为 CMS收集器发生失败时的后备预案 在并发收集时发生Concurrent Mode Failure时使用
5.11.5 Parallel Old 收集器
Parallel Old 是Parallel Scavenge 收集器的老年代版本 支持多线程并行收集 基于标记-整理算法实现
JDK6 时提供
5.11.6 CMS 收集器
CMS(Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器
CMS 收集器基于标记-清除算法实现的 整个过程分为四个步骤
- 初始标记
- 并发标记
- 重新标记
- 并发清除
初始标记和重新标记需要STW
初始标记仅仅只是标记一下GC Roots能直接关联到的对象 速度很快
并发标记阶段就是从GC Roots直接关联的对象开始遍历整个对象图的过程
5.11.7 Garbage First 收集器
简称G1 收集器是垃圾收集器技术发展历史上的里程碑式的成果