深入理解Java虚拟机

最常见的new对象

变形：Xxx的静态方法

变形：XxxBuilder/XxxFactory的静态方法

反射的方式，只能调用空参的构造方法，权限必须时public

反射的方式，可以调用空参、带参的构造方法，权限没有要求

不调用任何构造器，当前类需要实现Cloneable接口，实现clone()

从文件总、从网络中获取一个对象的二进制流

如果内存规整

如果内存不规整

采用CAS配上失败重试保证更新的原子性

每个线程预先分配一块TLAB

所有属性设置默认值，保证对象实例字段在不赋值时可以直接使用

哈希值（hashCode）

GC分代年龄（年龄计数器）

锁标志状态

线程持有的锁

偏向线程ID

偏向时间戳

指向元数据InstanceKlass，确定该对象所属类型

如果是数组，还需记录数组的长度

它是对象真正存储的有效信息，包括程序代码中定义的各种类型的字段（包括从父类继承下来的和本身拥有的字段）

相同宽度的字段总是被分配在一起

父类中定义的变量会出现在子类之前

如果CompactFields参数为true（默认为true）：子类的窄变量可能插入到父类变量的空隙

栈帧指向句柄池，句柄池中的到对象实例数据的指针指向实例池内的对象实例数据，拿到对象实例数据后返回句柄池再重新指向方法区

优缺点

指针直接指向堆中的对象实例，由对象实例数据指针再指向方法区

优缺点

强引用类型

Vector v=new Vector();v就是新建向量对象的reference;

因此出于性能考虑，读写频繁的场合可能会考虑使用直接内存

Java的NIO库允许Java程序使用直接内存，用于数据缓冲区

流程

读写文件，需要与磁盘交互，需要由用户态切换至内核态。再内核态时，需要内存发生读写

这里需要两份内存存储重复数据，效率低

流程

使用NIO时，操作系统划出了直接缓存区可以被Java代码直接访问，只有一份

NIO适合对大文件的读写操作

概念

基本思路

优缺点

如何解决循环引用问题

概念

GC Roots

基本思路

注意

Java语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑

当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize()方法

finalize()方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如：关闭文件、套接字和数据库连接等

finalize()方法只能被调用一次，GC或自己调用

在finalize()时可能会导致对象复活

finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，若不发生GC，则finalize()方法将没有执行机会

一个糟糕的finalize()方法会严重影响GC性能

如果从所有的根节点都无法访问到某个对象，说明对象已经不再使用了。一般来说，此对象需要被回收。但事实上，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段。一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它的回收就是不合理的，为此，定义虚拟机中的对象可能的三种状态，如下：

可达的

可复活的

不可达的

如果对象objA到GC Roots没有引用链，则进行第一次标记

进行筛选，判断此对象是否有必要执行finalize()方法

如果对象objA没有重写finalize()方法，或者finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA被判定为不可触及的

如果对象objA重写了finalize()方法，且还未执行过，那么objA会被插入到F-Queue对象中，有一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize()方法执行

finalize()方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会溢出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize()方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize()方法指挥被调用一次。

当堆中的有效内存空间被耗尽的时候，就会停止整个程序（也被称为Stop the world），然后进行两项工作，第一项则是标记，第二项则是清除

标记

清除

效率不算高

在进行GC的时候，需要停止整个应用程序，导致用户体验差

这种方式清理出来的空闲内存是不连续的，产生内存碎片。需要维护一个空闲列表

这里所谓的清除并不是真的置空，而是把需要清除的对象地址在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放。

将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收

优点

缺点

特别点

在新生代，对常规应用的垃圾回收，一次通常可以回收70%~99%的内存空间。回收性价比很高。所以现在的商业虚拟机都是用这种收集算法回收新生代

标记压缩算法的最终结果等同于标记清除算法执行完成后，再进行一次整理内存碎片的过程

第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象

第二阶段将所有的存活对象压缩到内存的一端，按顺序排放

之后，清理边界所有的空间

