Java死锁快速确认依赖ThreadMXBean.findDeadlockedThreads()，它仅检测Object monitor和ReentrantLock两类锁，返回线程ID需配合getThreadInfo()获取堆栈，且频繁调用有性能开销。
Java死锁怎么快速确认是ThreadMXBean.findDeadlockedThreads()在起作用
JDK自带的死锁检测能力就藏在这个接口里，但它默认不触发自动报警，得你主动调用。很多线上问题排查时反复看thread dump却漏掉死锁，就是因为没意识到这个API才是“真·检测入口”。
常见错误现象：jstack -l <pid></pid>输出里出现Found 1 deadlock.，但自己写的监控脚本没报，说明没走findDeadlockedThreads()逻辑。
- 它只检测
Object monitor和java.util.concurrent.Lock两类锁，synchronized和ReentrantLock覆盖了，但StampedLock或自定义AQS实现不在此列 - 返回的是线程ID数组，不是
Thread对象，要配合ThreadMXBean.getThreadInfo()才能拿到堆栈 - 频繁调用有性能开销（需全局暂停所有线程），别放在高频监控循环里，建议5分钟以上间隔
用jcmd <pid> VM.native_memory summary</pid>辅助判断死锁是否引发内存卡死
死锁本身不直接吃内存，但被卡住的线程如果还在反复申请堆外资源（比如Netty的PooledByteBufAllocator），就可能触发本地内存耗尽——这时候OutOfMemoryError: Direct buffer memory会掩盖真正的死锁根源。
使用场景：服务响应变慢、GC正常但RSS持续上涨、jstack显示大量线程停在Unsafe.park，这时就要查原生内存。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
VM.native_memory summary比-XX:NativeMemoryTracking=detail轻量，生产环境可随时跑 - 重点关注
Internal和Other区域增长，这两块常藏线程私有缓冲区泄漏 - 若
Internal占比突增且线程数稳定，大概率是某类锁等待导致缓冲区堆积（比如Kafka消费者线程卡在poll()前的锁上，但心跳缓冲还在分配）
为什么ReentrantLock.tryLock(long, TimeUnit)加超时不能彻底防死锁
加了超时只是让单次获取失败，不代表逻辑安全。很多人以为用了tryLock就高枕无忧，结果在线程复用场景下（比如线程池+异步回调），失败后没清理前置已持有的锁，反而制造出更难追踪的“伪死锁”。
参数差异：tryLock(1, SECONDS)和tryLock(100, MILLISECONDS)看似只是单位不同，但前者在锁竞争激烈时更容易因调度延迟误判为超时。
- 必须配对使用
lockInterruptibly()或显式unlock()，否则finally块里没写unlock()，一次超时就会让锁永远滞留 - 多个锁按固定顺序获取仍是硬要求，
tryLock不解决顺序问题，只解决“等多久”的问题 - Spring的
@Transactional底层用ReentrantLock时，若传播行为是REQUIRES_NEW，嵌套事务可能触发同一线程重复获取锁，此时tryLock超时反而掩盖了设计缺陷
jfr start --settings profile --duration 60s抓取死锁现场时最常忽略的三个配置点
JFR能录到死锁发生前200ms的线程状态变化，但默认配置下大概率录不到关键帧——不是工具不行，是开关没拧对。
容易踩的坑：只开profile模板，却没启用jdk.ThreadPark和jdk.JavaMonitorEnter事件，导致只能看到线程停在哪行代码，看不到它在等哪个锁对象。
- 必须加
--event jdk.JavaMonitorEnter#enabled=true，否则synchronized锁等待不记录 -
--event jdk.ReentrantLockLock#enabled=true单独开启，profile模板默认不包含它 -
--disk=false强制内存录制，避免I/O延迟错过死锁瞬间；但要注意JVM堆外内存占用会临时增加约50MB
findDeadlockedThreads()返回空，但业务明显卡死，这时候得想到StampedLock或JNI层锁不在检测范围内；又或者JFR里看到线程在park，但锁对象ID对不上任何monitor记录，那八成是AbstractQueuedSynchronizer的state字段被多处修改，得翻源码对齐CAS逻辑。 
