用jstack定位死锁需执行jstack -l ，关注末尾“found 1 deadlock”区块，明确列出互持/等待线程、锁地址及阻塞位置；注意权限与容器命名空间问题。
如何用jstack定位死锁线程
Java程序卡住、CPU不高但响应停滞，第一反应该看是否发生了死锁。jstack 是最轻量也最直接的工具，不需要改代码、不依赖IDE。
执行 jstack -l <pid></pid>（-l 表示输出锁信息），重点关注输出末尾的 Found 1 deadlock. 区块。它会明确列出互相持有和等待的线程、锁对象地址、以及阻塞在哪个 synchronized 块或 Lock.lock() 调用上。
- 注意：
jstack必须由与目标JVM相同用户运行，否则可能无权限；容器内需进到对应进程命名空间再执行 - 如果没看到
Found deadlock，不代表没锁竞争——只是没构成循环等待，此时要结合Thread.State: BLOCKED线程堆栈，人工追踪锁对象（如- waiting to lock）被谁持有 - 使用
jstack -l <pid> > thread.log</pid>保存快照，多次采样对比可发现“锁持有时间异常增长”的线索
为什么ThreadLocal变量在线程池中会引发脏数据
ThreadLocal 本身不是问题，问题出在复用线程时未清理。线程池中的线程长期存活，ThreadLocal 变量若没显式 remove()，下一次任务执行时可能读到上一个请求遗留的值。
典型表现是：HTTP请求间出现用户ID错乱、数据库连接配置污染、日志MDC上下文串号等。
立即学习“Java免费学习笔记（深入）”；
- 必须在业务逻辑结束前调用
threadLocal.remove()，不能只靠set(null)——后者不释放底层Entry，还可能导致内存泄漏 - 在 Spring 环境中，优先用
@Scope("prototype")Bean 或RequestContextHolder替代手动管理ThreadLocal - 若必须用，建议封装成工具类，在
try-finally中强制remove()：try { userIdHolder.set(userId); doWork(); } finally { userIdHolder.remove(); // 关键：不能省略 }
如何用jcmd触发Java Flight Recorder（JFR）录制并发行为
当问题偶发、无法稳定复现，又需要观察线程状态切换、锁竞争、GC对并发的影响时，jcmd + JFR 比 jstack 更有力——它能持续采集数分钟内的底层事件，且开销可控（默认
先确认JVM启动时已启用JFR：-XX:+FlightRecorder（JDK8u262+ / JDK11+ 默认开启）。然后执行：
jcmd <pid> VM.unlock_commercial_features jcmd <pid> JFR.start name=concurrent duration=120s settings=profile
录制结束后用 jcmd <pid> JFR.dump name=concurrent filename=recording.jfr</pid> 导出，用 JDK 自带的 JDK Mission Control 打开分析。
-
settings=profile启用低开销采样，包含线程状态、锁持有时长、ForkJoinPool任务队列深度等关键指标 - 避免用
duration=0长期录制，JFR 内存缓冲区有限，可能丢事件；建议按场景设定 30–180 秒窗口 - 特别关注 “Monitor Blocked” 和 “Java Monitor Wait” 事件的频次与堆栈，比单纯看线程 dump 更容易定位热点锁
排查CompletableFuture链式调用丢失异常的常见盲点
CompletableFuture 的异步链中，若中间某个 thenApply 或 thenAccept 抛出异常但没被 exceptionally 或 handle 捕获，异常会被静默吞掉——主线程收不到，日志也不打，只剩任务“消失”。这是并发调试中最隐蔽的失败模式之一。
- 所有非终端操作（
thenRun,thenApply,thenCompose）都必须配对exceptionally，或统一用handle处理结果与异常：future.thenApply(data -> process(data)) .exceptionally(ex -> { log.error("process failed", ex); return fallbackValue; }); - 不要依赖
join()或get()捕获异常——它们只能捕获最终阶段的异常，中间阶段失败会导致整个链提前终止且无提示 - 在测试中主动注入异常（如用
completeExceptionally(new RuntimeException())）验证错误处理路径是否真实生效
实际并发问题往往不是单点故障，而是多个条件叠加：线程池饱和 + ThreadLocal未清理 + CompletableFuture异常静默 + 锁竞争加剧。调试时别急于加日志，先用 jstack 看住线程状态，用 jcmd + JFR 看清锁和任务流转，最后才深入代码逻辑。最容易被忽略的是——你以为的“异步完成”，其实早在线程池拒绝策略或 ForkJoinPool 工作窃取机制里就断掉了。