可以看到，标记的存活对象将会被整理，按照内存地址一次排序，而未被标记的内存会被整理掉。如此依赖，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了很多开销

二者本质的差异在于标记清除算法是一种非移动式的回收算法，标记压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策

如果内存空间以规整和有序的方式分布，即已用和未用的内存都各自一边，彼此之间维系着一个记录下一次分配起始点的标记指针，当为新对象分配内存时，只需要通过修改指针的偏移量将新对象分配在第一个空闲内存位置上，这种分配方式就叫做指针碰撞（Bump the Pointer）

优点

缺点

速度

空间开销

移动对象

速度

空间开销

移动对象

速度

空间开销

移动对象

在HotSpot中，基于分代的概念，GC所使用的内存回收算法必须结合年轻代和老年代各自的特点

特点

算法选型

特点

以HotStop中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对象的回收频率很高。而对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收期作为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），采用Serial Old执行Full GC以达到对老年代内存的整理

如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成

总的来说，增量收集算法的基础仍是传统的标记清除和复制算法。增量收集算法通过对线程间冲突的妥善管理，允许垃圾收集线程以分阶段的方法完成标记清除或复制工作

使用这种方式，由于在垃圾回收过程中，间断性地还执行了引用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降

一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。为了更好的控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干小区间，而不是整个堆空间，从而减少一次GC所产生地停顿

分区算法将整个堆空间划分成连续的不同小区间，每一个小区间都独立使用，独立回收。这种算法的好处是控制一次回收多少个小区间

在默认情况下，通过System.gc()或者Runtime.getRuntime().gc()的调用，会显示触发Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存

然而System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用

性能基准

概述

概述

注意

内存泄漏的例子

简称STM，指的是GC事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，整个停顿成为Stop the world

可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿

分析工作必须再一个能保证一致性的快照中进行

一致性指整个执行系统看起来像被冻结在某个时间点上

如果出现分析过程中对象应用关系还在持续不断变化，则分析结果的准确性无法保证

被STW中断的应用程序线程会在完成GC之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以我们需要减少STW的发生

STW是JVM在后台发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉

STW事件和采用那款GC无关，所有GC都有这个事件

哪怕时G1也不能完全避免STW的发生，只能说垃圾回收器越来越优秀，回收效率越高，尽可能缩短了暂停时间

开发中不要使用System.gc()；会导致STW的发生

CPU把一个时间段划分成几个时间片，然后在这几个时间片快速的切换并交替执行

并发，指的是多个事情，在同一时间段内同时发生了

并发的多个任何之间是相互抢占资源的

一个CPU对应执行一个线程，不存在抢占CPU时间片的事件

并行，指的是多个事件，在同一个时间点上同时发生了

并行的多个任务之间是不互相抢占资源的

垃圾回收之并行

垃圾回收之串行

垃圾回收之并发

程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置成为“安全点（Safepoint）”

安全点的选择很重要，如果太少则可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都是非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。比如：选择一些执行时间较长的指令作为Safe Point，如方法调用、循环跳转和异常跳转等

中断

SafePoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？例如线程处于Sleep状态或Blocked状态，这时候线程无法响应JVM的中断请求，“走”到安全点去中断挂起，JVM也不太可能等待线程被唤醒。对于这种情况，就需要安全区域（Safe Region）来解决

安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的SafePoint

当线程运行到SafeRegion的代码时，首先标识已经进入SafeRegion，如果这段时间内发生了GC，JVM会忽略标识为SafeRegion状态的线程

当线程即将离开SafeRegion时，会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开SafeRegion的信号为止

概述

特点

概述

场景

使用

概述

场景

使用

虚引用与弱引用的不同点

概述

场景

使用

运行用户代码的时间占总运行时间的比例（总运行时间：程序的运行时间+内存回收的时间）

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）

比如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那么吞吐量就是99%

这种情况下，应用程序能容忍较高的暂停时间，因此，高吞吐量的引用程序有更长的时间基准，快速响应是不必考虑的

