锁-synchronized

互斥锁的本质是共享资源。

1 锁的使用

可以修饰在方法层面和代码块层面

synchronized有三种方式来加锁，不同的修饰类型，代表锁的控制粒度：

1. 修饰实例方法，作用于当前实例加锁，进入同步代码前要获得当前实例的锁

2. 静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁

3. 修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

锁是在对象头中存储。

2 锁的升级

1. 偏向锁

在大多数情况下，锁不仅仅不存在多线程的竞争，而且总是由同一个线程多次获得。在这个背景下就设计了偏向锁。偏向锁，顾名思义，就是锁偏向于某个线程。

当一个线程访问加了同步锁的代码块时，会在对象头中存储当前线程的ID，后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线程的偏向锁。如果相等表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径。（偏向锁的目的是消除数据在无竞争情 况下的同步原语，进一步提高程序的运行性能。）

2. 轻量级锁

如果偏向锁被关闭或者当前偏向锁已经已经被其他线程获取，那么这个时候如果有线程去抢占同步锁时，锁会升级到轻量级锁。

3. 重量级锁

多个线程竞争同一个锁的时候，虚拟机会阻塞加锁失败的线程，并且在目标锁被释放的时候，唤醒这些线程；Java 线程的阻塞以及唤醒，都是依靠操作系统来完成的：os pthread_mutex_lock() ；升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态。

每一个JAVA对象都会与一个监视器monitor关联，可以把它理解成为一把锁，当一个线程想要执行一段被synchronized修饰的同步方法或者代码块时，该线程得先获取到synchronized修饰的对象对应的monitor。monitorenter表示去获得一个对象监视器。monitorexit表示释放monitor监视器的所有权，使得其他被阻塞的线程可以尝试去获得这个监视器。monitor依赖操作系统的MutexLock(互斥锁)来实现的，线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能。

任意线程对Object（Object由synchronized保护）的访问，首先要获得Object的监视器。如果获取失败，线程进入同步队列，线程状态变为BLOCKED。当访问Object的前驱（获得了锁的线程）释放了锁，则该释放操作唤醒阻塞在同步队列中的线程，使其重新尝试对监视器的获取。

​ 总结：偏向锁只有在第一次请求时采用CAS在锁对象的标记中记录当前线程的地址，在之后该线程再次进入同步代码块时，不需要抢占锁，直接判断线程ID即可，这种适用于锁会被同一个线程多次抢占的情况。轻量级锁才用CAS操作，把锁对象的标记字段替换为一个指针指向当前线程栈帧中的LockRecord，该工件存储锁对象原本的标记字段，它针对的是多个线程在不同时间段内申请同一把锁的情况。重量级锁会阻塞、和唤醒加锁的线程，它适用于多个线程同时竞争同一把锁的情况。