多线程进阶

西瓜�74

已于 2023-05-09 11:36:09 修改

阅读量54

点赞数

文章标签： java 开发语言

于 2023-05-07 17:53:30 首次发布

本文链接：https://blog.csdn.net/qq_68875683/article/details/130328166

版权

本文详细介绍了Java并发编程中的锁策略，包括乐观锁、悲观锁、读写锁、自旋锁的概念和实现，以及synchronized的原理和优化。还探讨了可重入锁、非公平锁、线程池、原子类、信号量、线程安全的集合类和并发工具类等概念，帮助理解Java多线程环境中的同步和控制机制。

摘要由CSDN通过智能技术生成

常见锁策略

乐观锁和悲观锁

乐观锁：假设数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并发冲突进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做。

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

Synchronized 初始使用乐观锁策略. 当发现锁竞争比较频繁的时候, 就会自动切换成悲观锁策略.

读写锁

读写锁就是把读操作和写操作区分对待 . Java 标准库提供了 ReentrantReadWriteLock 类 , 实现了读写锁.

· ReentrantReadWriteLock.ReadLock 类表示一个读锁 . 这个对象提供了 lock / unlock 方法进行加锁解锁.

· ReentrantReadWriteLock.WriteLock 类表示一个写锁 . 这个对象也提供了 lock / unlock 方法进行加锁解锁.

其中 ,

· 读加锁和读加锁之间 , 不互斥 .

· 写加锁和写加锁之间 , 互斥 .

· 读加锁和写加锁之间 , 互斥 .

只要是涉及到 "互斥", 就会产生线程的挂起等待. 一旦线程挂起, 再次被唤醒就不知道隔了多久了. 因此尽可能减少 "互斥" 的机会, 就是提高效率的重要途径

读写锁特别适合于 "频繁读, 不频繁写" 的场景中.

Synchronized 不是读写锁

重量级锁和轻量级锁

重量级锁

· 大量的内核态用户态切换

· 很容易引发线程的调度

这两个操作 , 成本比较高 . 一旦涉及到用户态和内核态的切换 , 就意味着 " 沧海桑田 ".

轻量级锁 :

· 少量的内核态用户态切换 .

· 不太容易引发线程调度

理解用户态和内核态

想象去银行办业务 .

在窗口外 , 自己做 , 这是用户态 . 用户态的时间成本是比较可控的 .

在窗口内 , 工作人员做 , 这是内核态 . 内核态的时间成本是不太可控的 .

如果办业务的时候反复和工作人员沟通 , 还需要重新排队 , 这时效率是很低的 .

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

自旋锁

如果获取锁失败 , 立即再尝试获取锁 , 无限循环 , 直到获取到锁为止 . 第一次获取锁失败 , 第二次的尝试会在极短的时间内到来.

一旦锁被其他线程释放 , 就能第一时间获取到锁 .

// 自旋锁伪代码

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

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

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

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

synchronized 中的轻量级锁策略大概率就是通过自旋锁的方式实现的 .

公平锁和非公平锁

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

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

注意：

操作系统内部的线程调度就可以视为是随机的 . 如果不做任何额外的限制 , 锁就是非公平锁 . 如果要想实现公平锁, 就需要依赖 额外的数据结构 , 来记录线程们的先后顺序 .

公平锁和非公平锁没有好坏之分 , 关键还是看适用场景 .

synchronized 是非公平锁

可重入锁和不可重入锁

可重入锁的字面意思是 “ 可以重新进入的锁 ” ，即 允许同一个线程多次获取同一把锁 。

比如一个递归函数里有加锁操作，递归过程中这个锁会阻塞自己吗？如果不会，那么这个锁就是 可重入 锁（因为这个原因可重入锁也叫做 递归锁 ）。

Java 里只要以 Reentrant 开头命名的锁都是可重入锁，而且 JDK 提供的所有现成的 Lock 实现类，包括 synchronized 关键字锁都是可重入的。

而 Linux 系统提供的 mutex 是不可重入锁 .

synchronized 是可重入锁

CAS

什么是 CAS

CAS: 全称 Compare and swap ，字面意思 :” 比较并交换 “ ，一个 CAS 涉及到以下操作：

我们假设内存中的原数据 V ，旧的预期值 A ，需要修改的新值 B 。