吞吐量优先，意味着在单位时间内，STW的时间最短

吞吐量的补救，垃圾收集所用时间与总运行时间的比例

执行垃圾收集时，程序的工作线程被暂停的时间

相对于应用程序的执行，收集操作发生的频率

Java堆区所占的内存大小

一个对象从诞生到被回收所经历的时间

在最大吞吐量优先的情况下，降低停顿时间

串行

并行

并发

新生代收集器

老年代收集器

整堆收集器

分类

作用位置

使用算法

特点

使用场景

分类

作用位置

使用算法

特点

使用场景

分类

作用位置

使用算法

特点

使用场景

分类

作用位置

使用算法

特点

使用场景

分类

作用位置

使用算法

特点

使用场景

分类

作用位置

使用算法

特点

使用场景

分类

作用位置

使用算法

特点

使用场景

双亲委派机制

沙箱安全机制

分类

确保Class文件的字节流中包含信息符合虚拟机要求

文件格式验证

元数据验证

字节码验证

符号引用验证

为类变量分配内存并且设置该类的默认初始值

注意

将常量池内的符号引用转换为直接引用

随着方法的调用，对应方法的栈帧压栈，随着方法的结束，栈帧出栈

注意

局部变量表

操作数栈（表达式栈）

桢数据区

与虚拟机栈结构相同，不同点为执行native方法

虚拟机栈要想知道下一步执行哪个执行，要靠PC寄存器来存储下一条指令的地址

程序控制中的分支、循环、跳转、异常处理、线程恢复等功能都依赖于PC寄存器

靠执行引擎来读取下一条指令地址

是唯一一个Java虚拟机中没有任何OOM的组件

新生代

老年代

混合回收（Mixed GC）

整堆回收（Full GC）

内存分配策略

字符串常量池（版本差异）

静态变量（版本差异）

永久代

元空间

方法区存储内容

方法区的垃圾回收

将字节码指令解释/编译为对应平台上的本地机器指令

简单来说，JVM中执行引擎充当了将高级语言翻译为机器语言的译者

执行引擎再执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器

每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址

当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及对对象头中的元数据指针定位到目标对象的类型信息

从外观上来看，所有的Java虚拟机的执行引擎输入、输出都是一致的：输入的时字节码二级制流，处理过程是字节码解释执行的等效过程，输出的是执行结果

程序源码 - > 词法分析 - > 单词流 - > 语法分析 - > 抽象语法树 - > 指令流（可选） - > 解释器 - > 解释执行

程序源码 - > 词法分析 - > 单词流 - > 语法分析 - > 抽象语法树 - > 中间代码（可选） - > 生成器 - > 目标代码

源代码 - > 词法分析器 - > Token流 - > 语法分析器 - > 语法树/抽象语法树 - > 语法分析器 - > 注解抽象语法树 - > 字节码生成器 - > JVM字节码

JVM字节码 - > 借助Java虚拟机执行引擎 - > 机器无关优化 - > 中间代码 - > 寄存器分配器 - > 中间代码 - > 目标代码生成器 - > 目标代码

JVM 字节码 - > 借助符号表 - > 字节码解释器

机器码

指令

指令集

汇编语言

字节码

当Java虚拟机启动时会根据预定义的规范堆字节码采用逐行解释的方式执行，将每条字节码文件中的内容“翻译”为对应平台的本地机器指令执行

就是虚拟机将源代码直接编译成和本地机器平台相关的机器语言

当虚拟机启动时，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成再执行，这样可以省去许多不必要的编译时间。

并且随着程序运行时间的推移，即时编译器逐渐发挥作用，跟据热点探测功能，将有价值的字节码编译为本地机器指令，以换取更高的程序执行效率

热点代码及探测方式

解释编译模式设置

Hotspot中JIT分类

总结

PC寄存器

逐行编译字节码

本地机器指令

寻找字节码文件内热点代码

编译成本地机器指令，并放入方法区的元空间内，即JIT代码缓存

多次执行后直接从方法区的元空间的JIT代码缓存中取