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免费学习笔记（深入）”；
- 打开“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%以上的锁竞争问题。
