关于ReentrantReadWriteLock，ReentrantLock锁的闲扯

今天看了一下ReentrantReadWriteLock，ReentrantLock记录一下，可能写得不对。

ReentrantReadWriteLock,ReentrantLock两者都是可重入默认非公平锁。ReentrantReadWriteLock 个人理解为是对ReentrantLock锁的再次细分为读锁与写锁。读锁与写锁可能成为非独占锁与独占锁更贴切。ReentrantLock可以理解独占锁。

1.怎么理解可重入锁？

如果当前线程持有该锁还能再次获得该锁，则表明该锁是可重入。以ReentrantLock公平与非公平锁为例，主要在tryAcquire方法中。

以ReentrantLock的公平锁为例，红色方框中的代码，判断如果当前的线程就是持有锁的线程则获取锁成功，这也就是可重入的概念。

 

2.公平锁与非公平锁。

公平锁线程获取锁的概率是相同的，线程调用lock的时候判断当前线程能否获取锁，能则获取，不能则将线程放在链表中。非公平锁获取锁的概率不同，非公平锁在线程调用lock的时候首先判断是否有线程持有锁，如果没有线程持有则让当前线程持有锁。后面的逻辑与公平锁的实现一样。

看一下ReentrantLock的公平锁与非公平锁实现可能更容易理解。可以看到公平与非公平锁的实现差别不大。

3.ReentrantLock，ReentrantReadWriteLock默认实现是非公平锁。非公平锁可以减少线程挂起，cpu切换等时间，但是非公平锁也可能导致线程饿死的情况。如果想使用公平锁，在创建ReentrantLock，ReentrantReadWriteLock时在构造方法中传入true即可。

4.关于ReentrantReadWriteLock的想法。ReentrantReadWriteLock中包含读锁与写锁即独占锁与非独占锁。这与mysql数据库的独占锁与非独占锁有相似之处。为什么ReentrantReadWriteLock没有实现锁升级功能，在同一个线程中如果先使用了读锁，其后没有办法在获得写锁。这样会造成一个线程因为先获取了读锁然后获取写锁而死锁。同时这也与可重入概念不是很相符。如果能像数据库一样实现锁升级可以避免这个问题。先获取写锁在获取读锁是被允许的。

主要实现方法：

tryAcquire

主要实现方式：

Unsafe的CAS方式保证只有一个线程能获得锁。