1. 比较 A 与 V 是否相等。（比较）

2. 如果比较相等，将 B 写入 V 。（交换）

3. 返回操作是否成功。

当多个线程同时对某个资源进行 CAS 操作，只能有一个线程操作成功，但是并不会阻塞其他线程 , 其他线程只会收到操作失败的信号。

CAS 可以视为是一种乐观锁 . ( 或者可以理解成 CAS 是乐观锁的一种实现方式 )

CAS 是怎么实现的

针对不同的操作系统， JVM 用到了不同的 CAS 实现原理，简单来讲：

· java 的 CAS 利用的的是 unsafe 这个类提供的 CAS 操作；

· unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg ；

· Atomic::cmpxchg 的实现使用了汇编的 CAS 操作，并使用 cpu 硬件提供的 lock 机制保证其原子性。

简而言之，是因为 硬件予以了支持，软件层面才能做到 。

CAS 有哪些应用

1) 实现原子类

标准库中提供了 java.util.concurrent.atomic 包 , 里面的类都是基于这种方式来实现的 .

典型的就是 AtomicInteger 类. 其中的 getAndIncrement 相当于 i++ 操作.

AtomicInteger atomicInteger = new AtomicInteger(0);
// 相当于 i++
atomicInteger.getAndIncrement();

2) 实现自旋锁

基于 CAS 实现更灵活的锁 , 获取到更多的控制权 .

CAS 的 ABA 问题

什么是 ABA 问题

1）假设存在两个线程 t1 和 t2. 有一个共享变量 num, 初始值为 A

2）接下来 , 线程 t1 想使用 CAS 把 num 值改成 Z, 那么就需要

3）先读取 num 的值 , 记录到 oldNum 变量中 .

4）但是 , 在 t1 执行这两个操作之间 , t2 线程可能把 num 的值从 A 改成了 B, 又从 B 改成了 A

5）到这一步 , t1 线程无法区分当前这个变量始终是 A, 还是经历了一个变化过程 .

ABA 问题引来的 BUG

大部分的情况下 , t2 线程这样的一个反复横跳改动 , 对于 t1 是否修改 num 是没有影响的 . 但是不排除一些特殊情况.

假设滑稽老哥有 100 存款 . 滑稽想从 ATM 取 50 块钱 . 取款机创建了两个线程 , 并发的来执行 -50 操作.

我们期望一个线程执行 -50 成功 , 另一个线程 -50 失败 .

如果使用 CAS 的方式来完成这个扣款过程就可能出现问题 .

1) 存款 100. 线程 1 获取到当前存款值为 100, 期望更新为 50; 线程 2 获取到当前存款值为 100, 期

望更新为 50.

2) 线程 1 执行扣款成功 , 存款被改成 50. 线程 2 阻塞等待中 .

3) 在线程 2 执行之前 , 滑稽的朋友正好给滑稽转账 50, 账户余额变成 100 !!

4) 轮到线程 2 执行了 , 发现当前存款为 100, 和之前读到的 100 相同 , 再次执行扣款操作

这个时候 , 扣款操作被执行了两次 !!! 都是 ABA 问题搞的鬼。

解决方案

给要修改的值 , 引入版本号 . 在 CAS 比较数据当前值和旧值的同时 , 也要比较版本号是否符合预期 .

CAS 操作在读取旧值的同时 , 也要读取版本号 .

真正修改的时候 ,

· 如果当前版本号和读到的版本号相同 , 则修改数据 , 并把版本号 + 1.

· 如果当前版本号高于读到的版本号 . 就操作失败 ( 认为数据已经被修改过了 ).

相关面试题

1) 讲解下你自己理解的 CAS 机制

全称 Compare and swap, 即 " 比较并交换 ". 相当于通过一个原子的操作 , 同时完成 " 读取内存 , 比

较是否相等 , 修改内存 " 这三个步骤 . 本质上需要 CPU 指令的支撑 .

2) ABA问题怎么解决？

给要修改的数据引入版本号 . 在 CAS 比较数据当前值和旧值的同时 , 也要比较版本号是否符合预期 .

如果发现当前版本号和之前读到的版本号一致 , 就真正执行修改操作 , 并让版本号自增 ; 如果发现当

