锁详解区分 互斥锁⾃旋锁读写锁乐观锁悲观锁

Posted 2021-10-28 CJ-cooper

锁

今天看了下常见的几种锁：

互斥锁、⾃旋锁、读写锁、乐观锁、悲观锁，总结一下

互斥锁和自旋锁

最底层的就是互斥锁和自旋锁，有很多⾼级的锁都是基于它们实现的

加锁的⽬的就是保证共享资源在任意时间⾥，只有⼀个线程访问，这样就可以避免多线程导致共享数据错乱的问题

互斥锁和⾃旋锁的区别就是对于加锁失败后的处理⽅式是不⼀样的：

• 互斥锁加锁失败后，线程会释放CPU，给其他线程。加锁的代码就会被阻塞。
• 自旋锁加锁失败后，线程会忙等待，也就是一直请求加锁，直到它拿到锁

也就是当加锁失败时，互斥锁⽤「线程切换」来应对，⾃旋锁则⽤「忙等待」来应对。

如图

所以，互斥锁加锁失败，会从用户态陷入到内核态，让内核帮我们切换线程，这会有两次线程上下文切换的成本，具有一定的性能开销：

• 当线程加锁失败时，内核会把线程的状态从运行状态设置为睡眠状态，然后把CPU切换给其他线程运行
• 当锁被释放时，之前睡眠状态的线程会变为就绪状态，然后内核会在合适时间，把CPU切换给该线程运行

因为虚拟内存是共享的，这里上下文切换的是线程私有数据、寄存器等不共享的数据

所以如果代码运行时间很短，可以考虑不用互斥锁，而是选用自旋锁

自旋锁是通过CPU提供的CAS函数数（Compare And Swap），在用户态完成加锁和解锁操作，不会主动产生线程上下文切换，所以相比较互斥锁来说，会快一点，开销也小一点

⼀般加锁的过程，包含两个步骤：

第⼀步，查看锁的状态，如果锁是空闲的，则执⾏第⼆步；

第⼆步，将锁设置为当前线程持有；

CAS函数就把这两步骤合并成一条硬件级指令，形成原子指令

读写锁

读写锁由读锁和写锁两部分构成，如果只读共享资源用读锁加锁，如果需要修改共享资源则用写锁加锁

工作原理：

当写锁没有被线程持有时，多个线程可以并发地持有读锁，但是当写锁被线程持有后，其他线程获取读锁和写锁的操作都会阻塞

读写锁在读多写少的场景，能发挥出优势

根据实现的不同分为读优先锁和写优先锁

读优先锁：

写优先锁：

但是这两种都会造成线程“饥饿”的问题，比如

读优先锁：一直有读线程获取读锁，那么写线程将永远获取不到，造成写线程“饥饿”。

写优先锁：如果⼀直有写线程获取写锁，读线程也会被「饿死」。

所以我们可以搞一个公平读写锁

公平读写锁⽐较简单的⼀种⽅式是：⽤队列把获取锁的线程排队，不管是写线程还是读线程都按照先进先出的原则加锁即可，这样读线程仍然可以并发，也不会出现「饥饿」的现象。

乐观锁 悲观锁

悲观锁：认为多线程同时修改共享资源的概率⽐较⾼，于是很容易出现冲突，所以访问共享资源前，先要上锁。

前⾯提到的互斥锁、⾃旋锁、读写锁，都是属于悲观锁。

乐观锁：假定冲突的概率很低，它的⼯作⽅式是：先修改完共享资源，再验证这段时间内有没有发⽣冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。另外虽然叫锁，但是乐观锁全程并没有加锁，所以它也叫⽆锁编程。

一般会使用版本号机制或CAS算法实现

一篇文章读懂java中所有的锁（包括乐观锁/互斥锁/读写锁/分段锁）

一、锁分类

• 乐观锁/悲观锁

• 公平锁/非公平锁

• 可重入锁

