从字节码到对象头：synchronized 如何实现？

昨天晚上，和几个朋友撸串，聊着聊着就跑题到 JVM 了（程序员聚会的经典套路）。喝了点啤酒，突然有人抛来一句："你们真的懂 synchronized 怎么实现的吗？不是就是加个锁嘛，有啥难的。"我差点被辣椒呛到，哎呀，这话要是在网友面前说出来，分分钟被锤成铁渣！

其实，synchronized 的实现真没那么傻瓜，表面看着一个关键词，背后那套骚操作，多了去了。正好今天就顺着喝酒那点后劲，来一波随性的八卦，和你讲讲 synchronized 从 Java 源码，一路飞到字节码，从 HotSpot 的对象头里掏出那些暗藏的小心思。

还记得刚入门的时候，我天真地以为 synchronized 就是把代码"包起来"，线程就乖乖排队了。比如这样：

java 复制代码

synchronized (obj) {
    // 神奇的线程安全地带
}

每次用了 synchronized，总有种靠关键词发号施令的错觉。但后来我才发现，JVM 压根不惯着你，偷偷在背后做了好多事。

那天喝高了，回来翻 JVM 指令表，发现 synchronized 原来是变身成 monitorenter 和 monitorexit 这俩指令的。哎，不看真不信：

java 复制代码

// 伪代码哈，其实 javap 看下就明白了
monitorenter
// 同步块的内容......
monitorexit

所以 synchronized 本质是"墩上锁"（monitorenter），走的时候"松开锁"（monitorexit）。关键是，锁不是凭空出来的------而是藏在对象头（object header）里。

对象头是什么？你想象成每个 Java 对象头顶都顶着块"砖头"，这块砖里藏着很多秘密------Mark Word 就是最爱搞事情的那个。

Mark Word 里记录了锁的状态，比如：

不同的加锁方式，其实就是 Mark Word 换了种写法。拿锁其实就是 Mark Word 在变魔术------偏向锁、轻量级锁，最后不得不升级成咣咣互斥的大锁（重量级），才用到操作系统的 Mutex。

别说，早期自己写多线程，还真翻过车。下面几件事，堪称"听我踩坑少走弯路"系列：

升级锁的时候，发现性能突然闪崩。一查，原来竞争太激烈，锁直接升级为重量级，线程全都在那等队，场面一度失控。
synchronized 修饰方法和修饰代码块的区别。朋友好奇，method-level 和 block-level 有啥区别？一试，锁住对象还是锁住 class，可千万别搞混，不然 debug 吐血。
分布式场景下误用 synchronized，哈哈，发现压根没啥卵用：JVM 内部锁，跨进程它不管！

其实 synchronized 在 HotSpot 下不是一上来就是大锁。JVM 精于算计，能"偏向"就不"加大锁"，能"小打小闹"绝不"动手术"：

这些升级/降级，完全靠 Mark Word 这一块砖反复雕花。

踩过不少"锁"的坑，我个人现在有几条牢骚建议：

唉，说了这么多，synchronized 就是个看似"关键词"，实则背后牵扯到字节码、对象头、Mark Word、锁升级的"大工程"。

很多初学者会觉得它就是个"铁门"，进出靠排队。但你真把门板掀开，发现里面塞满了机关暗道：轻量级、偏向、重量级，能耍的花样一堆。

所以啊，synchronized 是好用，但不代表无脑用：

如果只是单线程逻辑或者无共享状态，完全没必要搞锁，反而多此一举。

在高并发场景，滥用 synchronized 就等于把高速公路硬生生改成单行线，拥堵那是必然的。

调优的时候别怕去看字节码、对象头、JVM 参数，很多玄学性能问题，其实都是 JVM 在背后偷偷搞小动作。

最后一句：理解 synchronized，不是为了炫技，而是让你写多线程代码时心里有底。不然真到线上出幺蛾子，你会怀疑人生。