Java中的synchronized本质上是通过操作系统层面的互斥锁（Mutex Lock）实现的，具体依赖于内核态的系统调用和CPU的硬件原子指令。
一、底层实现层级
Java代码层: synchronized方法/代码块 ↓ JVM层: Monitor（管程） - 包含_owner、_EntryList、_WaitSet等 ↓ 操作系统层: 互斥锁（Mutex） + 条件变量（Condition Variable） ↓ 硬件层: CPU原子指令（如x86的CMPXCHG） + 内存屏障二、操作系统层面的具体机制
1.内核态互斥锁（Mutex）
- 当发生锁竞争时，线程会从用户态切换到内核态
- 通过Linux的
futex（Fast Userspace muTEX）机制实现// futex系统调用longsyscall(SYS_futex,uint32_t*uaddr,intop,uint32_tval,...); - Windows通过
CRITICAL_SECTION和Event对象实现
2.线程阻塞与唤醒
- 阻塞：通过系统调用将线程放入等待队列（如
pthread_mutex_lock） - 唤醒：通过系统调用从等待队列中唤醒线程（如
pthread_mutex_unlock） - 涉及上下文切换，开销较大
三、JVM的具体实现
1.对象头中的Mark Word
|--------------------------------------------------------------| | Mark Word (64 bits) | State | |--------------------------------------------------------------| | unused:25 | identity_hashcode:31 | unused:1 | age:4 | biased_lock:0 | 01 | Normal | | thread:54 | epoch:2 | unused:1 | age:4 | biased_lock:1 | 01 | Biased | | ptr_to_lock_record:62 | 00 | Lightweight Locked | | ptr_to_heavyweight_monitor:62 | 10 | Heavyweight Locked | | | 11 | Marked for GC |2.锁升级过程
// 示例代码publicclassSyncExample{privatefinalObjectlock=newObject();publicvoidmethod(){synchronized(lock){// 锁状态变化// 临界区}}}锁升级流程：
无锁 (01) ↓ 线程首次进入 偏向锁 (01) - 仅记录线程ID，避免CAS ↓ 有竞争 轻量级锁 (00) - 通过CAS自旋尝试获取锁 ↓ 自旋失败/长时间竞争 重量级锁 (10) - 调用操作系统互斥锁四、重量级锁的系统调用过程
// 伪代码展示重量级锁的获取过程voidObjectMonitor::enter(){// 1. 尝试快速获取（CAS）if(CAS(&_owner,NULL,Self)==success)return;// 2. 检查是否重入if(_owner==Self){_recursions++;return;}// 3. 自旋尝试if(TrySpin(Self))return;// 4. 进入内核态等待（真正的系统调用）EnterI();// 调用futex_wait或类似机制}五、性能特点
| 锁状态 | 实现方式 | 开销 | 适用场景 |
|---|---|---|---|
| 偏向锁 | CAS修改Mark Word | 最小 | 单线程访问 |
| 轻量级锁 | 自旋+CAS | 中等 | 低竞争、短临界区 |
| 重量级锁 | 系统调用+内核阻塞 | 最大 | 高竞争、长临界区 |
六、关键系统调用示例
在Linux上，最终可能调用：
# 使用strace跟踪系统调用strace-fjavaYourClass2>&1|grep-E"futex|pthread"# 典型输出futex(0x7f8b380008c8, FUTEX_WAIT_PRIVATE,1, NULL)# 线程阻塞futex(0x7f8b380008c8, FUTEX_WAKE_PRIVATE,1)# 线程唤醒七、总结要点
- 核心机制：
synchronized的最终保障是操作系统的互斥锁 - 优化策略：JVM通过锁升级减少进入内核态的代价
- 关键成本：用户态↔内核态切换、上下文切换
- 适用性：重量级锁适合保护复杂操作，不适合高频短操作
这就是为什么ReentrantLock在某些场景下性能更好——它提供了更灵活的API和优化策略，但底层同样依赖于类似的系统机制。
