1. 从黑盒到白盒：synchronized与Monitor的纠缠关系
第一次用jstack看线程堆栈时，那个神秘的"monitor"状态让我困惑了很久。作为Java开发者，我们每天都在用synchronized关键字，但有多少人真正掀开过它的底盖？今天我们就用手术刀级别的精度，解剖这个看似简单实则精妙的设计。
synchronized在JVM内部是通过Monitor机制实现的，这种设计借鉴了操作系统中的管程(Monitor)概念。但Java的Monitor不是简单的互斥量，而是一个复杂的同步子系统。当线程进入synchronized块时，JVM会在对象头中的Mark Word里记录Monitor的指针，这个细节我们稍后会详细展开。
关键认知：每个Java对象都"天生"带有一把锁，但只有在被synchronized修饰时才会真正启用Monitor机制
2. Monitor的三大核心组件解析
2.1 对象头中的秘密战场
在HotSpot虚拟机中，对象头(Object Header)包含两部分：Mark Word和类型指针。其中Mark Word在同步机制中扮演关键角色，它的结构会随着锁状态变化而动态改变：
code复制| 锁状态 | 存储内容 |
|--------------|-----------------------------------|
| 无锁 | 对象的hashCode等 |
| 偏向锁 | 持有偏向锁的线程ID |
| 轻量级锁 | 指向栈中锁记录的指针 |
| 重量级锁 | 指向Monitor对象的指针 |
| GC标记 | 空(不需要记录信息) |
当锁升级为重量级锁时，Mark Word中的指针会指向一个Monitor对象。这个对象由C++实现，存在于JVM的堆外内存中。
2.2 MonitorObject的C++实现
在HotSpot源码中，Monitor的实现主要在objectMonitor.hpp文件中。其核心字段包括：
cpp复制class ObjectMonitor {
volatile markOop _header; // 存储原始对象头
void* volatile _owner; // 持有锁的线程
volatile jlong _previous_owner_tid; // 前一个持有者线程ID
volatile intptr_t _recursions; // 重入次数
ObjectWaiter* volatile _EntryList; // 等待获取锁的线程队列
ObjectWaiter* volatile _cxq; // 竞争队列
Thread* volatile _succ; // 假定继承者
// ...其他辅助字段
};
其中_EntryList和_cxq两个队列的交互逻辑最为复杂，它们共同构成了Monitor的等待机制。
2.3 线程状态的转换路径
当线程尝试获取Monitor时，会经历以下状态转换：
- 新请求的线程首先通过CAS尝试设置_owner字段
- 失败后进入_cxq竞争队列（采用头插法）
- 当持有锁的线程释放时，会根据策略将_cxq中的线程转移到_EntryList
- 从_EntryList中唤醒线程尝试获取锁
这个过程中存在多个临界区，需要非常精细的同步控制。我在分析jstack日志时发现，很多死锁问题都源于对这些队列状态的误解。
3. synchronized的完整生命周期
3.1 锁的膨胀过程
JVM会根据竞争情况自动升级锁状态，这是Java同步机制最精妙的设计之一：
- 偏向锁：单线程访问时，直接在对象头记录线程ID
- 轻量级锁：少量竞争时，通过CAS和栈帧中的锁记录实现
- 重量级锁：高竞争时，升级为Monitor机制
通过-XX:+PrintFlagsFinal可以看到控制这些行为的参数：
bash复制intx BiasedLockingStartupDelay = 4000
bool UseBiasedLocking = true
bool UseHeavyMonitors = false
3.2 内存语义的实现细节
synchronized的内存语义通过两个关键操作实现：
- monitorenter：获取锁，对应内存屏障
- monitorexit：释放锁，保证可见性
在字节码层面，一个同步块会被编译为：
code复制monitorenter
try {
// 同步代码
} finally {
monitorexit
}
但实际JVM实现比这复杂得多。我在用HSDIS反汇编时发现，x86架构下会插入lock cmpxchg指令来实现原子操作。
3.3 重量级锁的性能陷阱
虽然Monitor提供了强大的同步能力，但也带来显著开销：
- 系统调用：竞争激烈时会触发线程挂起/唤醒
- 缓存失效：Monitor对象在不同CPU核间迁移
- 上下文切换：等待队列的调度开销
通过perf工具可以观察到这些开销：
bash复制perf stat -e context-switches,cpu-migrations java MyApp
4. 实战中的Monitor问题排查
4.1 jstack日志分析技巧
当应用出现线程阻塞时，jstack是最直接的诊断工具。关键要识别这些状态：
- "BLOCKED (on object monitor)"：等待获取Monitor
- "WAITING (on object monitor)"：调用了wait()
- "PARKING"：可能使用了更现代的并发工具
示例分析：
code复制"Thread-1" #12 prio=5 os_prio=0 tid=0x00007f487c0b5000 nid=0x5e1e waiting for monitor entry [0x00007f486b7fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.example.MyClass.syncMethod(MyClass.java:42)
- waiting to lock <0x000000076e9d8e58> (a java.lang.Object)
4.2 避免Monitor滥用的设计模式
根据我的项目经验，这些模式可以降低对重量级锁的依赖：
- 分段锁：ConcurrentHashMap的风格
- 读写分离：CopyOnWriteArrayList的思路
- 无锁算法：Atomic类的CAS操作
- 线程封闭：ThreadLocal的应用
特别提醒：不要为了"性能优化"而盲目去掉必要的同步，线程安全永远是第一位的。
5. 从JVM源码看Monitor实现
5.1 关键函数调用链
在HotSpot源码中，锁获取的主要路径：
- InterpreterRuntime::monitorenter
- ObjectSynchronizer::fast_enter
- ObjectSynchronizer::slow_enter
- ObjectMonitor::enter
其中slow_enter是重量级锁的入口，它会调用：
cpp复制void ObjectMonitor::enter(TRAPS) {
Thread * const Self = THREAD;
// 尝试快速获取锁
if (TryLock(Self) > 0) return;
// 尝试自旋获取
if (TrySpin(Self) > 0) return;
// 进入完整锁获取流程
EnterI(THREAD);
}
5.2 EnterI的完整流程
EnterI方法是Monitor实现的核心，其伪代码如下：
- 将当前线程包装为ObjectWaiter节点
- 通过CAS将节点插入_cxq队列
- 根据策略可能旋转等待一段时间
- 最终通过park()挂起线程
这个过程中有多个竞争点，需要处理各种边界条件，代码复杂度相当高。
6. 现代JVM的优化方向
随着Java并发模型的发展，Monitor机制也在持续进化：
- 偏向锁撤销优化：JEP 374移除了偏向锁延迟
- 自旋策略改进：自适应自旋代替固定次数
- 等待机制优化：Safepoint与Monitor的协同
通过-XX:+PrintBiasedLockingStatistics可以看到偏向锁的统计信息，这对调优很有帮助。
在实际项目中，我发现这些JVM参数对同步性能影响最大：
bash复制-XX:+UseSpinning
-XX:PreBlockSpin=10
-XX:+UseBiasedLocking
最后分享一个诊断技巧：当怀疑Monitor竞争导致性能问题时，可以用async-profiler抓取lock样本：
bash复制./profiler.sh -d 60 -e lock -f profile.html <pid>