synchronized 在 JDK 1.5 之前性能是比较低的，在那时我们通常会选择使用 Lock 来替代 synchronized。然而这个情况在 JDK 1.6 时就发生了改变，JDK 1.6 中对 synchronized 进行了各种优化，性能也得到了大幅的提升，这也是目前版本中还能经常见到 synchronized 身影的重要原因之一。当然除了性能之外，synchronized 的使用也非常便利，这也是它流行的重要原因。
在众多优化方案中，锁膨胀机制是提升 synchronized 性能最有利的手段之一（其他优化方案我们后面再讲），本文我们重点来看什么是锁膨胀？以及锁膨胀的各种细节。
在 JDK 1.5 时，synchronized 需要调用监视器锁（Monitor）来实现，监视器锁本质上又是依赖于底层的操作系统的 Mutex Lock（互斥锁）实现的，互斥锁在进行释放和获取的时候，需要从用户态转换到内核态，这样就造成了很高的成本，也需要较长的执行时间，这种依赖于操作系统 Mutex Lock 实现的锁我们称之为“重量级锁”。
用户态（User Mode）：当进程在执行用户自己的代码时，则称其处于用户运行态。
内核态（Kernel Mode）：当一个任务（进程）执行系统调用而陷入内核代码中执行时，我们就称进程处于内核运行态，此时处理器处于特权级最高的内核代码中执行。
假设没有内核态和用户态之分，程序就可以随意读写硬件资源了，比如随意读写和分配内存，这样如果程序员一不小心将不适当的内容写到了不该写的地方，很可能就会导致系统崩溃。
而有了用户态和内核态的区分之后，程序在执行某个操作时会进行一系列的验证和检验之后，确认没问题之后才可以正常的操作资源，这样就不会担心一不小心就把系统搞坏的情况了，也就是有了内核态和用户态的区分之后可以让程序更加安全的运行，但同时两种形态的切换会导致一定的性能开销。
在 JDK 1.6 时，为了解决获取锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”的状态，此时 synchronized 的状态总共有以下 4 种：
无锁
偏向锁
轻量级锁
重量级锁
锁的级别按照上述先后顺序依次升级，我们把这个升级的过程称之为“锁膨胀”。
PS：到现在为止，锁的升级是单向的，也就是说只能从低到高升级（无锁 -> 偏向锁 -> 轻量锁锁 -> 重量级锁），不会出现锁降级的情况。
锁膨胀为什么能优化 synchronized 的性能？当我们了解了这些锁状态之后自然就会有答案，下面我们一起来看。
HotSpot 作者经过研究实践发现，在大多数情况下，锁不存在多线程竞争，总是由同一线程多次获得的，为了让线程获得锁的代价更低，于是就引进了偏向锁。
偏向锁（Biased Locking）指的是，它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，这种情况下会给线程加一个偏向锁。
当一个线程访问同步代码块并获取锁时，会在对象头的 Mark Word 里存储锁偏向的线程 ID，在线程进入和退出同步块时不再通过 CAS 操作来加锁和解锁，而是检测 Mark Word 里是否存储着指向当前线程的偏向锁，如果 Mark Word 中的线程 ID 和访问的线程 ID 一致，则可以直接进入同步块进行代码执行，如果线程 ID 不同，则使用 CAS 尝试获取锁，如果获取成功则进入同步块执行代码，否则会将锁的状态升级为轻量级锁。
偏向锁是为了在无多线程竞争的情况下，尽量减少不必要的锁切换而设计的，因为锁的获取及释放要依赖多次 CAS 原子指令，而偏向锁只需要在置换线程 ID 的时候执行一次 CAS 原子指令即可。
在 HotSpot 虚拟机中，对象在内存中存储的布局可以分为以下 3 个区域：
对象头（Header）
实例数据（Instance Data）
对齐填充（Padding）
对象头中又包含了：
Mark Word（标记字段）：我们的偏向锁信息就是存储在此区域的。
Klass Pointer（Class 对象指针）