Java锁竞争主要通过JVM内置工具监控：JFR捕获monitor-enter/monitor-park事件识别长等待；jstack定位“waiting to lock”与“locked”线程；JConsole/VisualVM观察BLOCKED线程及死锁；GC日志辅助发现Safepoint停顿异常。

Java里的锁竞争主要通过运行时事件采集和线程状态分析来监控，核心手段是利用JVM内置的诊断工具，而不是靠代码日志或手动埋点。

用JFR捕获锁相关事件

JDK Flight Recorder（JFR）是监控锁竞争最直接、开销最低的官方方案。它能持续记录虚拟线程和平台线程在锁上的行为：

• 关注 jdk.monitor-enter 事件：记录每次尝试进入 synchronized 块的时间点和持续时长
• 关注 jdk.monitor-park 事件：反映线程因争不到锁而挂起的等待时间
• 若某类事件平均耗时超过 1ms 或频繁出现 >5ms 的长等待，基本可判定存在严重锁竞争

用jstack查看阻塞线程堆栈

对正在运行的Java进程执行 jstack ，能快速定位锁竞争现场：

• 搜索 "waiting to lock"：找到正在排队等锁的线程及其目标锁对象地址
• 搜索 "locked"：定位当前持有该锁的线程及它所处的代码行
• 若多个线程反复在同一个锁地址上等待，说明该锁是瓶颈点

用JConsole或VisualVM观察线程视图

图形化工具适合实时观察趋势：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

立即学习“Java免费学习笔记（深入）”；

• 打开“Threads”页签，查看“Deadlock”检测结果（虽不能发现所有竞争，但能抓到死锁）
• 留意“Thread State”列中大量线程处于 BLOCKED 状态，且都指向同一 Object Monitor
• 结合“CPU Usage”曲线，若CPU不高但线程阻塞率高，大概率是锁竞争而非计算瓶颈

用-XX:+PrintGCDetails配合锁日志（辅助判断）

虽然不是专为锁设计，但在高竞争场景下会间接暴露问题：

• 开启 -XX:+PrintGCDetails -XX:+PrintSafepointStatistics 后，若频繁出现 Safepoint 停顿且 “no vm operation” 占比高，常意味着大量线程卡在 monitor enter
• 搭配 -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -Xlog:monitoring=debug（JDK 10+）可输出更细粒度的监视器活动日志

基本上就这些。不需要改代码，也不依赖第三方库，JDK自带工具链已足够定位90%以上的锁竞争问题。