＜JavaEE＞ 锁进阶 -- 锁策略(乐观锁和悲观锁、重量级锁和轻量级锁、自旋锁和挂起等待锁、可重入锁和不可重入锁、公平锁和非公平锁、读写锁)

轻量级锁加锁开销小，加锁速度快，是乐观锁；

重量级锁枷锁开销大，加锁速度慢，是悲观锁；

由此可以看出，轻量级锁和重量级锁、乐观锁和悲观锁，其实是对同一个事物不同角度的描述。

锁的轻量与重量，是从加锁时做的工作的多少来判定的；

而锁的乐观与悲观，是从加锁前对后续工作量的预估来判定的。

如果获取锁失败，将会在极短的时间内再次尝试获取。获取锁这个行为会不断循环，直到成功获取到锁。

自旋锁没有放弃CPU，不涉及线程阻塞和调度，一旦锁被释放，就会第一时间获得锁。但与此同时，如果锁被其他线程长期持有，那么自旋锁就会持续占用CPU资源，造成资源浪费。

如果获取锁失败，会让线程挂起等待，直到锁释放或满足其他条件，再重新尝试获取锁。

挂起等待时，内核调度器会介入，此时线程被调度离开，此时CPU资源释放，可以另作其他用途，但重新获取锁的开销也就随之变大。

自旋锁是轻量级锁的一种具体实现，同时也是一种乐观锁；

挂起等待锁则是重量级锁的一种具体实现，同时也是一种悲观锁。

synchronized 是非公平锁。

操作系统内部的线程调度是无序的，synchronized 并没有使用额外的数据结构来记录线程的阻塞顺序，没有对随即调度这个机制进行限制，因此是非公平锁。

公平锁天然就不会产生“线程饿死”问题。

但是，公平锁和非公平锁没有优劣之分，只需看哪个场景更适用。

同一个线程多次获取同一把锁而不会导致死锁，就是可重入锁；否则就是不可重入锁。

可重入锁中有专门用于记录锁的持有线程和加锁次数的属性。

可重入锁也叫递归锁。

Java 中，以 Reentrant 开头命名的锁都是可重入锁；JDK 中提供的 Lock 实现类，包括 synchronized 关键字，都是可重入锁。

Linux 系统提供的 mutex 是不可重入锁。

<1>多个线程同时读同一共享数据，不会产生线程安全问题；

从上文可以看出，多线程同时读的操作并不会产生线程安全问题，而在实际开发中，这种读操作是十分频繁的，如果使用和后两种情况一样“重量”的锁，那么就会有非常多的资源开销和性能浪费。因此，如果讲读锁和写锁分开，那么就可将资源开销省下，提升了性能。

读锁，就是一个线程加锁的时候，其他线程只能读不能写；

写锁，就是一个线程加锁的时候，其他线程不能读也不能写；

读锁与读锁之间不会出现锁冲突；

写锁和写锁之间会出现锁冲突；

读锁和写锁之间也会出现锁冲突；

synchronized 不是读写锁。

Java 标准库提供了?ReentrantReadWriteLock 类，实现了读写锁。

ReentrantReadWriteLock.ReadLock 类表示读锁。

ReentrantReadWriteLock.writeLock 类表示写锁。

上述两个锁，都通过 lock() 和 unlock() 方法进行加锁和解锁。