独占锁与共享锁

àì夳堔傛蜴生んèń 2021-11-04 11:50 335阅读 0赞

### 独占锁与共享锁 ###

*  前言
 *  概念引入
 *   *  独占锁概念
     *  共享锁概念
 *  源码分析
 *   *  ReentrantReadWriteLock源码
     *  读锁和写锁的具体加锁方式有什么区别

# 前言 #

独占锁和共享锁同样是一种概念。我们先介绍一下具体的概念，然后通过 ReentrantLock 和 ReentrantReadWriteLock 的源码来介绍独占锁和共享锁。

# 概念引入 #

## 独占锁概念 ##

独占锁也叫排他锁，是指该锁一次只能被一个线程所持有。如果线程T对数据A加上排他锁后，则其他线程不能再对A加任何类型的锁。获得排它锁的线程即能读数据又能修改数据。JDK中的synchronized和 JUC中Lock的实现类就是互斥锁。

## 共享锁概念 ##

共享锁是指该锁可被多个线程所持有。如果线程T对数据A加上共享锁后，则其他线程只能对A再加共享锁，不能加排它锁。获得共享锁的线程只能读数据，不能修改数据。 独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。

# 源码分析 #

## ReentrantReadWriteLock源码 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lqbjE5OTU_size_16_color_FFFFFF_t_70]  
我们看到 ReentrantReadWriteLock 有两把锁：ReadLock和WriteLock，见名知意，一个读锁一个写锁， 合称“读写锁”。  
再进一步观察可以发现 ReadLock 和 WriteLock 是靠内部类 Sync 实现的锁。  
Sync 是 AQS 的一个子类，这种结构在 CountDownLatch 、ReentrantLock 、Semaphore 里面也都存在。  
在ReentrantReadWriteLock 里面，读锁和写锁的锁主体都是 Sync ，但读锁和写锁的加锁方式不一样。  
读锁是共享锁，写锁是独占锁。读锁的共享锁可保证并发读非常高效，而读写、写读、写写的过程互斥，因为读锁和写锁是分离的。所以ReentrantReadWriteLock的并发性相比一般的互斥锁有了很大提升。

## 读锁和写锁的具体加锁方式有什么区别 ##

在了解源码之前我们需要回顾一下其他知识。 在最开始提及 AQS 的时候我们也提到了state字段(int类型，32位)，该字段用来描述有多少线程获持有锁。 在独享锁中这个值通常是0或者1（如果是重入锁的话state值就是重入的次数），在共享锁中state就是持有锁的数量。但是在 ReentrantReadWriteLock 中有读、写两把锁，所以需要在一个整型变量state上分别描述读锁和写锁的数量（或者也可以叫状态）。于是将state变量“按位切割”切分成了两个部分，高16位 表示读锁状态（读锁个数），低16位表示写锁状态（写锁个数）。如下图所示：  
![在这里插入图片描述][20190809191242596.png]

protected final boolean tryAcquire(int acquires) { 
    	Thread current = Thread.currentThread();
    	int c = getState(); // 取到当前锁的个数
    	int w = exclusiveCount(c); // 取写锁的个数w
    	if (c != 0) {  // 如果已经有线程持有了锁(c!=0)
    		// (Note: if c != 0 and w == 0 then shared count != 0)
    		if (w == 0 || current != getExclusiveOwnerThread()) // 如果写线程数（w）为0（换言之存在读锁） 或者持有锁的线程 不是当前线 程就返回失败
    				return false;
    		if (w + exclusiveCount(acquires) > MAX_COUNT) // 如果写入锁的数量大于最大数（65535，2的16次方-1）就抛出一个Error。
    		throw new Error("Maximum lock count exceeded");
    // Reentrant acquire
    		 setState(c + acquires);
    		return true;
     }
    if (writerShouldBlock() || !compareAndSetState(c, c + acquires)) // 如果当且写线程数为0，并且当前线程需要阻塞那么就返回失败；或者如果通过CAS增加写线程数失败也返回失败。
    		return false;
    	setExclusiveOwnerThread(current); // 如果c=0，w=0或者c>0，w>0（重入），则设置当前线程或锁的拥有者
    	return true; 
    }

