不能——vscode调试器是单会话模型，仅能逐个暂停线程并切换上下文，不支持真正并行控制；它依赖线程列表、快速切换、条件断点和日志辅助实现近似并发调试体验。
VSCode 不能真正“并发控制”多线程——它只允许你单点暂停、手动切换线程上下文，所有线程实际是 all-stop 模式（GDB/LLDB 后端行为），Java 调试器（JDWP）也默认同步挂起全部线程。所谓“并发调试”，本质是快速切栈 + 精准断点 + 非侵入观测。
Java 断点不触发？先改 Suspend 策略
默认 All 挂起策略会让一个线程断住时，其他线程也被强制暂停，导致竞态条件消失、超时逻辑跳过，甚至误判线程未启动。
- 右键断点 → Edit Breakpoint → 将
Suspend改为Thread - 对
synchronized块、ReentrantLock.lock()、CompletableFuture.thenApply()这类临界入口，必须用Thread级别，否则主线程一停，工作线程永远等不到锁释放 - 若需复现特定线程行为，加条件表达式：
Thread.currentThread().getName().equals("pool-1-thread-2")
线程列表为空或看不到 WAITING 状态？检查 Threads 视图是否手动打开
VSCode 的 Java 调试器不会自动展开线程树；你看到的只是当前暂停线程的调用栈，其他线程藏在后台，不点不开。
- 断点触发后，按
Ctrl+Shift+P→ 输入Java: Show Threads View，或点击 DEBUG 面板左上角Threads图标 - 列表中灰色文字的是 JVM 内部线程（如
Monitor Ctrl-Break），忽略；重点看RUNNABLE、WAITING、BLOCKED状态的业务线程 - 如果某线程始终不出现，大概率它已退出，或根本没
submit()到ExecutorService—— 检查任务提交逻辑，而非调试配置
在 sleep/wait 上设断点毫无意义
Thread.sleep()、Object.wait()、LockSupport.park() 是原子阻塞调用，断点打在它们上面永远不会命中。你真正需要的是阻塞前的状态快照或唤醒后的执行路径。
- 断点应放在阻塞调用的前一行（例如
log.info("about to wait on lock");）和后一行（例如log.info("lock acquired");） - 对
wait()，确保断点在synchronized块内、且在wait()调用之前，否则因未持有锁而直接抛IllegalMonitorStateException - 若线程卡在
WAITING (on object monitor)，点击该线程 → 查看其调用栈顶部的waiting on地址 → 切到其他线程搜索这个地址，就能定位谁正持有该锁
虚拟线程（Virtual Threads）要额外开 JFR 并手动采集
VSCode 默认的 Threads 面板只显示 OS 线程和普通 Java 线程，虚拟线程（Loom）不会自动列出来——它们被调度器映射到少量 carrier 线程上，必须靠 JFR 数据显式提取。
- 启动应用时加参数：
-XX:+EnablePreview -XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=recording.jfr - 在 VSCode 中按
Ctrl+Shift+P→Java: Open Flight Recorder→ 选择对应进程 - 打开 recording.jfr 后，在
Threads标签页下勾选Show virtual threads，才能看到VirtualThread-1类型条目及其生命周期事件 - 注意：JFR 录制本身有开销，生产环境慎用；开发阶段用它定位虚拟线程泄漏比轮询
Thread.activeCount()可靠得多
最常被忽略的一点：VSCode 的 Java 调试器对虚拟线程的堆栈支持仍有限——它能显示虚拟线程存在，但无法像 OS 线程那样完整渲染其挂起位置（尤其在 park 或 I/O 暂停时）。此时必须结合 JFR 的 jdk.VirtualThreadPinned 和 jdk.VirtualThreadSubmitFailed 事件交叉验证。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
