多线程之死锁就是这么简单

「爱情、让人受尽委屈。」 2021-09-15 09:26 309阅读 0赞

# 前言 #

> 只有光头才能变强

回顾前面：

*  [ThreadLocal就是这么简单][ThreadLocal]
 *  [多线程三分钟就可以入个门了！][Link 1]
 *  [多线程基础必要知识点！看了学习多线程事半功倍][Link 2]
 *  [Java锁机制了解一下][Java]
 *  [AQS简简单单过一遍][AQS]
 *  [Lock锁子类了解一下][Lock]
 *  [线程池你真不来了解一下吗？][Link 3]

本篇主要是讲解**死锁**，这是我在多线程的最后一篇了。主要将多线程的基础**过一遍**，以后**有机会再继续深入**！

死锁是在多线程中也是比较重要的知识点了！

那么接下来就开始吧，如果文章有错误的地方请大家多多包涵，不吝在评论区指正哦~

> 声明：本文使用JDK1.8

# 一、死锁讲解 #

在Java中使用多线程，就会**有可能导致死锁**问题。死锁会让程序一直**卡**住，不再程序往下执行。我们只能通过**中止并重启**的方式来让程序重新执行。

*  这是我们非常不愿意看到的一种现象，我们要**尽可能**避免死锁的情况发生！

造成死锁的原因可以**概括**成三句话：

*  当前线程**拥有其他线程需要的**资源
 *  当前线程**等待其他线程已拥有**的资源
 *  **都不放弃**自己拥有的资源

## 1.1锁顺序死锁 ##

首先我们来看一下最简单的死锁(锁顺序死锁)是怎么样发生的：

public class LeftRightDeadlock { 
        private final Object left = new Object();
        private final Object right = new Object();
    
        public void leftRight() {
            // 得到left锁
            synchronized (left) {
                // 得到right锁
                synchronized (right) {
                    doSomething();
                }
            }
        }
    
        public void rightLeft() {
            // 得到right锁
            synchronized (right) {
                // 得到left锁
                synchronized (left) {
                    doSomethingElse();
                }
            }
        }
    }

我们的线程是**交错执行**的，那么就很有可能出现以下的情况：

*  线程A调用`leftRight()`方法，得到left锁
 *  **同时**线程B调用`rightLeft()`方法，得到right锁
 *  线程A和线程B都继续执行，此时线程A需要right锁**才能继续往下**执行。此时线程B需要left锁**才能继续往下**执行。
 *  但是：**线程A的left锁并没有释放，线程B的right锁也没有释放**。
 *  所以他们都只能等待，而这种等待是无期限的–>永久等待–>死锁

![163350c1153053c4_w_3264_h_2448_f_jpeg_s_564724][]

## 1.2动态锁顺序死锁 ##

我们看一下下面的例子，你认为会发生死锁吗？

// 转账
        public static void transferMoney(Account fromAccount,
                                         Account toAccount,
                                         DollarAmount amount)
                throws InsufficientFundsException {
    
            // 锁定汇账账户
            synchronized (fromAccount) {
                // 锁定来账账户
                synchronized (toAccount) {
    
                    // 判余额是否大于0
                    if (fromAccount.getBalance().compareTo(amount) < 0) {
                        throw new InsufficientFundsException();
                    } else {
    
                        // 汇账账户减钱
                        fromAccount.debit(amount);
    
                        // 来账账户增钱
                        toAccount.credit(amount);
                    }
                }
            }
        }

上面的代码**看起来是没有问题的**：锁定两个账户来判断余额是否充足才进行转账！

但是，同样**有可能会发生死锁**：

*  如果两个线程**同时**调用`transferMoney()`
 *  线程A从X账户向Y账户转账
 *  线程B从账户Y向账户X转账
 *  那么就会发生死锁。

A:transferMoney(myAccount,yourAccount,10);
    
    
    B:transferMoney(yourAccount,myAccount,20);

## 1.3协作对象之间发生死锁 ##

我们来看一下下面的例子：

public class CooperatingDeadlock { 
        // Warning: deadlock-prone!
        class Taxi {
            @GuardedBy("this") private Point location, destination;
            private final Dispatcher dispatcher;
    
            public Taxi(Dispatcher dispatcher) {
                this.dispatcher = dispatcher;
            }
    
            public synchronized Point getLocation() {
                return location;
            }
    
            // setLocation 需要Taxi内置锁
            public synchronized void setLocation(Point location) {
                this.location = location;
                if (location.equals(destination))
                    // 调用notifyAvailable()需要Dispatcher内置锁
                    dispatcher.notifyAvailable(this);
            }
    
            public synchronized Point getDestination() {
                return destination;
            }
    
            public synchronized void setDestination(Point destination) {
                this.destination = destination;
            }
        }
    
        class Dispatcher {
            @GuardedBy("this") private final Set<Taxi> taxis;
            @GuardedBy("this") private final Set<Taxi> availableTaxis;
    