前版本号比之前读到的版本号大 , 就认为操作失败 .

Synchronized 原理

基本特点

1. 开始时是乐观锁 , 如果锁冲突频繁 , 就转换为悲观锁 .

2. 开始是轻量级锁实现 , 如果锁被持有的时间较长 , 就转换成重量级锁 .

3. 实现轻量级锁的时候大概率用到的自旋锁策略

4. 是一种不公平锁

5. 是一种可重入锁

6. 不是读写锁

加锁工作过程

JVM 将 synchronized 锁分为无锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进行依升级。

1) 偏向锁

第一个尝试加锁的线程, 优先进入偏向锁状态.

偏向锁不是真的 " 加锁 ", 只是给对象头中做一个 " 偏向锁的标记 ", 记录这个锁属于哪个线程 .

如果后续没有其他线程来竞争该锁 , 那么就不用进行其他同步操作了 ( 避免了加锁解锁的开销 )

如果后续有其他线程来竞争该锁 ( 刚才已经在锁对象中记录了当前锁属于哪个线程了 , 很容易识别

当前申请锁的线程是不是之前记录的线程 ), 那就取消原来的偏向锁状态 , 进入一般的轻量级锁状态 .

偏向锁本质上相当于 " 延迟加锁 " . 能不加锁就不加锁 , 尽量来避免不必要的加锁开销 .

但是该做的标记还是得做的 , 否则无法区分何时需要真正加锁 .

2) 轻量级锁

随着其他线程进入竞争 , 偏向锁状态被消除 , 进入轻量级锁状态 ( 自适应的自旋锁 ).

此处的轻量级锁就是通过 CAS 来实现

· 通过 CAS 检查并更新一块内存 ( 比如 null => 该线程引用 )

· 如果更新成功 , 则认为加锁成功

· 如果更新失败 , 则认为锁被占用 , 继续自旋式的等待 ( 并不放弃 CPU).

自旋操作是一直让 CPU 空转 , 比较浪费 CPU 资源 .

因此此处的自旋不会一直持续进行 , 而是达到一定的时间 / 重试次数 , 就不再自旋了 .

也就是所谓的 " 自适应"

3) 重量级锁

如果竞争进一步激烈 , 自旋不能快速获取到锁状态 , 就会膨胀为重量级锁

此处的重量级锁就是指用到内核提供的 mutex .

· 执行加锁操作 , 先进入内核态 .

· 在内核态判定当前锁是否已经被占用

· 如果该锁没有占用 , 则加锁成功 , 并切换回用户态 .

· 如果该锁被占用 , 则加锁失败 . 此时线程进入锁的等待队列 , 挂起 . 等待被操作系统唤醒 .

· 经历了一系列的沧海桑田 , 这个锁被其他线程释放了 , 操作系统也想起了这个挂起的线程 , 于是唤醒这个线程, 尝试重新获取锁 .

其他的优化操作

锁消除

编译器 +JVM 判断锁是否可消除 . 如果可以 , 就直接消除 .

什么是 " 锁消除 "

//有些应用程序的代码中, 用到了 synchronized, 但其实没有在多线程环境下. (例如 StringBuffer)

StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");

/*此时每个 append 的调用都会涉及加锁和解锁. 但如果只是在单线程中执行这个代码, 那么这些加
锁解锁操作是没有必要的, 白白浪费了一些资源开销.*/

锁粗化

一段逻辑中如果出现多次加锁解锁 , 编译器 + JVM 会自动进行锁的粗化 .

锁的粒度: 粗和细

实际开发过程中, 使用细粒度锁, 是期望释放锁的时候其他线程能使用锁.

但是实际上可能并没有其他线程来抢占这个锁. 这种情况 JVM 就会自动把锁粗化, 避免频繁申请释放锁.

Callable 接口

Callable 的用法

Callable 是一个 interface . 相当于把线程封装了一个 "返回值". 方便程序猿借助多线程的方式计算结果.

代码示例: 创建线程计算 1 + 2 + 3 + ... + 1000

// 创建一个匿名内部类, 实现 Callable 接口. Callable 带有泛型参数. 泛型参数表示返回值的类型. 
Callable<Integer> callable = new Callable<Integer>() {

// 重写 Callable 的 call 方法, 完成累加的过程. 直接通过返回值返回计算结果. 
    @Override
    public Integer call() throws Exception {
        int sum = 0;
        for (int i = 1; i <= 1000; i++) {
            sum += i;
       }
        return sum;
   }
};

