问题：
1、乐观锁和悲观锁的理解及如何实现，有哪些实现方式？
2、什么是乐观锁和悲观锁？
3、乐观锁可以重入吗？
1. 悲观锁存在的问题
独占锁其实就是一种悲观锁，java的synchronized是悲观锁。悲观锁可以确保无论哪个线程持有锁，都能独占式访问临界区。虽然悲观锁的逻辑非常简单，但是存在不少问题。
悲观锁总是假设会发生最坏的情况，每次线程读取数据时，也会上锁。这样其他线程在读取数据时就会被阻塞，直到它拿到锁。传统的关系型数据库用到了很多悲观锁，比如行锁、表锁、读锁、写锁等。
悲观锁机制存在以下问题：
（1）在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。
（2）一个线程持有锁后，会导致其他所有抢占此锁的线程挂起。
（3）如果一个优先级高的线程等待一个优先级低的线程释放锁，就会导致线程的优先级倒置，从而引发性能风险。
解决以上悲观锁的这些问题的有效方式是使用乐观锁去替代悲观锁。与之类似，数据库操作中的带版本号数据更新、JUC包的原子类，都使用了乐观锁的方式提升性能。
2. 通过CAS实现乐观锁
乐观锁的操作主要就是两个步骤：（1）第一步：冲突检测。（2）第二步：数据更新。
乐观锁一种比较典型的就是CAS原子操作，JUC强大的高并发性能是建立在CAS原子之上的。CAS操作中包含三个操作数：需要操作的内存位置（V）、进行比较的预期原值（A）和拟写入的新值（B）。如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置的值更新为新值B；否则处理器不做任何操作。
CAS操作可以非常清晰地分为两个步骤：
（1）检测位置V的值是否为A。
（2）如果是，就将位置V更新为B值；否则不要更改该位置。
CAS操作的两个步骤其实与乐观锁操作的两个步骤是一致的，都是在冲突检测后进行数据更新。
乐观锁是一种思想，而CAS是这种思想的一种实现。实际上，如果需要完成数据的最终更新，仅仅进行一次CAS操作是不够的，一般情况下，需要进行自旋操作，即不断地循环重试CAS操作直到成功，这也叫CAS自旋。通过CAS自旋，在不使用锁的情况下实现多线程之间的变量同步，也就是说，在没有线程被阻塞的情况下实现变量的同步，这叫作“非阻塞同步”，或者说“无锁同步”。使用基于CAS自旋的乐观锁进行同步控制，属于无锁编程的一种实践。
3. 不可重入的自旋锁
自旋锁的基本含义为：当一个线程在获取锁的时候，如果锁已经被其他线程获取，调用者就一直在那里循环检查该锁是否已经被释放，一直到获取到锁才会退出循环。
CAS自旋锁的实现原理为：
抢锁线程不断进行CAS自旋操作去更新锁的owner（拥有者），如果更新成功，就表明已经抢锁成功，退出抢锁方法。如果锁已经被其他线程获取（也就是owner为其他线程），调用者就一直在那里循环进行owner的CAS更新操作，一直到成功才会退出循环。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
public class SpinLock implements Lock { // 当前锁的拥有者 private AtomicReference<Thread> owner = new AtomicReference<>(); @Override public void lock() { Thread t = Thread.currentThread(); // 自旋 while (owner.compareAndSet(null,t)){ // 让出CPU的时间片 Thread.yield(); } } @Override public void unlock() { Thread t = Thread.currentThread(); // 只有拥有者才能获取锁 if(t==owner.get()){ // 设置owner为空，这里不需要使用compareAndSet，因为已经通过owner做过线程检查 owner.set(null); } } // 省略其他代码...} |
上述SpinLock是不支持重入的，即当一个线程第一次已经获取到了该锁，在锁没有被释放之前，如果又一次重新获取该锁，第二次将不能成功获取到，因为自旋后CAS会失败。
4. 可重入的自旋锁
为了实现可重入锁，这里引入一个计数器，用来记录一个线程获取锁的次数。一个简单的可重入的自旋锁的代码大致如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
public class ReentrantSpinLock implements Lock { // 当前锁的拥有者，使用Thread作为同步状态 AtomicReference<Thread> owner = new AtomicReference<>(); // 记录一个线程重复获取锁的次数 private int count = 0; // 抢占锁 @Override public void lock() { Thread t = Thread.currentThread(); // 如果时冲入，增加重入次数后，返回 if(t==owner.get()){ count++; return; } // 自旋 while (owner.compareAndSet(null,t)){ Thread.yield(); } } @Override public void unlock() { Thread t = Thread.currentThread(); // 只有拥有者才能释放锁 if(t==owner.get()){ // 如果重入次数大于0，减少重入次数后返回 if(count>0){ count--; }else{ // 设置拥有者为null owner.set(null); } } } // 省略其他代码...} |
自旋锁的特点：线程获取锁的时候，如果锁被其他线程持有，当前线程将循环等待，直到获取到锁。线程抢锁期间状态不会改变，一直是运行状态（RUNNABLE），在操作系统层面线程处于用户态。
自旋锁的问题：在争用激烈的场景下，如果某个线程持有锁的时间太长，就会导致其他空自旋的线程耗尽CPU资源。另外，如果大量的线程进行空自旋，还可能导致硬件层面的“总线风暴”。
在争用激烈的场景下，Java轻量级锁会快速膨胀为重量级锁，其本质上一是为了减少CAS空自旋，二是为了避免同一时间大量CAS操作所导致的总线风暴。那么，JUC基于CAS实现的轻量级锁如何避免总线风暴呢？答案是：使用队列对抢锁线性进行排队，最大程度上减少了CAS操作数量。
总结
本篇文章就到这里了，希望能够给你带来帮助，也希望您能够多多关注服务器之家的更多内容!
原文链接：https://blog.csdn.net/qq_42764468/article/details/123644735
