JAVAEE——多线程进阶，锁策略

news2024/11/25 6:44:21

文章目录

锁策略
- 乐观锁和悲观锁
- - 乐观锁
  - 悲观锁
  - - 两者的比较
- 读写锁
- 重量级锁和轻量级锁
- - 重量级锁
  - 轻量级锁
- 自旋锁
- 公平锁和非公平锁
- - 公平锁
  - 非公平锁
- 可重入锁和不可重入锁
- - 可重入锁
  - 不可重入锁

锁策略

乐观锁和悲观锁

乐观锁

什么是乐观锁呢？我们可以认为乐观锁比较自信，当多线程执行的时候如果要对一个资源进行访问，那么乐观锁会认为这些线程的访问是不会造成冲突的，并且这些访问也不都是要进行修改。因此对这些线程访问更新的时候乐观锁才会进行检测查看这个进程的访问是否会造成冲突，如果会的话就返回错误信息由用户决定是否如何去做

悲观锁

悲观锁相较于乐观锁也是一种极端，悲观锁认为只要访问就一定会造成并发冲突，因此悲观锁认为只要是访问资源，都必须加上锁，这样当别人想要获取这个资源的时候就必须获取这把锁陷入了阻塞等待当中。

两者的比较

这里我们举一个例子来说明

假如说甲乙两位同学向老师请问问题，那么甲是一个悲观的人，乙是一个乐观的人，甲突然去找老师，老师肯定在忙碌无法给自己将题目，因此会先给老师发个消息询问老师是否在忙碌当得到老师的答复之后再决定是继续等待还是直接过去，而乙则是比较乐观，认为自己现在过去不会打扰到老师，老师可以立即解答自己的疑惑，因此乙就会直接过去询问老师问题，这时候可能老师确实没有忙碌可以直接解决问题也有可能老师是在忙碌的，这时候乙就需要进行等待了。

结论:两把锁各有特点针对于不同的场合使用不同的锁没有什么优劣性比较。

读写锁

读写锁。线程对一个资源的访问是分为读操作和写操作的，那么对于一个资源来说读操作是不会导致线程不安全的只有写操作才会导致线程不安全，因此线程对一个资源的访问加锁我们也可以分为读锁和写锁来进行，因此我们就需要搞明白哪些情况会导致线程不安全

线程同时去读取一个数据：安全的
一批线程去读另一批线程在写：不安全
线程都在写：不安全

因此读写锁，也就诞生了，那么读写锁是怎么进行加锁的呢？按照字面意思肯定就是按照一个线程是读还是写来区别加锁了。那么既然是按照意图来进行区别加锁的我们首先当然要清除这个线程想要进行的操作是什么才可以来进行加锁。也就是加锁前需要获取这个线程的行为意图。
读写锁就是把读操作和写操作区分对待. Java 标准库提供了 ReentrantReadWriteLock 类, 实现了读写
锁.
我们来写一个示例代码运行一下查看

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

public class Lock_policy  {
    public static  int tmp=10;
    public static final ReentrantReadWriteLock wrlock=new ReentrantReadWriteLock();
    public static void main(String[] args) {
            Thread t1=new Thread(()->{
                wrlock.readLock().lock();
                System.out.println("我是t1线程"+tmp);
                //wrlock.readLock().unlock();

            });
            Thread t2=new Thread(()->{
                wrlock.readLock().lock();
                System.out.println("我是t2线程"+tmp);
                //wrlock.readLock().unlock();
            });
            Thread t3=new Thread(()->{
                wrlock.writeLock().lock();
                tmp++;
                System.out.println("我是t3线程"+tmp);
            });
            t1.start();
            t2.start();
    }
}

首先我们可以观察到这个代码中我们创建的t3线程并没有start运行因此我们测试的是当两个线程同时加上读锁并且读一个数据的时候是否会阻塞我们看一下运行结果。
在这里插入图片描述
结果很明显程序正常跑完因此没有任何的阻塞。我们来试试把t3线程运行试试结果。

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

public class Lock_policy  {
    public static  int tmp=10;
    public static final ReentrantReadWriteLock wrlock=new ReentrantReadWriteLock();
    public static void main(String[] args) {
            Thread t1=new Thread(()->{
                wrlock.readLock().lock();
                System.out.println("我是t1线程"+tmp);
                //wrlock.readLock().unlock();

            });
            Thread t2=new Thread(()->{
                wrlock.readLock().lock();
                System.out.println("我是t2线程"+tmp);
                //wrlock.readLock().unlock();
            });
            Thread t3=new Thread(()->{
                wrlock.writeLock().lock();
                tmp++;
                System.out.println("我是t3线程"+tmp);
            });
            t1.start();
            t2.start();
            t3.start();
    }
}

运行截图如下
在这里插入图片描述
那么是否只有这一种结果呢？当然不是。

在实验的过程中我们可能产生这些不同的结果那么这是为什么呢？原因很简单那就是因为t3线程在t1和t2线程获取读锁之前就已经加上了写锁导致了t1和t2的读操作阻塞了。那么无论上述的哪种结果都是可以说明读写锁中读锁和写锁是阻塞的。

重量级锁和轻量级锁

重量级锁

在理解这里的时候我们要先搞明白什么是重量级锁。顾名思义听名字就感觉这个锁很慢，那么这种原因究竟是为什么呢？这就要追溯到锁的一个机制了。

我们要搞明白加锁是为了干什么？很简单加锁是为了保证我们的多个操作是原子性的。原子性的保证使得我们的操作避免了多线程的安全问题。那么为什么锁可以保证操作的原子性呢？其实说白了还是因为我们的硬件设备的支持也就是底层建筑决定上层建筑，因为我们的硬件支持，所以我们的操作系统可以给我们提供一系列的锁的操作接口，而操作系统提供的接口就是mutex。