• 独享锁/共享锁

• 分段锁

• 偏向锁/轻量级锁/重量级锁

二、具体锁

• 互斥锁/读写锁（独享锁/共享锁的具体实现）

• 自旋锁

---

乐观锁/悲观锁

乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度。

• 悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。

• 乐观锁则认为对于同一个数据的并发操作，是不会发生修改的。在更新数据的时候，会采用尝试更新，不断重新的方式更新数据。乐观的认为，不加锁的并发操作是没有事情的。

• 从上面的描述我们可以看出，悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。

悲观锁在Java中的使用，就是利用各种锁。

乐观锁在Java中的使用，是无锁编程，常常采用的是CAS算法，典型的例子就是原子类，通过CAS自旋实现原子操作的更新。

公平锁/非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁。

非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。

• 优点：在于吞吐量比公平锁大。

• 缺点：可能会造成优先级反转或者某些线程饥饿现象(一直拿不到锁)。

• 对于Java ReentrantLock而言，通过构造函数指定该锁是否是公平锁，默认是非公平锁。

• 对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。

可重入锁

• 可重入锁的概念是自己可以再次获取自己的内部锁。

• 举个例子，比如一条线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的（如果不可重入的锁的话，此刻会造成死锁）。说的更高深一点可重入锁是一种递归无阻塞的同步机制。

• 对于Java ReentrantLock而言, 他的名字就可以看出是一个可重入锁，其名字是Re entrant Lock重新进入锁。

• 对于Synchronized而言,也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。

独享锁/共享锁

• 独享锁是指该锁一次只能被一个线程所持有。

• 共享锁是指该锁可被多个线程所持有。

• 对于Java ReentrantLock（互斥锁）而言，其是独享锁。

• 但是对于Lock的另一个实现类ReadWriteLock（读写锁），其读锁是共享锁，其写锁是独享锁。读锁的共享锁可保证并发读是非常高效的，读写，写读 ，写写的过程是互斥的。

• 对于Synchronized而言，当然是独享锁。

分段锁

分段锁其实是一种锁的设计，并不是具体的一种锁。对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。

• 我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap（JDK7与JDK8中HashMap的实现）的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock)。

• 当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在那一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。

• 但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。

• 分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。

互斥锁：

无法获取琐时，进线程立刻放弃剩余的时间片并进入阻塞（或者说挂起）状态，同时保存寄存器和程序计数器的内容（保存现场，上下文切换的前半部分），当可以获取锁时，进线程激活，等待被调度进CPU并恢复现场（上下文切换下半部分）

上下文切换会带来数十微秒的开销，不要在性能敏感的地方用互斥锁

互斥锁在Java中的具体实现就是ReentrantLock：

类ReentrantLock实现了Lock，它拥有与Sychronized相同的并发性和内存语义，但是添加了类似锁投票、定时锁等候和可中断等候的一些特性。此外，它还提供了在与激烈争用情况下更佳的性能（说白了就是ReentrantLock和Sychronized差不多，线程间都是完全互斥的，一个时刻只能有一个线程获取到锁，执行被锁住的代码，但ReentrantLock相对于Sychronized提供了更加丰富的功能并且在线程调度上做了优化，JVM调度使用ReentrantLock的线程会更快）

读写锁：

1. 1）多个读者可以同时进行读

2. 2）写者必须互斥（只允许一个写者写，也不能读者写者同时进行）

3. 3）写者优先于读者（一旦有写者，则后续读者必须等待，唤醒时优先考虑写者）

读写锁在Java中的具体实现就是ReadWriteLock

通过类的继承结构可以看出ReentrantLock 和 ReentrantReadWriteLock是拥有者两个不同类继承结构的体系，两者并无关联

自旋锁：

自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。

场景：一般应用于加锁时间很短（1ms左右或更低）的场景。总之，使用自旋锁必须非常慎重。

来源丨java进阶架构师