前言

在你立足处深挖下去,就会有泉水涌出!别管蒙昧者们叫嚷:“下边永远是地狱!”

博客主页：KC老衲爱尼姑的博客主页

博主的github，平常所写代码皆在于此

共勉：talk is cheap, show me the code

作者是爪哇岛的新手，水平很有限，如果发现错误，一定要及时告知作者哦！感谢感谢！

文章目录

常见的锁策略
- 乐观锁vs悲观锁
- 读写锁
- 重量级锁vs轻量级锁
- 自旋锁vs挂起等待锁
- 公平锁vs非公平锁
- **可重入锁** **vs** **不可重入锁**

常见的锁策略

乐观锁vs悲观锁

悲观锁:总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。

乐观锁：假设数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并

发冲突进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做。

举个栗子:合租房里面有2个人一起合租,厕所只有一个。A在上厕所的时候,就比较乐观,他上厕所的时候,他就觉得B想上厕所的概率比较小,就不锁门了。这就是乐观锁。所谓的悲观锁就是,B上厕所的时候,就比较悲观,就觉得A懒人屎尿多,老想上厕所,就每次上厕所的时候,即使A不在家,也会把门锁上。

读写锁

多线程之间，数据的读取方之间不会产生线程安全问题，但数据的写入方互相之间以及和读者之间都需要进行互斥。如果两种场景下都用同一个锁，就会产生极大的性能损耗。所以读写锁因此而产生。读写锁（readers-writer lock），看英文可以顾名思义，在执行加锁操作时需要额外表明读写意图，复数读者之间并不互斥，而写者则要求与任何人互斥。

一个线程对于数据的访问, 主要存在两种操作: 读数据和写数据.

两个线程都只是读一个数据, 此时并没有线程安全问题. 直接并发的读取即可.
两个线程都要写一个数据, 有线程安全问题.
一个线程读另外一个线程写, 也有线程安全问题.

Java 标准库提供了 ReentrantReadWriteLock 类, 实现了读锁写锁,ReentrantReadWriteLock.ReadLock 类表示一个读锁.,这个对象提供了 lock / unlock 方法进行加锁解锁。 ReentrantReadWriteLock.WriteLock 类表示一个写锁. 这个对象也提供了 lock / unlock 方法进行加锁解锁。其中读加锁和读加锁不互相互斥,写加锁和写加锁之前互斥,读加锁和写加锁之间互斥。

使用演示

我们创建了一个ReadWriteLockExample类，其中包含了一个sharedData变量，表示共享数据。ReadWriteLock用于控制对sharedData的读写访问。

读取操作使用读锁(readLock)进行保护，允许多个线程同时读取共享数据。写入操作使用写锁(writeLock)进行保护，确保在写入过程中只有一个线程能够修改共享数据。

在main方法中，我们创建了多个读取线程和一个写入线程。读取线程会不断读取共享数据并输出，而写入线程会每隔一段时间写入一个新的数据。由于使用了读写锁，读取线程可以并发执行读操作，而写入线程则可以互斥地执行写操作，从而实现了对共享数据的安全读写。

实现代码


import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

public class ReadWriteLockExample {
    private int sharedData = 0;
    private ReadWriteLock rwLock = new ReentrantReadWriteLock();
    private Lock readLock = rwLock.readLock();
    private Lock writeLock = rwLock.writeLock();

    public void readData() {
        readLock.lock();
        try {
            System.out.println("Read Thread: Reading data: " + sharedData);
        } finally {
            readLock.unlock();
        }
    }

    public void writeData(int data) {
        writeLock.lock();
        try {
            System.out.println("Write Thread: Writing data: " + data);
            sharedData = data;
        } finally {
            writeLock.unlock();
        }
    }

