虚拟线程的延续体（Continuation）是JVM实现挂起与恢复的核心运行时结构，为堆中保存的可中断计算状态快照；平台线程则依赖OS调度，无用户态执行快照机制，阻塞时内核线程休眠，无Continuation概念。
虚拟线程的延续体（Continuation）不是抽象概念，而是 JVM 实现挂起与恢复执行的核心运行时结构；平台线程则完全依赖操作系统调度，没有这种用户态的执行快照机制。
延续体是虚拟线程可挂起、可恢复的“执行快照”
Continuation 代表一段可中断计算的状态封装。当虚拟线程执行阻塞操作（如 Socket.read()、Thread.sleep() 或文件读写）时，JVM 不会冻结底层 OS 线程，而是将当前调用栈的所有栈帧序列化到堆内存中——这个被保存下来的完整执行上下文，就是 Continuation。
- 它不占用内核栈空间，只存于 Java 堆，大小随实际调用深度动态变化，通常仅几 KB
- 挂起时，JVM 清空该虚拟线程在载体线程上的执行上下文，释放载体线程去跑别的虚拟线程
- I/O 完成后，JVM 从堆中还原 Continuation，把调用栈重新加载到某个空闲载体线程上继续执行，对开发者完全透明
平台线程调度由操作系统全权接管，无用户态状态管理
平台线程生命周期全程绑定一个内核线程：创建时分配固定大小栈（默认 1MB），销毁时归还资源；其调度完全由 OS 内核完成，JVM 只做简单包装。
- 遇到阻塞调用时，整个内核线程进入休眠态，CPU 时间片被剥夺，无法复用
- 没有 Continuation 概念——OS 不保存、也不恢复 Java 方法调用栈；线程唤醒后直接从系统调用返回点继续，但中间无法切换其他任务
- 上下文切换需陷入内核态，涉及寄存器保存/恢复、TLB 刷新等开销，频繁切换易导致 CPU 缓存失效
调度模型本质不同：协作式卸载 vs 抢占式内核调度
虚拟线程调度发生在 JVM 用户态，基于 Continuation 的“卸载（unmount）→ 调度 → 挂载（mount）”三步闭环；平台线程调度则是 OS 在固定时间片或事件触发下强制切换内核线程。
立即学习“Java免费学习笔记（深入）”；
- 虚拟线程调度器（基于 ForkJoinPool 工作窃取）决定何时把哪个虚拟线程分配给哪个载体线程，无需系统调用
- 平台线程的调度时机、优先级、亲和性均由 OS 决定，JVM 无法干预，也无“卸载”能力
- 一个载体线程可轮流承载成百上千个虚拟线程，而一个平台线程永远只服务一个 Java Thread 实例
代码层面的体现：同一套 Thread API，行为截然不同
两者都继承自 java.lang.Thread，但构造方式和行为语义分离：
- Thread.ofPlatform().start(runnable) → 创建传统 1:1 平台线程
- Thread.ofVirtual().start(runnable) → 创建 M:N 虚拟线程，自动启用 Continuation 支持
- 调用 Thread.sleep(1000) 在平台线程中让 OS 线程休眠 1 秒；在虚拟线程中只是触发一次卸载+Continuation 保存，载体线程立刻投入其他工作
