Java无法通过AOP拦截synchronized，因其是JVM原语，不经过方法调用栈；AOP仅拦截public方法入口/出口，而synchronized锁竞争发生在monitorenter指令层面，线程BLOCKED状态由JVM内部调度，无Java回调。
Java 无法直接通过 AOP 拦截 synchronized 关键字的加锁/等待行为，因为 synchronized 是 JVM 层面的原语，不经过方法调用栈，AOP（如 Spring AOP）基于代理机制，只能拦截**public 方法调用**，对 synchronized 块、synchronized 静态方法或非 public 方法中的同步逻辑完全不可见。
为什么标准 AOP 无法切到 synchronized 等待过程
核心原因有三点：
- Spring AOP 默认使用 JDK 动态代理或 CGLIB，只作用于方法入口/出口，而
synchronized的锁竞争发生在字节码层面（monitorenter/monitorexit 指令），不在方法调用链上； - 线程在获取不到锁时会进入
BLOCKED状态，该过程由 JVM 内部调度，不触发任何 Java 方法回调； - AOP 无法感知线程状态变化、锁队列排队、自旋等待等底层行为。
可行的替代方案：用 ReentrantLock + AOP 统计等待时间
若目标是「可观测锁等待耗时」，推荐将 synchronized 替换为 java.util.concurrent.locks.ReentrantLock，它支持显式、可监控的锁操作：
- 使用
lock.tryLock(long timeout, TimeUnit unit)可捕获等待是否超时； - 配合 AOP 在
lock()前记录开始时间，在unlock()后计算耗时； - 更精确的做法：用
lock.getQueueLength()或hasQueuedThreads()辅助判断竞争程度。
示例切面逻辑（统计 lock() 调用的阻塞等待时间）：
立即学习“Java免费学习笔记（深入）”；
@Around("execution(* com.example.service..*.lockWithTimeout(..))")
public Object measureLockWaitTime(ProceedingJoinPoint joinPoint) throws Throwable {
long start = System.nanoTime();
try {
return joinPoint.proceed();
} finally {
long durationNs = System.nanoTime() - start;
if (durationNs > 1_000_000) { // 超过 1ms 记录
log.warn("Lock wait time: {} ms", TimeUnit.NANOSECONDS.toMillis(durationNs));
}
}
}
注意：需确保业务方法中调用的是带超时的 tryLock，并在 finally 中 unlock —— 这样 AOP 才能包裹整个“尝试获取锁”的过程。
进阶方案：JVM 级监控（无需改代码）
若必须保留 synchronized 且不能改源码，可通过 JVM 工具间接观测：
-
jstack：定期抓取线程快照，搜索
java.lang.Thread.State: BLOCKED (on object monitor)，结合堆栈定位锁对象和等待线程； -
JFR（Java Flight Recorder）：开启
LockDuration和MonitorEnter事件，可记录 synchronized 锁的争用、持有、等待时长（JDK 11+ 原生支持，JDK 8 需借助 JMC 插件）； -
JMX + ThreadMXBean：调用
getThreadInfo(ids, true, true)获取线程的 blockedTime 和 blockedCount，反映累计阻塞情况（精度为毫秒级，且仅限当前已阻塞完成的线程）。
不推荐但技术上可行：字节码插桩（如 Byte Buddy / ASM）
在类加载时修改字节码，在每个 monitorenter 前插入计时逻辑，在 monitorexit 后计算差值。但这属于重型方案：
- 需处理重入锁、异常路径、锁升级（偏向→轻量→重量）等复杂场景；
- 可能影响 JIT 编译和性能，调试困难；
- 仅建议用于诊断工具（如 Arthas 的
trace命令底层就依赖类似机制），不适合生产常驻监控。
总之，想动态统计 synchronized 锁等待时长，最务实的做法是：优先迁移到 ReentrantLock 并结合 AOP；无法改动时，用 JFR 或 jstack 辅助分析；避免强行用 AOP “硬套” synchronized。