*  这段代码首先取到当前锁的个数c，然后再通过c来获取写锁的个数w。因为写锁是低16位，所以取低16位的最大值与当前的c做与运算（ int w = exclusiveCount©; ），高16位和0与运算后是0，剩下的就是低位运算的值，同时也是持 有写锁的线程数目。
 *  在取到写锁线程的数目后，首先判断是否已经有线程持有了锁。如果已经有线程持有了锁(c!=0)，则查看当前写锁线程的数目，如果写线程数为0（即此时存在读锁）或者持有锁的线程不是当前线程就返回失败。
 *  如果写入锁的数量大于最大数（65535，2的16次方-1）就抛出一个Error。
 *  如果当且写线程数为0（那么读线程也应该为0，因为上面已经处理c!=0的情况），并且当前线程需要阻塞那么就返 回失败；如果通过CAS增加写线程数失败也返回失败。
 *  如果c=0,w=0或者c>0,w>0（重入），则设置当前线程或锁的拥有者，返回成功！

tryAcquire()除了重入条件（当前线程为获取了写锁的线程）之外，增加了一个读锁是否存在的判断。  
如果存在读锁，则写锁不能被获取，原因在于：  
必须确保写锁的操作对读锁可见，如果允许读锁在已被获取 的情况下对写锁的获取，那么正在运行的其他读线程就无法感知到当前写线程的操作。  
因此，只有等待其他读线程都释放了读锁，写锁才能被当前线程获取，而写锁一旦被获取，则其他读写线程的后续访问均被阻塞。写锁的释放与 ReentrantLock 的释放过程基本类似，每次释放均减少写状态，当写状态为0时表示写锁已被释放，然后等待的读写线程才能够继续访问读写锁，同时前次写线程的修改对 后续的读写线程可见。 接着是读锁的代码：

protected final int tryAcquireShared(int unused) { 
     	Thread current = Thread.currentThread();
    	int c = getState();
    	if (exclusiveCount(c) != 0 &&getExclusiveOwnerThread() != current)
    		return -1; // 如果其他线程已经获取了写锁，则当前线程获取读锁失败，进入等待状态
    	int r = sharedCount(c);
    	if (!readerShouldBlock() &&r < MAX_COUNT &&compareAndSetState(c, c + SHARED_UNIT)) { 
    		if (r == 0) { 
     			firstReader = current;
     			firstReaderHoldCount = 1;
     		} else if (firstReader == current) { 
     			firstReaderHoldCount++;
     		} else { 
     			HoldCounter rh = cachedHoldCounter;
    			if (rh == null || rh.tid != getThreadId(current))
     				cachedHoldCounter = rh = readHolds.get();
    			else if (rh.count == 0)
     				readHolds.set(rh);
     				rh.count++;
     		}
    		return 1;
     	}
    	return fullTryAcquireShared(current);
    }

可以看到在 tryAcquireShared(int unused) 方法中，如果其他线程已经获取了写锁，则当前线程获取读锁 失败，进入等待状态。如果当前线程获取了写锁或者写锁未被获取，则当前线程（线程安全，依靠CAS保证）增加读状态，成功获取读锁。读锁的每次释放（线程安全的，可能有多个读线程同时释放读锁）均减少读状态，减少的值是“1<<16”。所以读写锁才能实现读读的过程共享，而读写、写读、写写的过程互斥。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lqbjE5OTU_size_16_color_FFFFFF_t_70]: /images/20211104/af30fc8d5958495892764a56ba4d0d89.png
[20190809191242596.png]: /images/20211104/ae8f72d370f7468a8ed1735955ccfd63.png