虚拟线程需规避CPU密集型任务、慎用同步锁、交由结构化并发管理、适配非阻塞库。它优化调度但不改变并发本质，滥用会阻塞载体线程、削弱性能。
Java Project Loom 的虚拟线程（Virtual Threads）极大简化了高并发 I/O 密集型应用的编写，但不是“开箱即用就万无一失”。它不改变 Java 并发模型的本质，而是优化了线程资源调度。用好虚拟线程的关键，在于理解它和平台线程（Platform Threads）的根本差异，并据此调整编程习惯。
避免在虚拟线程中执行长时间 CPU 密集型任务
虚拟线程由 JVM 调度、轻量、可海量创建，但它们仍运行在有限的平台线程（Carrier Thread）上。若某个虚拟线程长时间独占 CPU（如大循环、复杂计算、同步阻塞等），会阻塞整个载体线程，拖慢其他虚拟线程的执行，甚至引发吞吐下降或响应延迟。
- 识别 CPU 密集型逻辑：比如图像处理、加密解密、大量数学运算、深度递归、未优化的字符串拼接等
- 对确需 CPU 计算的任务，显式提交到 ForkJoinPool.commonPool() 或专用的 ThreadPoolExecutor（配置足够核心数）
- 可通过 Thread.currentThread().isVirtual() 在运行时判断，便于做策略分流
谨慎使用同步块和锁（synchronized / ReentrantLock）
虚拟线程本身不解决锁竞争问题。当多个虚拟线程争抢同一把锁时，JVM 仍需将它们排队挂起 —— 这看似“阻塞”，实则可能触发线程调度切换，削弱虚拟线程的轻量优势；更严重的是，若锁持有时间长，会造成大量虚拟线程在 carrier 线程上堆积等待。
- 优先采用无锁结构：如 ConcurrentHashMap、AtomicInteger、StampedLock（乐观读）
- 缩小临界区：只锁真正共享且需互斥的代码段，避免包裹 I/O 调用或日志打印
- 避免在 synchronized 方法/块内调用阻塞 I/O（如 SocketInputStream.read()），否则既阻塞又浪费载体线程
不要手动管理虚拟线程生命周期（如调用 start()/join()/interrupt()）
虚拟线程是“托管式”的，应交由结构化并发（Structured Concurrency）或 ExecutorService 统一调度。直接 new Thread(Runnable).start() 创建虚拟线程虽可行，但失去作用域管理和错误传播能力，也难以监控和取消。
立即学习“Java免费学习笔记（深入）”；
- 推荐使用 Executors.newVirtualThreadPerTaskExecutor() 提交任务
- 在 JDK 21+ 中，优先采用 StructuredTaskScope（如 ShutdownOnFailure 或 ShutdownOnSuccess）实现父子任务关系与异常聚合
- 避免调用 thread.interrupt() —— 虚拟线程不响应中断信号（除非主动检查 Thread.interrupted()）；改用 CancellationException 或作用域取消机制
适配现有库和框架：注意阻塞调用的“传染性”
很多传统 I/O 库（如 JDBC 驱动、OkHttp 同步客户端、旧版 Apache HttpClient）默认使用阻塞式 API。在虚拟线程中直接调用它们，会导致载体线程被占用，丧失并发弹性。这不是虚拟线程的缺陷，而是调用方式不匹配。
- 优先选用支持异步/非阻塞的替代品：如 PostgreSQL 的 pgjdbc-ng、R2DBC、Netty-based HTTP 客户端（如 AsyncHttpClient）
- 若必须用阻塞库，用 Executors.newCachedThreadPool() 或固定大小线程池隔离调用，再通过 CompletableFuture.supplyAsync(..., executor) 转移执行上下文
- 警惕日志框架的同步刷盘行为（如 Log4j2 默认的 FileAppender），建议启用异步日志（AsyncLogger）或切换为无锁队列实现
虚拟线程不是银弹，而是一次调度范式的升级。它的威力体现在“让每个请求拥有专属线程”变得廉价可行，前提是开发者尊重其设计约束：远离长耗时 CPU、慎用锁、交给结构化工具管理、绕过阻塞陷阱。写得越像单线程直觉代码，跑得越高效。