    public static void main(String[] args) {
        ReadWriteLockExample example = new ReadWriteLockExample();
        // 创建多个读取线程
        for (int i = 0; i < 5; i++) {
            new Thread(() -> {
                while (true) {
                    example.readData();
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }).start();
        }

        // 创建一个写入线程
        new Thread(() -> {
            int data = 1;
            while (true) {
                example.writeData(data);
                data++;
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

运行结果:

在这里插入图片描述

重量级锁vs轻量级锁

锁的核心特性 “原子性”, 这样的机制追根溯源是 CPU 这样的硬件设备提供的，CPU 提供了 "原子操作指令，然后操作系统基于 CPU 的原子指令, 实现了 mutex 互斥锁.,JVM 基于操作系统提供的互斥锁, 实现了 synchronized 和 ReentrantLock 等关键字和类。

重量级锁

重量级锁加锁机制重度依赖了 OS 提供了 mutex,使用此锁容易引起线程的调度以及大量的内核态用户态的切换。这两个操作成本都比较高,一旦涉及到用户态和内核态的切换,就意味着"沧海桑田",典型的进入内核态的加锁逻辑,开销比较大。

轻量级锁

加锁机制尽可能不使用 mutex, 而是尽量在用户态代码完成. 实在搞不定了, 再使用 mutex,轻量级锁和重量级锁相反,不太容易引起线程调度以及只有少量的内核态用户态的切换,典型的纯用户态的加锁逻辑,开销比较小。

举个栗子,去银行办理业务,在窗口找机器办理,自己操作,这里是用户态,用户态的时间成本相对是可控的。有时候得去排队找工作人员办理,这就是内核态.内核态的时间成本不太可控,因为办理业务的时候存在和工作人员大量的沟通,还需要排队,这时的效率就很低。

synchronized 开始是一个轻量级锁如果锁冲突比较严重,就会变成重量级锁

自旋锁vs挂起等待锁

自旋锁

按之前的方式，线程在抢锁失败后进入阻塞状态，放弃 CPU，需要过很久才能再次被调度,但实际上, 大部分情况下，虽然当前抢锁失败，但过不了很久，锁就会被释放。没必要就放弃 CPU。这个时候就可以使用自旋锁来处理这样的问题.。

自旋锁伪代码

while (抢锁(lock) == 失败) {}

如果获取锁失败, 立即再尝试获取锁, 无限循环, 直到获取到锁为止. 第一次获取锁失败, 第二次的尝试会在极短的时间内到来.。一旦锁被其他线程释放, 就能第一时间获取到锁。

举个栗子,这就还比张三和妹子出去约会,当张三已经到了目的地,张三就给妹子打电话,问到了没,妹子就说"马上",挂了之后,你又不停的打电话询问到了没。这样你就第一时间知道她到了。

自旋锁是一种典型的轻量级锁的实现方式.

优点: 没有放弃 CPU, 不涉及线程阻塞和调度, 一旦锁被释放, 就能第一时间获取到锁.

缺点: 如果锁被其他线程持有的时间比较久, 那么就会持续的消耗 CPU 资源. (而挂起等待的时候是不消耗 CPU 的).

挂起等待锁

当获取锁失败后,就会挂起等待。

举个栗子,依旧是张三和妹子约会的,张三不再反复的打电话询问妹子到了没,而是站在那里看小说等待着妹子过来。

公平锁vs非公平锁

假设三个线程 A, B, C. A 先尝试获取锁, 获取成功. 然后 B 再尝试获取锁, 获取失败, 阻塞等待; 然后C 也尝试获取锁, C 也获取失败, 也阻塞等待.。当线程 A 释放锁的时候, 会发生啥呢?

公平锁: 遵守 “先来后到”. B 比 C 先来的. 当 A 释放锁的之后, B 就能先于 C 获取到锁.。

非公平锁: 不遵守 “先来后到”. B 和 C 都有可能获取到锁.

举个栗子,当被一群男生心心念念的女神失恋后,这些男生对女生都展开了猛烈的追求,先来的男生先上位,这就是公平锁。如果是女神看那个顺眼就和那个在一起,这就是非公平锁。

使用ReentrantLock演示公平锁和非公平锁,ReentrantLock默认是非公平锁

代码演示


import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class ReentrantLockFairnessDemo {
    private static Lock fairLock = new ReentrantLock(true); // 公平锁
    private static Lock nonFairLock = new ReentrantLock(); // 非公平锁

    public static void main(String[] args) {
        Runnable fairTask = () -> {
            fairLock.lock();
            try {
                System.out.println("Fair lock: Thread " + Thread.currentThread().getId() + " acquired the lock.");
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                fairLock.unlock();
            }
        };

        Runnable nonFairTask = () -> {
            nonFairLock.lock();
            try {
                System.out.println("Non-fair lock: Thread " + Thread.currentThread().getId() + " acquired the lock.");
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                nonFairLock.unlock();
            }
        };

        // 使用公平锁执行任务
        for (int i = 0; i < 5; i++) {
            new Thread(fairTask).start();
        }

        try {
            Thread.sleep(10000); // 等待2秒，以确保公平锁的线程先运行
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("------------------");

        // 使用非公平锁执行任务
        for (int i = 0; i < 5; i++) {
            new Thread(nonFairTask).start();
        }
    }
}