            public Dispatcher() {
                taxis = new HashSet<Taxi>();
                availableTaxis = new HashSet<Taxi>();
            }
    
            public synchronized void notifyAvailable(Taxi taxi) {
                availableTaxis.add(taxi);
            }
    
            // 调用getImage()需要Dispatcher内置锁
            public synchronized Image getImage() {
                Image image = new Image();
                for (Taxi t : taxis)
                    // 调用getLocation()需要Taxi内置锁
                    image.drawMarker(t.getLocation());
                return image;
            }
        }
    
        class Image {
            public void drawMarker(Point p) {
            }
        }
    }

上面的`getImage()`和`setLocation(Point location)`都需要获取两个锁的

*  并且在操作**途中是没有释放锁的**

这就是**隐式获取两个锁**(对象之间协作)..

这种方式**也很容易就造成死锁**…..

# 二、避免死锁的方法 #

避免死锁可以概括成三种方法：

*  **固定加锁的顺序**(针对锁顺序死锁)
 *  **开放调用**(针对对象之间协作造成的死锁)
 *  **使用定时锁**–>`tryLock()`  
    
    
     *  如果等待获取锁时间超时，则**抛出异常而不是一直等待**！

## 2.1固定锁顺序避免死锁 ##

上面`transferMoney()`发生死锁的原因是因为**加锁顺序**不一致而出现的~

*  正如书上所说的：如果所有线程**以固定的顺序来获得锁**，那么程序中就不会出现锁顺序死锁问题！

那么上面的例子我们就可以**改造**成这样子：

public class InduceLockOrder { 
    
        // 额外的锁、避免两个对象hash值相等的情况(即使很少)
        private static final Object tieLock = new Object();
    
        public void transferMoney(final Account fromAcct,
                                  final Account toAcct,
                                  final DollarAmount amount)
                throws InsufficientFundsException {
            class Helper {
                public void transfer() throws InsufficientFundsException {
                    if (fromAcct.getBalance().compareTo(amount) < 0)
                        throw new InsufficientFundsException();
                    else {
                        fromAcct.debit(amount);
                        toAcct.credit(amount);
                    }
                }
            }
            // 得到锁的hash值
            int fromHash = System.identityHashCode(fromAcct);
            int toHash = System.identityHashCode(toAcct);
    
            // 根据hash值来上锁
            if (fromHash < toHash) {
                synchronized (fromAcct) {
                    synchronized (toAcct) {
                        new Helper().transfer();
                    }
                }
    
            } else if (fromHash > toHash) {
       // 根据hash值来上锁
                synchronized (toAcct) {
                    synchronized (fromAcct) {
                        new Helper().transfer();
                    }
                }
            } else {
       // 额外的锁、避免两个对象hash值相等的情况(即使很少)
                synchronized (tieLock) {
                    synchronized (fromAcct) {
                        synchronized (toAcct) {
                            new Helper().transfer();
                        }
                    }
                }
            }
        }
    }

得到对应的**hash值来固定加锁的顺序**，这样我们就不会发生死锁的问题了！

## 2.2开放调用避免死锁 ##

在协作对象之间发生死锁的例子中，主要是因为在**调用某个方法时就需要持有锁**，并且在方法内部也调用了其他带锁的方法！

*  **如果在调用某个方法时不需要持有锁，那么这种调用被称为开放调用**！

我们可以这样来改造：

*  同步代码块最好**仅被用于保护那些涉及共享状态的操作**！

class CooperatingNoDeadlock {
        @ThreadSafe
        class Taxi {
            @GuardedBy("this") private Point location, destination;
            private final Dispatcher dispatcher;
    
            public Taxi(Dispatcher dispatcher) {
                this.dispatcher = dispatcher;
            }
    
            public synchronized Point getLocation() {
                return location;
            }
    
            public synchronized void setLocation(Point location) {
                boolean reachedDestination;
    
                // 加Taxi内置锁
                synchronized (this) {
                    this.location = location;
                    reachedDestination = location.equals(destination);
                }
                // 执行同步代码块后完毕，释放锁
    
    
    
                if (reachedDestination)
                    // 加Dispatcher内置锁
                    dispatcher.notifyAvailable(this);
            }
    
            public synchronized Point getDestination() {
                return destination;
            }
    
            public synchronized void setDestination(Point destination) {
                this.destination = destination;
            }
        }
    
        @ThreadSafe
        class Dispatcher {
            @GuardedBy("this") private final Set<Taxi> taxis;
            @GuardedBy("this") private final Set<Taxi> availableTaxis;
    
            public Dispatcher() {
                taxis = new HashSet<Taxi>();
                availableTaxis = new HashSet<Taxi>();
            }
    
            public synchronized void notifyAvailable(Taxi taxi) {
                availableTaxis.add(taxi);
            }
    
