首先，我们要知道一个知识点，就是synchronized的实现是通过monitorenter/monitorexit 指令实现的。
每个对象都有Monitor（监视器锁），当monitor被占用的时候，对象进入锁定状态。
monitorenter：线程通过monitorenter指令尝试获取monitor所有权，情况如下：
1、如果monitor的进入数为0，则该线程进入，进入数设置为1，线程占有monitor
2、如果该线程已经占有了monitor，只是重新进入，则进入数+1
3、如果已经有别的形成占有了monitor，则该线程进入阻塞状态，知道monitor的进入数为0，再重新尝试获取monitor
monitorexit：
执行monitorexit的线程必须是objectref所对应的monitor的所有者。
指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。
Synchronized的语义底层是通过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。
在java6以前，monitor的实现完全依靠操作系统内部的互斥锁（因为需要在user space和kernel space间切换），所以这时期的同步操作时一个无差别的重量级操作，也就没有锁的升级降级概念。
在后来的jdk中，提供了三种不同的Monitor实现，既三种不同的锁：偏斜锁、轻量级锁、重量级锁
锁的升级、降级：就是JVM优化synchronized运行的机制，当jvm检测到不同的竞争状况时，会自动的切换到合适的锁实现
锁升级：
1、当没有竞争出现时，默认会使用偏斜锁。JVM 会利用 CAS操作，在对象头上的Mark Word部分设置线程ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁。这样做的假设是基于在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏斜锁可以降低无竞争开销。
2、有竞争出现时，当有另外的线程试图锁定某个已经被偏斜锁锁定的对象，jvm就会撤销revoke偏斜锁，并切换到轻量级锁。轻量级锁依赖CAS操作Mark Word来试图获取锁，如果成功，就使用轻量级锁，否则继续升级未重量级锁
PS:锁降级也是存在的，当JVM进入SafePoint安全点的时候，会检查是否有闲置的Monitor，然后试图进行降级。