标准答案
- 虚拟线程可以让阻塞风格代码承载更多并发，但每个请求仍可能占用数据库连接、内存和下游配额。
- CPU 密集任务不能靠增加虚拟线程获得超过 CPU 能力的吞吐。
- 应检查 synchronized、native 调用、线程本地变量和第三方库对挂载、资源和诊断的影响。
- 迁移前要基于目标 JDK 和真实负载测试延迟、吞吐、内存和下游压力。
题目解析
虚拟线程降低大量阻塞等待对平台线程和线程栈的成本，适合请求多、I/O 等待多且代码希望保持同步风格的场景。但每个请求仍会占用连接、内存、锁和下游配额。
CPU 密集工作最终仍受核心数限制，虚拟线程过多只会增加调度和排队。synchronized、native 调用、旧库行为和长时间持锁还可能影响虚拟线程的挂载与吞吐。
迁移要以目标 JDK 和真实负载验证内存、P99、吞吐、连接池、ThreadLocal 和诊断工具。虚拟线程是执行模型变化，不是取消容量治理。
常见误区
- 误区：把虚拟线程当作 CPU 扩容。改正：CPU 密集任务仍按核心和算法容量控制并发。
- 误区：每个任务仍创建永久连接。改正：连接池和下游配额仍是硬边界，任务结束必须归还资源。
- 误区：忽略库兼容性和 ThreadLocal 生命周期。改正：检查阻塞、native、锁和上下文传播行为，并做目标 JDK 压测。