            public Image getImage() {
                Set<Taxi> copy;
    
                // Dispatcher内置锁
                synchronized (this) {
                    copy = new HashSet<Taxi>(taxis);
                }
                // 执行同步代码块后完毕，释放锁
    
                Image image = new Image();
                for (Taxi t : copy)
                    // 加Taix内置锁
                    image.drawMarker(t.getLocation());
                return image;
            }
        }
    
        class Image {
            public void drawMarker(Point p) {
            }
        }
    
    }

使用开放调用是**非常好的一种方式**，应该尽量使用它~

## 2.3使用定时锁 ##

使用显式Lock锁，在获取锁时使用`tryLock()`方法。当等待**超过时限**的时候，`tryLock()`不会一直等待，而是返回错误信息。

使用`tryLock()`能够有效避免死锁问题~~

## 2.4死锁检测 ##

虽然造成死锁的原因是因为我们设计得不够好，但是可能写代码的时候不知道哪里发生了死锁。

JDK提供了两种方式来给我们检测：

*  JconsoleJDK自带的图形化界面工具，使用JDK给我们的的工具JConsole
 *  Jstack是JDK自带的命令行工具，主要用于线程Dump分析。

具体可参考：

*  [https://www.cnblogs.com/flyingeagle/articles/6853167.html][https_www.cnblogs.com_flyingeagle_articles_6853167.html]

# 三、总结 #

发生死锁的原因主要由于：

*  线程之间交错执行  
    
    
     *  解决：**以固定的顺序加锁**
 *  执行某方法时就需要持有锁，且不释放  
    
    
     *  解决：**缩减同步代码块范围，最好仅操作共享变量时才加锁**
 *  永久等待  
    
    
     *  解决：使用`tryLock()`定时锁，超过时限则返回错误信息

在操作系统层面上看待死锁问题(这是我之前做的笔记、很浅显)：

*  [操作系统第五篇【死锁】][Link 4]

参考资料：

*  《Java核心技术卷一》
 *  《Java并发编程实战》
 *  《计算机操作系统 汤小丹》

> 如果文章有错的地方欢迎指正，大家互相交流。习惯在微信看技术文章，想要获取更多的Java资源的同学，可以**关注微信公众号:Java3y**。为了大家方便，刚新建了一下**qq群：742919422**，大家也可以去交流交流。谢谢支持了！希望能多介绍给其他有需要的朋友

**文章的目录导航**：

*  [https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang][https_zhongfucheng.bitcron.com_post_shou-ji_wen-zhang-dao-hang]

[ThreadLocal]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247484118&idx=1&sn=da3e4c4cfd0642687c5d7bcef543fe5b&chksm=ebd743d7dca0cac19a82c7b29b5b22c4b902e9e53bd785d066b625b4272af2a6598a0cc0f38e#rd
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247484186&idx=1&sn=2a7b937e6d3b1623aceac199d3e402f9&chksm=ebd7421bdca0cb0d6206db8c7f063c884c3f0b285975c8e896fde424660b4ccb88da1549f32c#rd
[Link 2]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247484194&idx=1&sn=ed1241fcba5d3e85b6d900d8667f04f6&chksm=ebd74223dca0cb35fe16a267c88ac9e5159825b27c278fb165a8c50d681e1340b73cfd69ae0d#rd
[Java]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247484198&idx=1&sn=4d8e372165bb49987a6243f17153a9b4&chksm=ebd74227dca0cb31311886f835092c9360d08a9f0a249ece34d4b1e49a31c9ec773fa66c8acc#rd
[AQS]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247484202&idx=1&sn=dbf9e94d2486ee0baa43e043a2363231&chksm=ebd7422bdca0cb3dc0451e09d139b72558b1cfa3593a6bcc1716ae9d1bd443804d194a303985#rd
[Lock]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247484206&idx=1&sn=9722748c0308b3e56220be1c9d939ad7&chksm=ebd7422fdca0cb39ac7825e565ac4e7ed7fd77638da1a931f916d3b6c06ef50beb5c085510bf#rd
[Link 3]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247484214&idx=1&sn=9b5c977e0f8329b2bf4c29d230c678fb&chksm=ebd74237dca0cb212f4505935f9905858b9166beddd4603c3d3b5386b5dd8cf240c460a8e7c4#rd
[163350c1153053c4_w_3264_h_2448_f_jpeg_s_564724]: https://user-gold-cdn.xitu.io/2018/5/6/163350c1153053c4?w=3264&h=2448&f=jpeg&s=564724
[https_www.cnblogs.com_flyingeagle_articles_6853167.html]: https://www.cnblogs.com/flyingeagle/articles/6853167.html
[Link 4]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247484186&idx=6&sn=fbe59571e8469fe953404cc632723646&chksm=ebd7421bdca0cb0d85c3a6651e765821d8e0b8aba43e2358d6f3be550a10e0b3ef02bc603715#rd
[https_zhongfucheng.bitcron.com_post_shou-ji_wen-zhang-dao-hang]: https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang