jvm 第3版

对象头

实例数据

对齐填充

1.句柄

2.直接指针

内存泄漏

内存溢出

永不会被回收

内存溢出前会二次回收

一定会回收

非真实引用，只是一个标记，用来发系统通知

只需要在新生代建立一个全局的数据结构：记忆集

记忆集将老年代划分为若干小块

当Minor GC的时候，只需要扫描包含了跨代引用的小块内存，而不是整个老年代

新生代收集

老年代收集

混合收集

堆和方法区的垃圾收集

例如方法调用、循环跳转、异常跳转等

线程轮询标志位

卡表的每一个元素都对应一个卡页

只要卡页中有一个对象存在跨代指针，就将卡表的值标为1（变脏）

GC Roots扫描的时候，就可以轻松的找到包含跨代指针的内存了

写前屏障

写后屏障

判断卡表未被标记时才将其变脏

增加了一次判断，解决了“伪共享问题”

白色

黑色

灰色

收集器在“对象图”上标记颜色
同时，用户线程在修改引用关系
导致两个后果

产生对象消亡问题的两个充分必要条件

只需要破坏上面两个条件之一就可以了

运行用户代码时间/(运行用户代码时间 + 垃圾收集时间)

用户代码加上垃圾收集总耗时100分钟，其中垃圾收集
花掉1分钟，那吞吐量就是99%

参数-XX：+UseAdaptiveSizePolicy

自动分配新生代大小、Eden与Survivor区的比例等

1.对处理器资源敏感

2.无法处理浮动垃圾

3.会产生大量的空间碎片

1.跨Region引用对象问题

2.收集线程与用户线程互不干扰问题

3.建立可靠的停顿预测模型问题

4.要维护记忆集需要的内存开销大

5.写屏障过多

初始标记（Initial Marking）：标记一下GC Roots能直接关联到的对象，速度快，停顿短

并发标记（Concurrent Marking）：从GC Root开始对堆中对象进行可达性分析

最终标记（Final Marking）：短暂的暂停，用于处理并发阶段结束后仍遗留下来的SATB记录

筛选回收（Live Data Counting and Evacuation）：对各个Region的回
收价值和成本进行排序，并制定回收计划，必须暂停用户线程

1.G1不会有内存碎片

2.G1占用的内存比CMS多

3.G1的写屏障的消耗比CMS大

4.小内存（4G以内）CMS的表现基本上会优于G1
6G以上基本上是G1更好

初始标记（Initial Marking）：与G1一样

并发标记（Concurrent Marking）：与G1一样

最终标记（Final Marking）：与G1一样

并发清理（Concurrent Cleanup）：清理那些整个区域内连一个存活对象都没有的Region

并发回收（Concurrent Evacuation）：（与其他收集器的核心差异）把存活的对象复制到未使用的Region中

初始引用更新（Initial Update Reference）：把堆中所有指向旧对象的引用修正到复制后的新地址

并发引用更新（Concurrent Update Reference）：真正开始进行引用更新操作

最终引用更新（Final Update Reference）：把GC Roots中所有指向旧对象的引用修正到复制后的新地址

并发清理（Concurrent Cleanup）：整个回收集中所有的Region就没有存活对象了，将这些空间回收

在原有对象布局结构的最前面统一增加一个
新的引用字段，在正常情况下，该引用指向对象自己

小型Region（Small Region）：容量固定为2MB，用于放置小于256KB的小对象
中型Region（Medium Region）：容量固定为32MB，用于放置大于等于256KB但小于4MB的对象
大型Region（Large Region）：容量不固定，可以动态变化，用于放置4MB或以上的大对象

把标记信息记在引用对象的指针上

Linux下64位指针的高18位不能用来寻址，剩余的46位指针能支持64TB内存
将46位中的高4位用来做四个标志信息，用来实现三色标记
于是ZGC最大只有4TB的内存，不能支持32位平台，不能支持压缩指针

三大优势

初始标记（Initial Marking）：与G1、Shenandoah一样

并发标记（Concurrent Mark）：与G1、Shenandoah一样

并发预备重分配（Concurrent Prepare for Relocate）：确定重分配集

并发重分配（Concurrent Relocate）：重分配是ZGC执行过程中的核心阶段

并发重映射（Concurrent Remap）：修正指向重分配集中旧对象的所引用

G1的问题在于
1.维护记忆集的内存开销大
2.写屏障的过多使用给程序造成额外负担

jps -l

-q

RMI注册表中注册的主机名

jstat -gc 2764 250 20

jstat -gcutil 2764

jinfo -flag CMSInitiatingOccupancyFraction 1444

jmap -dump:format=b,file=eclipse.bin 3500

jstack -l 3500

天字一号大坑

微软的DLL、Java的JAR、.NET的Assembly，
工程做大后都无一例外陷入模块化地狱

Jigsaw面临的更大困难是大厂之间的竞争

由此得出Java要收费一说，轰动一时

但是在JDK11时说要保证OracleJDK和OpenJDK一致
转眼就在OracleJDK12里把Shennandoah剔除（出尔反尔）

从ZIP压缩包中读取

从网络中获取

运行时计算生成

从数据库中读取

......

是否以魔数0xCAFEBABE开头

主、次版本号是否在当前Java虚拟机接受范围之内

常量池的常量中是否有不被支持的常量类型

这个类是否有父类

这个类的父类是否继承了不允许被继承的类

如果这个类不是抽象类，是否实现了所有的方法

最复杂的一个阶段

保证被校验类的方法在运行时不会做出危害 虚拟机安全的行为

发生在虚拟机将符号引用转化为直接引用的时候

符号引用中通过字符串描述的全限定名是否能找到对应的类

在指定类中是否存在符合方法的字段描述符

符号引用中的类、字段、方法的可访问性

仅针对类变量，不包括实例变量

初始值是类型的零值，不是定义的值

以一组符号来描述所引用的目标

直接指向目标的指针

相对偏移量

间接定位到目标的句柄

1）遇到new、getstatic、putstatic或invokestatic

2）反射调用的时候

3）父类还没初始化，要先初始化父类

4）执行的主类要先初始化

5）当使用JDK 7新加入的动态语言支持时

6）当一个接口中定义了JDK 8新加入的默认方法时

子类访问父类的静态变量，只会触发
父类的初始化而不会触发子类的初始化

创建一个数组时，对象没有初始化

常量传播

自定义的类加载器

public class Singleton {
    private volatile static Singleton instance;
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
    public static void main(String[] args) {
        Singleton.getInstance();
    }
}

可能正在执行

也可能等待分配执行时间

■没有设置Timeout参数的Object::wait()方法；

■没有设置Timeout参数的Thread::join()方法；

■LockSupport::park()方法。

■Thread::sleep()方法；

■设置了Timeout参数的Object::wait()方法；

■设置了Timeout参数的Thread::join()方法；

■LockSupport::parkNanos()方法；

■LockSupport::parkUntil()方法。

等待获取一个排它锁

·等待可中断

·公平锁

·锁绑定多个条件