我们知道，Java中的轻量级锁是基于CAS的，CAS是不走系统调用的，是在用户态的代码中“插入” cmpxchg 汇编指令，由这种CPU原语性质的汇编指令保证原子性。所以整体来看一直是在用户态代码中执行，而没有走入内核的代码。没有用户态/内核态之间的上下文切换。

而重量级锁才是进行了系统调用、用户态代码发起系统调用向内核申请mutex互斥量，CPU接着执行进入内核代码、内核代码进行了后续的高低电位锁总线等一系列硬件操作，最后互斥的设置了一个内存中的标志位称为互斥锁，然后把这个锁返回给了用户态代码。这个过程中当然是有上下文/用户态内核态切换的。

重量级锁可以理解为是大致这么一个关系：

**synchronized（Java代码） -> Monitor（JVM底层C++） -> mutex（内核维护） **

最底层是mutex，是内核维护的内存标志，外部使用需要走系统调用，然后再上一层是JVM在mutex这个同步原语的基础上进行了封装，提供了所谓Monitor监视器对象机制，然后再上层是Java语言，通过synchronized关键字进行同步操作来保护临界区代码段、当锁升级膨胀为重量级锁的时候就是使用监视器锁了，对应的进出临界区的字节码指令是monitorenter和monitorexit，这俩是由c++编写的代码逻辑，新版的jdk有所谓锁升级的一个优化逻辑（偏向锁 -> 轻量锁 -> 重量锁）。而旧版的jdk的内置锁直接就使用操作系统的互斥量，要进行用户态到内核态的切换。

更多的关于监视器锁可以参考：java并发系列-monitor机制实现 - 青衫执卷 - 博客园 (cnblogs.com)

Java 中的 Monitor 机制 - SegmentFault 思否

锁膨胀升级相关C++代码：

void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) {
	markOop mark = obj->mark();
	if (mark->is_neutral()) {
		// 将目前的Mark Word复制到Displaced Header上
		lock->set_displaced_header(mark);
		// 利用CAS设置对象的Mark Word
		if (mark == obj()->cas_set_mark((markOop) lock, mark)) {
			TEVENT(slow_enter: release stacklock);
			return;
		}
	// 检查存在竞争
	} else if (mark->has_locker() && THREAD->is_lock_owned((address)mark->locker())) {
		// 清除
		lock->set_displaced_header(NULL);
		return;
	}

  // 重置Displaced Header
  lock->set_displaced_header(markOopDesc::unused_mark());
  ObjectSynchronizer::inflate(THREAD, obj(), inflate_cause_monitor_enter)->enter(THREAD);
}

关于synchronized的底层，更多可以参考 JDK成长记15：从0分析你不知道的synchronized底层原理（上） - _繁茂 - 博客园 (cnblogs.com)