// 把 callable 实例使用 FutureTask 包装一下. 
FutureTask<Integer> futureTask = new FutureTask<>(callable);

// 创建线程, 线程的构造方法传入 FutureTask . 此时新线程就会执行 FutureTask 内部的 Callable 的call 方法, 完成计算. 计算结果就放到了 FutureTask 对象中. 
Thread t = new Thread(futureTask);
t.start();

//在主线程中调用 futureTask.get() 能够阻塞等待新线程计算完毕. 并获取到 FutureTask 中的结果.
int result = futureTask.get();
System.out.println(result);

理解 Callable

Callable 和 Runnable 相对 , 都是描述一个 " 任务 ". Callable 描述的是带有返回值的任务 ,

Runnable 描述的是不带返回值的任务.

Callable 通常需要搭配 FutureTask 来使用 . FutureTask 用来保存 Callable 的返回结果 . 因为 Callable 往往是在另一个线程中执行的 , 啥时候执行完并不确定 .

FutureTask 就可以负责这个等待结果出来的工作 .

理解 FutureTask

想象去吃麻辣烫 . 当餐点好后 , 后厨就开始做了 . 同时前台会给你一张 " 小票 " . 这个小票就是 FutureTask. 后面我们可以随时凭这张小票去查看自己的这份麻辣烫做出来了没 .

JUC(java.util.concurrent) 的常见类

ReentrantLock

可重入互斥锁 . 和 synchronized 定位类似 , 都是用来实现互斥效果 , 保证线程安全 .

ReentrantLock 的用法:

· lock(): 加锁 , 如果获取不到锁就死等 .

· trylock( 超时时间 ): 加锁 , 如果获取不到锁 , 等待一定的时间之后就放弃加锁 .

· unlock(): 解锁

ReentrantLock 和 synchronized 的区别:

· synchronized 是一个关键字 , 是 JVM 内部实现的 ( 大概率是基于 C++ 实现 ). ReentrantLock 是标准库的一个类, 在 JVM 外实现的 ( 基于 Java 实现 ).

· synchronized 使用时不需要手动释放锁 . ReentrantLock 使用时需要手动释放 . 使用起来更灵活 , 但是也容易遗漏 unlock.

· synchronized 在申请锁失败时 , 会死等 . ReentrantLock 可以通过 trylock 的方式等待一段时间就放弃.

· synchronized 是非公平锁 , ReentrantLock 默认是非公平锁 . 可以通过构造方法传入一个 true 开启公平锁模式.

· 更强大的唤醒机制 . synchronized 是通过 Object 的 wait / notify 实现等待 - 唤醒 . 每次唤醒的是一个随机等待的线程. ReentrantLock 搭配 Condition 类实现等待 - 唤醒 , 可以更精确控制唤醒某个指定的线程.

如何选择使用哪个锁?

锁竞争不激烈的时候 , 使用 synchronized, 效率更高 , 自动释放更方便 .

锁竞争激烈的时候 , 使用 ReentrantLock, 搭配 trylock 更灵活控制加锁的行为 , 而不是死等 .

如果需要使用公平锁 , 使用 ReentrantLock.

原子类

原子类内部用的是 CAS 实现，所以性能要比加锁实现 i++ 高很多。原子类有以下几个

AtomicBoolean

AtomicInteger

AtomicIntegerArray

AtomicLong

AtomicReference

AtomicStampedReference

以 AtomicInteger 举例，常见方法有：

addAndGet(int delta); i += delta;

decrementAndGet(); --i;

getAndDecrement(); i--;

incrementAndGet(); ++i;

getAndIncrement(); i++;

线程池

虽然创建销毁线程比创建销毁进程更轻量 , 但是在频繁创建销毁线程的时候还是会比较低效 .

线程池就是为了解决这个问题. 如果某个线程不再使用了 , 并不是真正把线程释放 , 而是放到一个 " 池子 "中, 下次如果需要用到线程就直接从池子中取 , 不必通过系统来创建了 .

ExecutorService 和 Executors

代码示例 :

