synchronized是Java原生提供的用于在多线程环境中保证同步的关键字，底层是通过修改对象头中的MarkWord来实现的。
synchronized锁住的Monitor对象就存在于对象头之中。对象头又分为：Mark Word、指向类的指针、数组长度（数组对象）。
对象头在Hotspot虚拟机实现中，对象头的Mark Word位格式在32位机器中是32位长，在64位机器中是64位长（采用 big endian ，低地址存放最高有效字节，即低位在左，高位再右）。
synchronized凭借的就是Monitor锁住的对象，Monitor又是借助于操作系统的mutex lock，之所以它重是因为它被挂起后线程会由用户态转换为内核态，这个转换会带来性能损耗。JDK6开始对其进行了优化，提出了偏向锁和轻量级锁，针对锁竞争较为激烈的场景不会直接去获取Monitor对象，减少性能损耗。因此在现如今的synchronized实现中，它的性能劣势也已不再那么明显。
偏向锁
上面提到了JDK6过后优化了synchronized的加锁过程，尽量使得synchronized不再那么重。偏向锁即是如此。
JVM的研究者表明，大多数情况下锁的竞争不是那么激励，在不那么激励的时候如果通过获取Monitor来进行同步访问，会造成线程在操作系统用户态和核心态的转换，这会使得系统性能下降。偏向锁表示，当只有一个线程进入同步方法或同步代码块时，并不会直接获取Monitor锁，而是先判断对象头中Mark Word部分的锁标志位是否处于“01”，如果处于“01”，此时再判断线程ID是否是本线程ID，如果是则直接进入方法进行后续操作；如果不是，此时则通过CAS无锁机制竞争，如果竞争成功，此时将线程ID设置为本线程ID，如果竞争失败，说明造成了有了较为强烈的锁竞争，偏向锁已不能满足，此时偏向锁晋级为轻量级锁。
轻量级锁
当锁发生竞争时，持有偏向锁的线程会撤销偏向锁，转而晋级为轻量级锁（状态）。轻量级锁的核心是，不让未获取锁的线程进入阻塞状态，因为这会使得线程由用户态转为核心态，这会造成很大的性能损失，而是采用“死循环”的方式不断的获取锁，这种采用“死循环”获取的锁的方式称为——锁自旋。它不会让线程陷入阻塞，但同时仅适用于持有锁时间较短的场景。那么轻量级锁升级为重量级锁的条件就是，自旋等待的时间过长，并且又有了新的线程来竞争。
重量级锁
这种锁，就是地地道道原原本本synchronized的本意了。线程会去抢夺对象上的一个互斥量（这个互斥量就是Monitor），每个对象都会有，就算是类也有一个Monitor互斥量（因为类在堆内存中有一个Class对象）。当一个线程获取到对象的Monitor锁时，其余线程会被阻塞挂起，并且由用户态转为核心态。
上文提到在锁的竞争状态晋级为重量级锁时，Java对象头中的Mark Word前30位存储的是Monitor对象的指针。Monitor对象定义在openjdk/hotspot/share/runtime/objectMonitor.hpp中，在ObjectMonitor中定义了：计数器、持有Monitor的线程、处于wait状态的线程、处于阻塞状态的线程等等。
synchronized无论是普通实例还是同步代码块，它所获取的锁是对象实例中的Monitor锁，而对象的Monitor又是存在于Java对象头的Mark Work之中，所以可以这么说，synchronized获取的锁在Java对象头中。
对于普通实例或者静态方法，JVM并没有显示的指令进入临界区，而是在方法上标识了“ACC_SYNCHRONIZED”，标识是synchronized同步方法，方法内部都是临界区。
而对于同步代码块，则在synchronized代码块开始执行了monitorenter，结束或者抛出异常时执行了monitorexit指令。
synchronized 用法
1.修饰代码块，指定加锁对象，对指定对象加锁，进入同步代码库前要获得给定对象的锁。
2.修饰实例方法，作用于当前实例加锁，进入同步代码前要获得当前实例的锁。
3.静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁。
修饰代码块
修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。
修饰实例方法，相当于对当前实例加锁.
错误示例 ：
synchronized作用在实例方法上时锁的是当前对象实例，图中 红框部分t1 、t2 是new了两个不同的实例，可改成
修饰静态方法，相当于对当前类加锁
此时t1 ，t2 虽然new了不同的实例，但由于synchronized此时不是在实例上加锁，而是在类上加锁，所以正确。