VirtualThread 创建失败主因是 JDK 版本低于 21 或未启用预览特性，应确认使用 JDK 21+ 且未加 --disable-preview 参数，构建工具需同步配置 --enable-preview。
VirtualThread 创建失败：为什么 Thread.ofVirtual() 报 UnsupportedOperationException
Java 21 默认启用虚拟线程，但旧版本（如 Java 19/20）或未开启预览特性的环境里，Thread.ofVirtual() 会直接抛出 UnsupportedOperationException。这不是代码写错了，而是 JVM 层没开闸。
实操建议：
- 确认 JDK 版本 ≥ 21（推荐 21+ LTS），且未加
--disable-preview启动参数 - 若用 Maven/Gradle，确保编译和运行都指定
--enable-preview（Java 21 起已默认启用，但某些 IDE 或构建插件仍可能漏掉） - 检查是否在非模块化项目中调用了
Thread.ofVirtual().unstarted(runnable)—— 这个方法在 Java 21 中存在，但部分早期 21 GA 构建有 bug，建议改用Thread.ofVirtual().start(runnable)或直接new Thread(...).start()回退验证
虚拟线程池选 Executors.newVirtualThreadPerTaskExecutor() 还是手动 Thread.ofVirtual().start()
两者不是替代关系，而是不同抽象层级：前者返回 ExecutorService，适合任务调度、生命周期统一管理；后者是裸线程创建，适合极简控制或调试场景。
实操建议：
- Web 请求处理、批量 I/O 等典型高并发场景，优先用
Executors.newVirtualThreadPerTaskExecutor()—— 它内部自动复用CarrierThread，避免频繁 OS 线程切换 - 不要在循环里反复调用
Executors.newVirtualThreadPerTaskExecutor()创建新执行器，它不轻量，每次新建都会初始化独立的调度器；应复用单例或按需关闭 - 若需捕获虚拟线程异常（比如
InterruptedException），注意ExecutorService提交的任务异常默认被吞，要用Future.get()或包装Runnable捕获
Thread.ofVirtual() 的 builder 方法哪些参数真正生效
虚拟线程不支持设置优先级、守护状态、栈大小等传统线程属性，多数 setter 是空实现或仅存档（如 name() 可设，priority() 直接忽略）。
实操建议：
- 唯一可靠可设的是线程名：
Thread.ofVirtual().name("io-worker", 1)—— 对日志排查和 JFR 分析有意义 -
uncaughtExceptionHandler()有效，但要注意：虚拟线程异常若未被捕获，会传播到 carrier 线程的 handler，而不是主线程；建议全局设置Thread.setDefaultUncaughtExceptionHandler() -
allowSetThreadLocals(true)在 Java 21 中仍为实验性 API，生产环境慎用；inheritInheritableThreadLocals(false)才是默认且安全的行为
虚拟线程 + 阻塞 I/O 导致 carrier 线程饥饿的真实表现
虚拟线程遇到阻塞调用（如 FileInputStream.read()、老式 JDBC 驱动、未适配虚拟线程的 NIO 库）时，会把 carrier 线程“钉住”，导致其他虚拟线程无法调度 —— 表现为吞吐骤降、延迟飙升，但 CPU 不高、线程数看似正常。
实操建议：
- 用
jcmd <pid> VM.native_memory summary</pid>或 JFR 录制，观察jdk.VirtualThreadParked和jdk.CarrierThreadBlocked事件频次 - 数据库连接必须用支持虚拟线程的驱动（如 PostgreSQL 42.6.0+、MySQL 8.0.33+ 并启用
useVirtualThreads=true） - 文件 I/O 建议迁移到
AsynchronousFileChannel或封装成CompletableFuture.supplyAsync(..., executor)，避免直接阻塞
虚拟线程不是银弹，它的优势只在大量“等待 I/O 但不占 CPU”的场景里成立；一旦混入同步阻塞调用，反而比平台线程更难诊断。
