断点丢失本质是JDWP与虚拟线程调度适配问题，非插件可解决；必须配置--enable-preview、suspendPolicy:"thread"和maxThreads:100三项，否则断点在虚拟线程中大概率不生效。
没有专门解决“高并发调试断点丢失”的 VSCode 插件——断点丢失不是插件能绕过的底层机制问题，而是 JVM 调试协议（JDWP）与虚拟线程调度模型之间的适配问题。真正起作用的是配置、JVM 参数和调试器行为控制。
为什么装插件没用
VSCode Java 调试依赖 Extension Pack for Java（含 Debugger for Java），它本身已支持虚拟线程调试；但若断点在大量 jdk.VirtualThread 中“消失”或“不触发”，根源不在插件缺失功能，而在：
- JVM 启动时未启用预览特性：
--enable-preview缺失 → 虚拟线程被降级为平台线程，调试器无法识别其生命周期 - launch.json 里没传
vmArgs，或参数写错位置（比如放在args而非vmArgs） - 调试器默认挂起所有线程，导致 UI 卡死、断点绑定超时失败 —— 这不是插件 bug，是性能策略
必须改的 launch.json 配置项
以下三项缺一不可，否则断点在虚拟线程中大概率不生效：
-
"vmArgs": ["--enable-preview", "-source", "21"]：Java 21 虚拟线程是预览特性，不加这行，JVM 根本不暴露虚拟线程调试接口 -
"suspendPolicy": "thread"：避免全局暂停，只挂起命中的那个虚拟线程；设成all会卡死或丢断点 -
"maxThreads": 100（可选但强烈建议）：限制调试器加载线程数，防止因百万级虚拟线程拖垮 VSCode 渲染
示例片段：
{
"type": "java",
"name": "Launch with Virtual Threads",
"request": "launch",
"mainClass": "com.example.Main",
"vmArgs": ["--enable-preview", "-source", "21"],
"suspendPolicy": "thread",
"maxThreads": 100
}
别信“自动修复断点”的插件宣传
目前没有任何 VSCode 插件能“自动恢复丢失的虚拟线程断点”。所谓“修复”，本质是帮你补全上述配置、或注入 debugger; 语句——但 Java 没有 debugger 关键字，只能靠 JVM 参数和条件断点兜底。
- 条件断点要写在宿主线程调用处（如
executor.submit(...)行），而不是虚拟线程内部代码里——后者可能还没来得及绑定就已结束 - 如果看到断点变为空心红点，先检查
target/classes/下是否有对应.class文件，再确认mainClass路径是否拼写正确（大小写敏感） - 日志点（Logpoint）比中断断点更可靠：
console.log("vthread id: " + Thread.currentThread().getName())可验证是否真进了虚拟线程
最常被跳过的其实是 JVM 日志开关：-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput 不开，你就看不到虚拟线程创建/阻塞的真实时机，断点永远像在猜。