// ExecutorService 表示一个线程池实例.
// Executors 是一个工厂类, 能够创建出几种不同风格的线程池.
ExecutorService pool = Executors.newFixedThreadPool(10);

// ExecutorService 的 submit 方法能够向线程池中提交若干个任务.
pool.submit(new Runnable() {

    @Override
    public void run() {
        System.out.println("hello");
   }

});

Executors 创建线程池的几种方式

· newFixedThreadPool: 创建固定线程数的线程池

· newCachedThreadPool: 创建线程数目动态增长的线程池 .

· newSingleThreadExecutor: 创建只包含单个线程的线程池 .

· newScheduledThreadPool: 设定延迟时间后执行命令，或者定期执行命令 . 是进阶版的 Timer.

线程池的工作流程

信号量 Semaphore

用来表示 "可用资源的个数". 本质上就是一个计数器

代码示例：

// 创建 Semaphore 示例, 初始化为 4, 表示有 4 个可用资源.
Semaphore semaphore = new Semaphore(4);

Runnable runnable = new Runnable() {

// acquire 方法表示申请资源(P操作), release 方法表示释放资源(V操作)

// 创建 20 个线程, 每个线程都尝试申请资源, sleep 1秒之后, 释放资源. 观察程序的执行效果.

    @Override
    public void run() {

        try {
            System.out.println("申请资源");
            semaphore.acquire();
            System.out.println("我获取到资源了");
            Thread.sleep(1000);
            System.out.println("我释放资源了");
            semaphore.release();

       } catch (InterruptedException e) {

            e.printStackTrace();

       }
   }
};

for (int i = 0; i < 20; i++) {
    Thread t = new Thread(runnable);
    t.start();
}

CountDownLatch

同时等待 N 个任务执行结束.

// 好像跑步比赛，10个选手依次就位，哨声响才同时出发；所有选手都通过终点，才能公布成绩。

代码示例：

public class Demo {
    public static void main(String[] args) throws Exception {

        // 构造 CountDownLatch 实例, 初始化 10 表示有 10 个任务需要完成.
        CountDownLatch latch = new CountDownLatch(10);

        Runnable r = new Runable() {

        // 每个任务执行完毕, 都调用 latch.countDown() . 在 CountDownLatch 内部的计数器同时自减.
            @Override
            public void run() {

                try {

                    Thread.sleep(10000);
                    latch.countDown();

               } catch (Exception e) {

                    e.printStackTrace();
               }
           }
       };

        for (int i = 0; i < 10; i++) {

            new Thread(r).start();

       }

       // 主线程中使用 latch.await(); 阻塞等待所有任务执行完毕. 相当于计数器为 0 了.
       // 必须等到 10 人全部回来

        latch.await();
        System.out.println("比赛结束");

   }
}

线程安全的集合类

原来的集合类, 大部分都不是线程安全的.

Vector, Stack, HashTable, 是线程安全的 ( 不建议用 ), 其他的集合类不是线程安全的 .

多线程环境使用 ArrayList

1) 自己使用同步机制 (synchronized 或者 ReentrantLock)

2) Collections.synchronizedList(new ArrayList);

synchronizedList 是标准库提供的一个基于 synchronized 进行线程同步的 List.

synchronizedList 的关键操作上都带有 synchronized

3) 使用 CopyOnWriteArrayList

CopyOnWrite 容器即写时复制的容器。

· 当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行 Copy ，复制出一个新的容器，然后新的容器里添加元素，

· 添加完元素之后，再将原容器的引用指向新的容器。

这样做的好处是我们可以对 CopyOnWrite 容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。

所以 CopyOnWrite 容器也是一种读写分离的思想，读和写不同的容器。

优点 :

在读多写少的场景下 , 性能很高 , 不需要加锁竞争 .

缺点 :

1. 占用内存较多 .

2. 新写的数据不能被第一时间读取到 .

多线程环境使用队列

1) ArrayBlockingQueue

基于数组实现的阻塞队列

2) LinkedBlockingQueue

基于链表实现的阻塞队列

3) PriorityBlockingQueue

基于堆实现的带优先级的阻塞队列

4) TransferQueue

最多只包含一个元素的阻塞队列

多线程环境使用哈希表

HashMap 本身不是线程安全的 .

