总结
无锁 -> 偏向锁 -> 轻量级锁 (自旋锁) -> 重量级锁 (悲观锁)
锁状态对比：
|
偏向锁 |
轻量级锁 |
重量级锁 |
|
|
适用场景 |
只有一个线程进入同步块 |
虽然很多线程，但是没有冲突：多条线程进入同步块，但是线程进入时间错开因而并未争抢锁 |
发生了锁争抢的情况：多条线程进入同步块并争用锁 |
|
本质 |
取消同步操作 |
CAS操作代替互斥同步 |
互斥同步 |
|
优点 |
不阻塞，执行效率高（只有第一次获取偏向锁时需要CAS操作，后面只是比对ThreadId） |
不会阻塞 |
不会空耗CPU |
|
缺点 |
适用场景太局限。若竞争产生，会有额外的偏向锁撤销的消耗 |
长时间获取不到锁空耗CPU |
阻塞，上下文切换，用户态切换到内核态重量级操作，消耗操作系统资源 |
1.无锁
没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功，其他修改失败的线程会不断重试直到修改成功。
2.偏向锁
在锁对象的对象头里面有一个 threadid 字段，在第一次访问的时候 threadid 为空，jvm 让其持有偏向锁，并将 threadid 设置为其线程 id（线程第一次进入，使用CAS来设置线程id），再次进入的时候会先判断 threadid 是否与其线程 id 一致（无需CAS了）：
- 如果一致则可以直接使用此对象，降低获取锁带来的性能开销。
- 如果不一致，则升级偏向锁为轻量级锁
偏向锁，指的就是偏向第一个加锁线程a，该线程是不会主动释放偏向锁的，只有当其他线程b尝试竞争偏向锁才会被释放。
关闭偏向锁，通过jvm的参数-XX:UseBiasedLocking=false,则默认会进入轻量级锁。
偏向锁的释放
其实就是线程b要操作的时候，看是否可以释放掉a线程的偏向锁。需要等待全局安全点（在这个时间点上没有正在执行的字节码），它会首先暂停拥有偏向锁的线程a(达到安全点再暂停阿~)，然后检查持有偏向锁的线程a是否还活着:
- 如果线程a不处于活动状态，则将锁对象的MarkWord设置成无锁状态，(再指向b线程)。
- 如果线程a仍然活着，拥有偏向锁a的栈会被执行。
- 当线程a不需要用到该偏向锁了，则恢复到无锁，(再指向b线程)。
- 如果a还要用，则和b产生竞争，标记对象不适合作为偏向锁。最后唤醒暂停的线程。
偏向锁->轻量级锁 条件
当锁是偏向锁的时候，被第二个线程 b 所访问，此时偏向锁就会升级为轻量级锁
3.轻量级锁
轻量级锁是指: 当锁是偏向锁的时候（锁的threadid 是 a 时），被第二个线程 b 所访问，此时偏向锁就会升级为轻量级锁，线程 B 会通过自旋的形式尝试获取锁，线程不会阻塞，从而提高性能。
轻量级锁->重量级锁 两个条件
- 当前只有一个等待线程b，则该线程将通过自旋进行等待。但是当自旋超过一定的次数时，轻量级锁便会升级为重量级锁；
- 当一个线程已持有锁，另一个线程在自旋，而此时又有第三个线程来访时，轻量级锁也会升级为重量级锁。
4.重量级锁
指当有一个线程获取锁之后，其余所有等待获取该锁的线程都会处于阻塞状态。
重量级锁通过对象内部的监视器（monitor）实现，而其中 monitor 的本质是依赖于底层操作系统的 Mutex Lock 实现，操作系统实现线程之间的切换需要从用户态切换到内核态，切换成本非常高。
锁分级别原因
- 锁升级是为了减低了synchronized(初始设计就是重量级锁)带来的性能消耗。没有优化以前，synchronized是重量级锁-悲观锁 （对比：乐观锁vs悲观锁），使用 wait 和 notify、notifyAll 来切换线程状态非常消耗系统资源。
- synchronized锁在线程运行到该代码块的时候，让程序的运行级别从用户态切换到内核态，把所有的线程挂起，让cpu通过操作系统指令，去调度多线程之间，谁执行代码块，谁进入阻塞状态。
- 这样会频繁出现程序运行状态的切换，线程的挂起和唤醒，这样就会大量消耗资源，程序运行的效率低下。为了提高效率，jvm的开发人员，把锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态，尽量让多线程访问公共资源的时候，不进行程序运行状态的切换（用户态切换到内核态）。
用户态和内核态
进程在运行时一般都是用户态，此时权限是最低的。
但一旦要执行系统硬件层的操作，比如读写文件，网络传输等需要从用户态切换到内核态才能执行，但这个切换过程是很耗时的。
部分内容摘自：