Linux内核线程调度与虚拟线程调度机制系统级深度剖析
- 前言
- 内核线程调度与虚拟线程调度机制剖析
-
- [一、 平台线程（1:1 模型）与 Linux 内核 `task_struct` 抽象](#一、 平台线程（1:1 模型）与 Linux 内核
task_struct抽象) -
- [1.1 系统级调用链与内存映射](#1.1 系统级调用链与内存映射)
- [1.2 OpenJDK 源码分析：1:1 平台线程创建路径](#1.2 OpenJDK 源码分析：1:1 平台线程创建路径)
- [1.3 Linux 内核系统调用过程](#1.3 Linux 内核系统调用过程)
- [1.4 1:1 模型系统的瓶颈分析](#1.4 1:1 模型系统的瓶颈分析)
- [二、 Project Loom 虚拟线程与 Continuation（M:N 调度机制）](#二、 Project Loom 虚拟线程与 Continuation（M:N 调度机制）)
-
- [2.1 Continuation 栈挂起（Freeze）与恢复（Thaw）架构](#2.1 Continuation 栈挂起（Freeze）与恢复（Thaw）架构)
- [2.2 Java 层虚拟线程调度与出让（Yield）源码分析](#2.2 Java 层虚拟线程调度与出让（Yield）源码分析)
- [2.3 HotSpot 内核 C++ 层的 Freeze（冻结）栈拷贝实现](#2.3 HotSpot 内核 C++ 层的 Freeze（冻结）栈拷贝实现)
- [三、 Carrier Thread 的抢占机制与 Thread Pinning（线程钉住）](#三、 Carrier Thread 的抢占机制与 Thread Pinning（线程钉住）)
-
- [3.1 调度与抢占时机对照](#3.1 调度与抢占时机对照)
- [3.2 Thread Pinning 产生原因与 C++ 源码判定](#3.2 Thread Pinning 产生原因与 C++ 源码判定)
-
- [导致 Pinning 的三大关键场景：](#导致 Pinning 的三大关键场景：)
- [四、 ForkJoinPool 工作窃取（Work-Stealing）算法源码剖析](#四、 ForkJoinPool 工作窃取（Work-Stealing）算法源码剖析)
-
- [4.1 核心数据结构 `WorkQueue` 内存布局](#4.1 核心数据结构
WorkQueue内存布局) - [4.2 `ForkJoinPool.java` 无锁队列与双端窃取源码详解](#4.2
ForkJoinPool.java无锁队列与双端窃取源码详解) - [4.3 系统级无锁设计与 Cache 优化哲学](#4.3 系统级无锁设计与 Cache 优化哲学)
- [4.1 核心数据结构 `WorkQueue` 内存布局](#4.1 核心数据结构
- [五、 平台线程与虚拟线程调度特性综合对比](#五、 平台线程与虚拟线程调度特性综合对比)
- [一、 平台线程（1:1 模型）与 Linux 内核 `task_struct` 抽象](#一、 平台线程（1:1 模型）与 Linux 内核
前言
本文旨在记录近期研读Java源码的学习心得与疑难问题。由于个人理解水平有限，文中内容难免存在疏漏，恳请读者不吝指正。
内核线程调度与虚拟线程调度机制剖析
一、 平台线程（1:1 模型）与 Linux 内核 task_struct 抽象
在传统 HotSpot JVM 实现中，java.lang.Thread 平台线程与 Linux 操作系统的 POSIX 线程（pthread）是一对一（1:1）直接映射的。在 Linux 内核层，无论是进程还是线程，均由 task_struct 结构体统一表示。
1.1 系统级调用链与内存映射
当 Java 代码执行 new Thread().start() 时，JVM 内部会触发一系列从用户态 Java 运行时到 C++ HotSpot 虚拟机，再到 POSIX 线程库，最终进入 Linux 内核的下沉调用：
Java 线程层: [ java.lang.Thread (Platform Thread) ]
│ (JNI / JVM_StartThread)
HotSpot C++ 层: [ JavaThread ] ───► [ OSThread ]
│
OS 系统调用层: [ pthread_create() ] ───► clone(2)
│
Linux 内核层: [ task_struct (CFS/EEVDF 调度队列) ]1.2 OpenJDK 源码分析：1:1 平台线程创建路径
在 HotSpot 源码 src/hotspot/os/linux/os_linux.cpp 中，os::create_thread 展现了物理线程的创建与映射逻辑：
cpp
// 源代码出处: src/hotspot/os/linux/os_linux.cpp
// 描述: 创建 Linux 原生线程并建立 JavaThread 与 OSThread 的 1:1 映射关系
bool os::create_thread(Thread* thread, ThreadType thr_type, size_t stack_size) {
assert(thread->osthread() == nullptr, "caller responsible");
// 1. 分配 HotSpot 层面的 OSThread 内部数据结构，用于保存 Native PID/TID 及线程状态
OSThread* osthread = new OSThread(finish_creating_thread, thread);
if (osthread == nullptr) {
return false;
}
// 将 OSThread 结构挂载到 JavaThread 上
thread->set_osthread(osthread);
// 2. 初始化 POSIX 线程属性结构体
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
// 3. 设置物理栈大小（受 -Xss 参数配置，默认通常为 1MB）
// 系统工程师视角：内核必须为每一个 1:1 平台线程分配独立且连续的虚拟内存区域 (VMA) 和 Guard Page
if (stack_size != 0) {
pthread_attr_setstacksize(&attr, stack_size);
} else {
pthread_attr_setstacksize(&attr, os::Linux::default_stack_size(thr_type));
}
// 4. 调用 NPTL pthread_create 触发 clone(2) 内核系统调用
// 传递系统回调入口函数 thread_native_entry
pthread_t tid;
int ret = pthread_create(&tid, &attr, thread_native_entry, thread);
pthread_attr_destroy(&attr);
if (ret != 0) {
thread->set_osthread(nullptr);
delete osthread;
return false;
}
// 5. 保存 POSIX pthread_t 句柄，Linux 上 pthread_t 本质上是 NPTL 线程描述符内存地址
osthread->set_pthread_id(tid);
return true;
}1.3 Linux 内核系统调用过程
pthread_create 在 Linux 下通过 glibc 最终发起 clone(2) 系统调用，传递的关键标志位如下：
Flags = CLONE_VM ∣ CLONE_FS ∣ CLONE_FILES ∣ CLONE_SIGHAND ∣ CLONE_THREAD ∣ CLONE_SYSVSEM ∣ CLONE_SETTLS \text{Flags} = \text{CLONE\_VM} \mid \text{CLONE\_FS} \mid \text{CLONE\_FILES} \mid \text{CLONE\_SIGHAND} \mid \text{CLONE\_THREAD} \mid \text{CLONE\_SYSVSEM} \mid \text{CLONE\_SETTLS} Flags=CLONE_VM∣CLONE_FS∣CLONE_FILES∣CLONE_SIGHAND∣CLONE_THREAD∣CLONE_SYSVSEM∣CLONE_SETTLS
内核处理 clone(2) 时：
-
**分配
task_struct**：内核在 Slab 分配器（task_struct_cachep）中为新线程分配空间。 -
**分配
kernel_stack**：分配固定大小（通常为 16KB）的内核栈（Kernel Stack），用于响应系统调用与硬件中断。 -
共享虚拟地址空间 ：由于设置了
CLONE_VM，新线程与父进程共享同一个mm_struct（包含页表、VMA 树等）。 -
加入调度队列 ：内核调度器（CFS 或 EEVDF）将新
task_struct插入 CPU 的运行队列（runqueue）红黑树或 EEVDF 延迟树中。+-----------------------------------------------------------------------------------+
| Linux Kernel task_struct (线程 A) |
| ├── pid_t pid (线程ID / TID) |
| ├── pid_t tgid (线程组ID / PID) |
| ├── mm_struct *mm ──────────────────────────────► [ 共享的虚拟内存地址空间页表 ] |
| ├── thread_struct thread ▲ |
| │ ├── rsp (用户态栈顶指针) │ |
| │ └── rip (指令寄存器指针) │ |
| └── stack (16KB 内核栈) │ |
+--------------------------------------------------│--------------------------------+
│
+--------------------------------------------------│--------------------------------+
| Linux Kernel task_struct (线程 B) │ |
| ├── pid_t pid │ |
| ├── pid_t tgid │ |
| ├── mm_struct *mm ──────────────────────────────┘ |
+-----------------------------------------------------------------------------------+
1.4 1:1 模型系统的瓶颈分析
从系统工程师的角度，1:1 模型存在物理维度的上限瓶颈：
| 维度 | 系统开销/瓶颈机理 |
|---|---|
| 内存足迹 (Memory Footprint) | 每一个平台线程必须分配连续的 Native Stack（设为 1MB，由 -Xss 决定），加上内核 task_struct（~2.75KB）、kernel_stack（16KB）以及系统的物理页表项（PTE），10 万线程将消耗超过 100GB 内存。 |
| 内核资源限制 | 受限于 /proc/sys/kernel/pid_max（PID 数量上限）与 /proc/sys/vm/max_map_count（虚拟内存映射区数量上限）。 |
| 上下文切换耗时 (Context Switch) | 内核级切换引发 Ring 3 ↔ \leftrightarrow ↔ Ring 0 级切换，保存/恢复通用寄存器、RSP、RIP、AVX-512/SIMD 向量寄存器，产生 TLB（页表缓存）失效 及 CPU L1/L2 Cache 污染 ，每次切换耗时约为 1 ∼ \sim ∼ 5 微秒。 |
| 调度器 O ( log N ) O(\log N) O(logN) 竞争 | CFS/EEVDF 在维护极多活跃线程的 runqueue 时，红黑树的调整与 CPU 核心间 load_balance（负载均衡锁）会导致显著的内核态 CPU 消耗。 |
二、 Project Loom 虚拟线程与 Continuation（M:N 调度机制）
Project Loom 引入了 M:N 调度模型 ，将 M M M 个用户态虚拟线程（VirtualThread）复用映射到 N N N 个平台线程（ Carrier Thread，载体线程）上执行。
虚拟线程 (M) [VT 1] [VT 2] [VT 3] [VT 4] [VT ... M]
│ │ │ │
┌─┴────────┴────────┴────────┴─┐
调度器层 (JVM) │ ForkJoinPool (Carrier 线程池) │
└─┬────────────────────────┬───┘
Carrier 线程 (N) [Carrier Thread 1] [Carrier Thread 2] (N = CPU Cores)
│ │
Linux 内核 (1:1) [task_struct 1] [task_struct 2]2.1 Continuation 栈挂起（Freeze）与恢复（Thaw）架构
虚拟线程的核心是 Continuation（执行上下文控制流）。Continuation 允许 JVM 将方法调用栈解耦为可序列化到 Java 堆内存 的 stackChunkOop 对象。
【物理 CPU Stack】 【Java Heap】
┌────────────────────────────────┐ ┌───────────────────────────────┐
│ VirtualThread.run() Frame │ │ stackChunkOop (Heap Object) │
├────────────────────────────────┤ Freeze │ ┌─────────────────────────┐ │
│ Service.process() Frame │ ──────► │ │ Saved Stack Frame N │ │
├────────────────────────────────┤ │ ├─────────────────────────┤ │
│ SocketChannel.read() Frame │ │ │ Saved Stack Frame N-1 │ │
└────────────────────────────────┘ │ └─────────────────────────┘ │
▲ └───────────────────────────────┘
│ │
└─────────────────────────────────────────┘
Thaw2.2 Java 层虚拟线程调度与出让（Yield）源码分析
在 src/java.base/share/classes/java/lang/VirtualThread.java 中，定义了虚拟线程的状态机转换与挂起逻辑：
java
// 源代码出处: src/java.base/share/classes/java/lang/VirtualThread.java
public class VirtualThread extends BaseVirtualThread {
private final Executor scheduler; // 默认调度器：ForkJoinPool
private final Continuation cont; // 保存执行状态的 Continuation 对象
private volatile Thread carrierThread; // 当前绑定的 Carrier 平台线程
// 状态定义：NEW -> STARTED -> RUNNING -> PARKING -> PARKED -> RUNNABLE -> TERMINATED
private volatile int state;
// 当虚拟线程需要挂起（如 LockSupport.park()、NIO 阻塞、Thread.sleep()）时调用
@Override
void park() {
if (Thread.currentThread() != this) {
throw new IllegalStateException();
}
int s = getState();
if (s == RUNNING && compareAndSetState(RUNNING, PARKING)) {
boolean yielded = false;
try {
// 触发用户态 Continuation 出让逻辑
yielded = yieldContinuation();
} finally {
// 若 yield 失败（例如由于 Pinned 状态），强制回退到 Native 物理阻塞模式
if (!yielded) {
parkOnCarrierThread();
}
}
}
}
private boolean yieldContinuation() {
// 调用 Continuation.yield() 出让当前执行上下文
// 内部通过 JNI 陷入 HotSpot C++ 运行时，执行 Continuation::freeze
return Continuation.yield(VTHREAD_SCOPE);
}
// 当 Carrier Thread 调度运行该 Virtual Thread 时触发的回调
private void runContinuation() {
// 绑定当前 Carrier 平台线程到 VirtualThread 实例
mount();
try {
// 执行 Continuation（内部会调用 Continuation::thaw 恢复栈帧）
cont.run();
} finally {
// 挂起或执行完毕后，解绑 Carrier 平台线程
unmount();
}
}
}2.3 HotSpot 内核 C++ 层的 Freeze（冻结）栈拷贝实现
在 src/hotspot/share/runtime/continuationFreezeThaw.cpp 中，展示了 JVM 如何将物理 CPU 栈帧打包并移动至 Java 堆内存：
cpp
// 源代码出处: src/hotspot/share/runtime/continuationFreezeThaw.cpp
// 描述: 执行 Continuation::freeze，将物理栈帧保存至 stackChunkOop
int Continuation::freeze(JavaThread* thread, intptr_t* sp) {
// 1. 获取当前 JavaThread 挂载的 ContinuationEntry 句柄
ContinuationEntry* entry = thread->last_continuation();
// 2. 检查 Pinning（钉住）限制条件
// 如果栈帧中包含 Native 代码、JNI 句柄或锁监视器，则禁止 Freeze
if (is_pinned(thread, entry)) {
return freeze_pinned; // 返回 pinned 状态，拒绝挂起
}
// 3. 构建 Freeze 上下文，准备对物理栈进行 Stack Walk（栈遍历）
FreezeBase freeze(thread, entry, sp);
// 4. 执行堆栈帧复制（Physical Stack -> Heap stackChunkOop）
return freeze.freeze();
}
template <typename Config>
int FreezeBase::freeze() {
int size = 0;
int num_frames = 0;
// 步骤 A: 遍历物理栈上从当前 SP (Stack Pointer) 到 Continuation 边界的所有 Java 栈帧
for (frame f = _thread->last_frame(); !_cont_at_frame(f); f = sender(f)) {
size += f.cb()->frame_size(); // 统计所需物理字节数
num_frames++;
}
// 步骤 B: 在 Java 堆上分配或获取预留的 stackChunkOop 对象
stackChunkOop chunk = get_or_allocate_chunk(size);
// 步骤 C: 逐帧内存拷贝 (Fast memcpy)
address chunk_sp = chunk->start_address() + size;
for (frame f = _thread->last_frame(); !_cont_at_frame(f); f = sender(f)) {
chunk_sp -= f.cb()->frame_size();
// 执行二进制级别的物理栈内容拷贝至 Heap
Copy::conjoint_bytes(f.unextended_sp(), chunk_sp, f.cb()->frame_size());
// 修正 (Patch) 栈帧内的相对基址指针（FP/SP）以及 局部变量表/OopMap 中的对象引用
patch_frame(f, chunk_sp);
// 将该栈帧内的所有 Java 对象引用 (Oops) 记录到 stackChunkOop 的 GC Bitmap 中
// 保证 GC 在并发标记阶段能扫描到挂起栈中的堆对象
process_oops(f, chunk_sp, chunk);
}
// 步骤 D: 更新 stackChunk 的元数据并返回成功
chunk->set_sp(chunk_to_sp_offset(chunk, chunk_sp));
chunk->set_num_frames(num_frames);
return freeze_ok;
}三、 Carrier Thread 的抢占机制与 Thread Pinning（线程钉住）
3.1 调度与抢占时机对照
下图展示了虚拟线程在发生 I/O 阻塞或调用出让 API 时，物理 Carrier 线程解绑与挂起的步骤：
-
1. 触发阻塞 API: 用户态逻辑.
虚拟线程执行
SocketChannel.read()、LockSupport.park()或Thread.sleep()。 -
2. 检查 Pinning 标志: HotSpot C++ 内核.
JVM 扫描栈帧，确认是否存在
synchronized临界区或 Native JNI 帧。 -
3. 执行 Continuation Freeze: 内存拷贝.
物理栈上的 Java 栈帧被拷贝至堆内存的
stackChunkOop对象中，修改 SP/FP 指针。 -
4. Carrier 线程解绑与复用: 用户态调度.
Carrier Thread 脱离当前虚拟线程，状态保持为
TASK_RUNNING，回到ForkJoinPool窃取或执行其他虚拟线程。 -
5. 事件唤醒与 Thaw 恢复: Poller / ForkJoinPool.
NIO Poller 或其他线程调用
unpark()，将虚拟线程重新放入ForkJoinPool，任一空闲 Carrier 线程提取该任务并还原（Thaw）栈帧。
3.2 Thread Pinning 产生原因与 C++ 源码判定
当虚拟线程执行到无法安全剥离栈帧的代码区段时，触发 Continuation.yield() 会失败并返回 freeze_pinned。此时虚拟线程无法出让 Carrier，直接退化为阻塞底层 Native 平台线程。
导致 Pinning 的三大关键场景：
- 处于
synchronized块/方法内部 ：
HotSpot 的经典 Monitor 锁机制（ObjectMonitor）将持有锁的指针与物理线程的JavaThread*绑定。如果在synchronized内解绑，会导致锁持有者标识错乱。 - 执行 Native 方法（JNI 调用）或 Foreign Function & Memory API（Panama） ：
C/C++ 代码的 Native 栈帧分配在 C-Stack（物理系统栈）上，JVM 无法对其进行 Stack Walk、截断或反序列化到 Heap。 - 隐式的类加载（Class Loading）与 JVM 内部临界区。
cpp
// 源代码出处: src/hotspot/share/runtime/continuationFreezeThaw.cpp
// 描述: 判定当前物理栈上的栈帧是否包含 Pinning 条件
bool Continuation::is_pinned(JavaThread* thread, ContinuationEntry* entry) {
if (thread->has_last_Java_frame()) {
// 从最新栈帧向老栈帧遍历，直至 Continuation 边界
for (frame f = thread->last_frame(); !_cont_at_frame(f); f = sender(f)) {
// 检查 1: 是否包含 Native C/C++ 语言栈帧
if (f.is_native_frame()) {
return true; // Native 栈帧无法被安全冻结，强制 Pinning
}
// 检查 2: 解释器栈帧中是否包含未释放的 synchronized 监视器 (Monitor)
if (f.is_interpreted_frame()) {
if (f.interpreter_frame_monitor_begin() < f.interpreter_frame_monitor_end()) {
return true; // 持有 synchronized Monitor，强行 Pinning
}
}
// 检查 3: 编译后的 C1/C2 栈帧中是否包含 synchronized 锁记录 (Monitorenter)
if (f.is_compiled_frame()) {
if (f.compiled_frame_has_monitor(_thread)) {
return true; // 编译锁未释放，强行 Pinning
}
}
}
}
return false;
}四、 ForkJoinPool 工作窃取（Work-Stealing）算法源码剖析
Project Loom 默认使用专属的 ForkJoinPool 实例调度虚拟线程。ForkJoinPool 为每个 Carrier 线程分配独立的双端工作队列（WorkQueue） ，结合无锁化（Lock-Free）工作窃取算法，解决了高并发场景下的线程竞争与负载不均问题。
4.1 核心数据结构 WorkQueue 内存布局
[ Carrier Thread X (Owner) ] [ Carrier Thread Y (Thief) ]
│ │
▼ (LIFO 本地存取) ▼ (FIFO 跨线程窃取)
┌───────────────────┬───────────────────┬───────────────────┐
Array │ Task 0 │ Task 1 │ Task 2 │
└───────────────────┴───────────────────┴───────────────────┘
▲ ▲
│ │
base (volatile) top
(窃取端 / Thief 访问) (本地端 / Owner 访问)-
Owner（持有者平台线程） ：从
top端压入（push）和弹出（pop）任务，遵循 LIFO（后进先出） 顺序。 -
系统优化原理 ：最新入队（位于
top）的任务对应的数据更有可能停留在 CPU 的 L1/L2 Cache 中，LIFO 能最大化提升 Cache 命中率。 -
Thief（窃取者平台线程） ：当自身的
WorkQueue为空时，从其他 Carrier 线程队列的base端执行窃取（poll），遵循 FIFO（先进先出） 顺序。 -
系统优化原理 ：最早入队（位于
base）的任务通常是树状分治结构顶层的"大任务"，窃取大任务可以将其继续拆解，减少后续再次窃取的频次；同时实现 Owner 与 Thief 的空间解耦，将 CAS 锁竞争概率降至最低。
4.2 ForkJoinPool.java 无锁队列与双端窃取源码详解
java
// 源代码出处: src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
static final class WorkQueue {
// 伪共享消除：对 base 和 top 变量施加内存对齐填充，防止 Cache Line 废弃风暴
@jdk.internal.vm.annotation.Contended
volatile int base; // 窃取端索引 (Thief 访问端，需保证 volatile 内存可见性)
int top; // 本地压栈/出栈索引 (仅 Owner 线程修改，无写竞争)
ForkJoinTask<?>[] array; // 环形任务数组 (容量为 2 的幂次)
final ForkJoinWorkerThread owner; // 绑定的 Carrier 平台线程
// ================= 1. Owner 线程压入任务 (LIFO Push) =================
final void push(ForkJoinTask<?> task) {
int s = top;
ForkJoinTask<?>[] a = array;
if (a != null) {
int m = a.length - 1;
// 将 VirtualThread 包装的 ForkJoinTask 写入 top 槽位
// 使用 Unsafe/VarHandle 的 Release 语义写入，保证指令不重排序
U.putReferenceRelease(a, ((m & s) << ASHIFT) + ABASE, task);
// 递增 top 指针（只有 Owner 修改 top，无需任何 CAS 操作！）
top = s + 1;
// 唤醒或创建其他 Carrier 线程来协助处理
signalWork();
}
}
// ================= 2. Owner 线程弹出任务 (LIFO Pop) =================
final ForkJoinTask<?> pop() {
ForkJoinTask<?>[] a; int b, s;
if ((a = array) != null && (b = base) != (s = top)) {
int m = a.length - 1;
int i = (m & --s) << ASHIFT; // 先递减 top 指针
// 以 Acquire 内存语义获取 top 槽位上的任务
ForkJoinTask<?> t = (ForkJoinTask<?>) U.getReferenceAcquire(a, i + ABASE);
if (t != null) {
// 清空该槽位
if (U.compareAndSetReference(a, i + ABASE, t, null)) {
top = s; // 更新 top 指针
return t;
}
}
}
return null;
}
// ================= 3. Thief 线程并发窃取任务 (FIFO Poll/Steal) =================
final ForkJoinTask<?> poll() {
ForkJoinTask<?>[] a; int b;
// 当 base - top < 0 时，说明队列中存在可供窃取的任务
while ((b = base) - top < 0 && (a = array) != null) {
int m = a.length - 1;
// 计算 base 端对应任务的物理内存偏移量 (FIFO 顺序)
int i = ((m & b) << ASHIFT) + ABASE;
// 以 Acquire 语义读取 base 处的任务
ForkJoinTask<?> t = (ForkJoinTask<?>) U.getReferenceAcquire(a, i);
// 再次校验 base 是否发生改变（防止其他 Thief 并发修改）
if (base == b) {
if (t != null) {
// 核心并发控制：
// 多个 Thief 线程可能同时窃取同一个 WorkQueue 的 base 位置
// 使用 CAS (compareAndSetReference) 强行抢占！
if (U.compareAndSetReference(a, i, t, null)) {
// 抢占成功，原子的将 base 指针推进 1 位
base = b + 1;
return t; // 返回窃取到的虚拟线程任务
}
} else {
break;
}
}
}
return null;
}
}4.3 系统级无锁设计与 Cache 优化哲学
- Owner-Side Zero Contention ：
Owner 在top端的push和pop不需要执行 CAS 指令（不需要LOCK CMPXCHG），避免了总线锁引起的 CPU 流水线停顿（Pipeline Stall）。 - 伪共享（False Sharing）消除 ：
在多核 CPU 架构下，base（由 Thief 频繁 CAS 写入）与top（由 Owner 频繁写）若处于同一个 64 字节的 Cache Line 中，会导致严重的高频缓存失效（Cache Bounce）。WorkQueue中通过@Contended标记对base变量做显式 Padding 对齐，切断了缓存伪共享。 - CAS 锁竞争最小化 ：
通过 Owner 访问top（LIFO）与 Thief 访问base（FIFO）的双端分离设计，只有当队列中仅剩最后一个任务，导致top - 1 == base时，Owner 和 Thief 才会发生碰撞竞争同一个槽位。
五、 平台线程与虚拟线程调度特性综合对比
| 调度维度 | Platform Thread（平台线程） | Virtual Thread（虚拟线程） |
|---|---|---|
| 映射模型 | 1:1 映射 Linux 内核 task_struct |
M:N 映射（M 个 VirtualThread 复用 N 个 Carrier 平台线程） |
| 调度控制方 | Linux 内核 CFS / EEVDF 调度器 | JVM 用户态调度器 （ForkJoinPool） |
| 内存分配 | 固定预分配 （默认 -Xss1M），占用 Native 物理内存 |
动态扩展/收缩 （几百字节起），存在 Java 堆 stackChunkOop |
| 上下文切换开销 | 高 （Ring 3 ↔ \leftrightarrow ↔ Ring 0，保存/恢复 CPU 寄存器组，TLB 失效，Cache 污染） | 极低 （用户态 memcpy 拷贝，更新 Continuation 句柄） |
| 抢占机制 | 硬件时钟中断强行抢占（时间片轮转 / 动态优先级调整） | 协同式出让（基于阻塞点主动出让；纯 CPU 密集的死循环无法强行抢占） |
| 并发承载上限 | 数千 ∼ \sim ∼ 数万（受限于 OS 物理内存与 PID 数量） | 数百万 ∼ \sim ∼ 千万级（受限于 Java 堆内存大小） |
| 内核阻塞代价 | 平台线程挂起，引发内核级 TASK_INTERRUPTIBLE 上下文切换 |
解耦！虚拟线程挂起，Carrier 线程继续运行其他虚拟线程 |