860MHz的专栏

分代ZGC能够适用于绝大多数使用场景，预计2025年3月发布的JDK 24中将移除ZGC的非分代模式（

总共花三篇文章大概介绍了JDK19中新增的虚拟线程，从LOOM Project的纤程、阿里的wisp和wisp2、到今天JEP 425中的虚拟线程，官方提供的生产可用的用户态线程方案距离我们越来越近了。

在上一篇文章中，我们已经简单的介绍了JEP 425: Virtual Threads (Preview)，以及如何使用虚拟线程编写例程，本文中将继续介绍虚拟线程的底层机制和核心源码。

经过多年的等待后，JEP 425: Virtual Threads (Preview)终于带来了虚拟线程，这一轻量级的线程模型对标其他语言中的协程，能够显著的减少编写、维护和观察高并发应用程序的工作量。

1. 简介 ZGC最后一个阶段就是并发转移，在之前的阶段已经标记出了活跃对象和需要转移的page。因此并发转移阶段，GC并发的将转移集中的活跃对象迁移到新页面，并在转移完成后回收旧页面。 2. 源码分析 2.1 入口 并发转移的转移的入口也在zHeap。 hotspot/share/gc/z/zHeap.cpp void ZHeap::relocate() { // Relocate relocation set _relocate.relocate(&_relocation_set);

1. 简介 在并发处理完强引用和非强引用后，ZGC就进入了转移阶段。 本文将介绍转移阶段开始的两个小步骤，重置转移集和选择转移集。 2. 源码分析 2.1 重置转移集 在标记阶段介绍后，所有的引用都已经指向对象迁移后的新地址，ZForwardingTable中的数据已经全部失效。此时需要重置转移集，为下一轮GC做准备。 hotspot/share/gc/z/zHeap.cpp void ZHeap::reset_relocation_set() { // 重置forwarding table ZRe

1. 简介 在并发标记结束后，ZGC进入非强引用的并发标记和处理阶段。主要负责处理软引用、弱引用、虚引用、FinalReference（实现了Finalize方法的类的实例）。 2. 引用 2.1 引用的基本概念 引用的类型 memory/referenceType.hpp enum ReferenceType { REF_NONE, // 正常的类 REF_OTHER, // java/lang/ref/Reference的子类，但不在下面里面 REF_SOFT,

1. 简介 并发标记是ZGC的第2个阶段，此阶段中，GC worker与Mutator并发工作，GC worker执行标记、load barrier和relocate。 并发线程从带标记对象列表开始，递归遍历对象及对象的成员变量并标记。 2. 源码分析 2.1 入栈 标记栈的size受ZMarkStackSpaceLimit参数控制，默认8G，合法值32MB到1TB之间。 share/gc/z/z_globals.hpp product(size_t, ZMarkStackSpaceLimit, 8*G

1. 简介 GC回收周期大体如下图所示： 与早期版本不同，ZGC回收周期调整为9个子阶段： phase 1：初始标记，需要STW phase 2：并发标记 phase 3：标记结束，需要STW phase 4：并发处理软引用、弱引用 phase 5：并发重置Relocation Set phase 6：验证 phase 7：并发选择Relocation Set phase 8：开始Relocate，STW phase 9：并发Relocate 出于回收效率的考虑，remap过程放在下一个回收周期的并发标记

1. 简介 对于并发GC来说，最复杂的事情在于GC worker在标记-整理，而Java线程(Mutator)同时还在不断的创建新对象、修改字段，不停的更新对象引用关系。因此并发GC一般采用两种策略Incremental Update(增量更新、CMS) 和SATB(snapshot at beginning、G1) ，两种策略网上介绍文章很多，此处不再赘述。 SATB关注引用关系的删除，可以参考我之前的博客JVM G1 源码分析（四）- Dirty Card Queue Set，而Incremental

1. 简介 自从JDK10中的引入了JEP 304: Garbage Collector Interface 后，OpenJDK定义了一整套关于GC的虚方法，供具体的GC算法实现。极大了简化了开发难度和代码的可维护性。 JEP 304定义了CollectedHeap类，每个GC都需要实现。CollectedHeap类负责驱动HotSpot的GC，以及和其他模块的交互。GC应当实现如下功能： CollectedHeap的子类 BarrierSet集合类的实现，提供在运行时各种屏障功能。 CollectorP

1. 概览 ZGC在JDK11中作为实验性功能引入后，已经经过了5个版本的演进，目前较之前版本有了较大的变化。 本文及其后几篇文章，将分析ZGC的设计思想和原理。 关于ZGC的介绍，可以参考OpenJDK ZGC 源码分析（一）概览 2. 简介 ZGC为了支持TB级内存，采用了基于Page的分页管理（类似于G1的Region）。 同时，为了加快内存访问速度，快速的进行并发标记和relocate，ZGC新引入了Color Pointers；Color Pointers与Shenandoah GC使用的Bro

堆 PriorityQueue是一种什么样的容器呢？看过前面的几个jdk容器分析的话，看到Queue这个单词你一定会，哦~这是一种队列。是的，PriorityQueue是一种队列，但是它又是一种什么样的队列呢？它具有着什么样的特点呢？它的底层实现方式又是怎么样的呢？我们一起来看一下。 PriorityQueue其实是一个优先队列，什么是优先队列呢？这和我们前面讲的先进先出（Firs

问题 最近在线上环境遇到一个奇怪的问题，仅仅20qps的压测，产生非常多的毛刺，立刻判断出毛刺是由于YGC导致。 线上环境为docker容器，4核8G内存，openjdk8u 排查过程 于是登录线上机器查看GC日志，发现GC Workers: 63，但压测服务器仅4核，不可能有63个GC线程。 [GC pause (G1 Evacuation Pause) (young), 0.0054131 secs] 10 [Parallel Time: 3.6 ms, GC Workers: 63] 11

1. 背景 昨日开始压测某微服务，但是发现了一个很奇怪的OOM: java heap space 通过压测平台压测必现，即使QPS=1时也必现 手动触发无法重现 发生OOM时，GC日志显示java heap并未全部占用，但gc触发原因是GC (Allocation Failure) 除了OOM日志，没有其他任何拦截器日志和业务日志 虽然已经在生产环境见过很多种OOM，但这类奇怪的OOM还是第一次见到。 2. 分析过程 2.1 Java Dump 分析OOM第一步通常就是查看dump文件，但是由于压测环境

1. 前言 本文将介绍select … for update语句相关知识，以及对可能导致的死锁和影响进行分析。 如无特殊说明，本文涉及的MySQL版本为8.0.22，事务隔离级别为RR，数据库引擎为INNODB。 2. 实验数据准备 创建一个测试表t_a： CREATE TABLE `test_a` ( `id` int NOT NULL, `a` int NOT NULL, `b` int NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAU

一个运行时的Java虚拟机实例的天职是：负责运行一个java程序。当启动一个Java程序时，一个虚拟机实例也就诞生了。当该程序关闭退出，这个虚拟机实例也就随之消亡。如果同一台计算机上同时运行三个Java程序，将得到三个Java虚拟机实例。每个Java程序都运行于它自己的Java虚拟机实例中。 Java虚拟机实例通过调用某个初始类的main()方法来运行一个Java程序。而这个main

1. 简介 在上篇文章中，我们介绍了RSet的原理，当对象引用关系变化时，都需要更新RSet。为了不影响Mutator的性能，RSet的更新通常是异步进行的，这一异步更新操作需要引入DCQS（Dirty Card Queue Set）结构。 本文将分析DCQS的原理。 2. DCQS 2.1 写入DCQS JVM声明了一个全局的静态结构G1BarrierSet，其中包含两个Queue Set，Di...

1. 背景 几年前曾经写过一篇Lambda表达式实现机制的分析，现在回头看错误很多，有误导嫌疑，因此重写一版订正。 2. Lambda表达式的字节码分析 下面代码为一个Lambda表达式的例子 package demo; import java.util.LinkedList; import java.util.List; import java.util.stream.Collectors; public class Test1 { public void func1(List<Inte

1. 简介 etcd的backend模块对于底层存储引擎进行了抽象，默认使用上一篇文章中介绍的BoltDB。 etcd将键值对的每一个版本都存储在BoltDB中，并在内存中构建BTree keyIndex索引。 在BoltDB中存储数据的key是revision，revision包含两个id：main revision和sub revision；main revision每个事务加1，sub revision事务中的每次操作加1； keyIndex索引的key是键值对的key，value是revisio