在多线程环境下使用哈希表可以使用 :

· Hashtable

· ConcurrentHashMap

1) Hashtable

只是简单的把关键方法加上了 synchronized 关键字 .

这相当于直接针对 Hashtable 对象本身加锁 .

· 如果多线程访问同一个 Hashtable 就会直接造成锁冲突 .

· size 属性也是通过 synchronized 来控制同步 , 也是比较慢的 .

· 一旦触发扩容 , 就由该线程完成整个扩容过程 . 这个过程会涉及到大量的元素拷贝 , 效率会非常低 .

2) ConcurrentHashMap

相比于 Hashtable 做出了一系列的改进和优化 . 以 Java1.8 为例

· 读操作没有加锁(但是使用了 volatile 保证从内存读取结果 ), 只对写操作进行加锁 . 加锁的方式仍然是是用 synchronized, 但是不是锁整个对象 , 而是 "锁桶 " ( 用每个链表的头结点作为锁对象 ), 大大降低了锁冲突的概率.

· 充分利用 CAS 特性 . 比如 size 属性通过 CAS 来更新 . 避免出现重量级锁的情况 .

· 优化了扩容方式 : 化整为零

· 发现需要扩容的线程 , 只需要创建一个新的数组 , 同时只搬几个元素过去 .

· 扩容期间 , 新老数组同时存在 .

· 后续每个来操作 ConcurrentHashMap 的线程 , 都会参与搬家的过程 . 每个操作负责搬运一小部分元素.

· 搬完最后一个元素再把老数组删掉 .

· 这个期间 , 插入只往新数组加 .

· 这个期间 , 查找需要同时查新数组和老数组

死锁

死锁是什么

死锁是这样一种情形：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。

为了进一步阐述死锁的形成 , 很多资料上也会谈论到 " 哲学家就餐问题 ".

1）有个桌子 , 围着一圈哲学家 , 桌子中间放着一盘意大利面 . 每个哲学家两两之间 , 放着一根筷子

2）每个哲学家只做两件事 : 思考人生或者吃面条 . 思考人生的时候就会放下筷子 . 吃面条就会拿起左右两边的筷子( 先拿起左边, 再拿起右边 ).

3）如果哲学家发现筷子拿不起来了 ( 被别人占用了 ), 就会阻塞等待 .

4）假设同一时刻 , 五个哲学家同时拿起左手边的筷子 , 然后再尝试拿右手的筷子 , 就会发现右手的筷子都被占用了 . 由于哲学家们互不相让 , 这个时候就形成了死锁

如何避免死锁

死锁产生的四个必要条件：

· 互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用

· 不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。

· 请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。

· 循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。

当上述四个条件都成立的时候，便形成死锁。当然，死锁的情况下如果打破上述任何一个条件，便可让死锁消失。

其中最容易破坏的就是 " 循环等待 ".

破坏循环等待

最常用的一种死锁阻止技术就是 锁排序 . 假设有 N 个线程尝试获取 M 把锁 , 就可以针对 M 把锁进行编号(1, 2, 3...M).

N 个线程尝试获取锁的时候 , 都按照固定的按编号由小到大顺序来获取锁 . 这样就可以避免环路等待 .

可能产生环路等待的代码 :

// 两个线程对于加锁的顺序没有约定, 就容易产生环路等待.

Object lock1 = new Object();
Object lock2 = new Object();

Thread t1 = new Thread() {
    @Override
    public void run() {
        synchronized (lock1) {
            synchronized (lock2) {
                // do something...
           }
       }
   }
};
t1.start();

Thread t2 = new Thread() {
    @Override
    public void run() {
        synchronized (lock2) {
            synchronized (lock1) {
                // do something...
           }
       }
   }
};
t2.start();

不会产生环路等待的代码 :

// 约定好先获取 lock1, 再获取 lock2 , 就不会环路等待.

Object lock1 = new Object();
Object lock2 = new Object();

Thread t1 = new Thread() {
    @Override
    public void run() {
        synchronized (lock1) {
            synchronized (lock2) {
                // do something...
           }
       }
   }
};
t1.start();

Thread t2 = new Thread() {
    @Override
    public void run() {
        synchronized (lock1) {
            synchronized (lock2) {
                // do something...
           }
       }
   }
};
t2.start();