java target目录_Java 编码安全:死锁的产生与避免死锁的方法,纯干货分享~~

↑ 点击上面 “时代Java”关注我们, 关注新技术,学习新知识!

Java提供了种类丰富的锁,每种锁因其特性的不同,在适当的场景下能够展现出非常高的效率。本文旨在对锁相关源码、使用场景进行举例,为读者介绍主流锁的知识点,以及不同的锁的适用场景。

Java中往往是按照是否含有某一特性来定义锁,我们通过特性将锁进行分组归类,再使用对比的方式进行介绍,帮助大家更快捷的理解相关知识。下面给出本文内容的总体分类目录:

f20c0c2b5a617e7284f705d7040c92af.png

Java的线程锁是可重入的锁。

什么是可重入的锁?我们还是来看例子:

public class Counter {    private int count = 0;        public synchronized void add(int n) {                if (n < 0) {            dec(-n);        } else {            count += n;        }    }        public synchronized void dec(int n) {        count += n;    }}

观察synchronized修饰的add()方法,一旦线程执行到add()方法内部,说明它已经获取了当前实例的this锁。如果传入的n < 0,将在add()方法内部调用dec()方法。由于dec()方法也需要获取this锁,现在问题来了:

对同一个线程,能否在获取到锁以后继续获取同一个锁?

答案是肯定的。JVM允许同一个线程重复获取同一个锁,这种能被同一个线程反复获取的锁,就叫做可重入锁。

由于Java的线程锁是可重入锁,所以,获取锁的时候,不但要判断是否是第一次获取,还要记录这是第几次获取。每获取一次锁,记录+1,每退出synchronized块,记录-1,减到0的时候,才会真正释放锁。

死锁

一个线程可以获取一个锁后,再继续获取另一个锁。例如:

public void add(int m) {        synchronized(lockA) { // 获得lockA的锁        this.value += m;                synchronized(lockB) { // 获得lockB的锁            this.another += m;        } // 释放lockB的锁    } // 释放lockA的锁}public void dec(int m) {    synchronized(lockB) { // 获得lockB的锁        this.another -= m;                synchronized(lockA) { // 获得lockA的锁            this.value -= m;       } // 释放lockA的锁    } // 释放lockB的锁}

在获取多个锁的时候,不同线程获取多个不同对象的锁可能导致死锁。对于上述代码,线程1和线程2如果分别执行add()dec()方法时:

  • 线程1:进入add(),获得lockA

  • 线程2:进入dec(),获得lockB

随后:

  • 线程1:准备获得lockB,失败,等待中;

  • 线程2:准备获得lockA,失败,等待中。

此时,两个线程各自持有不同的锁,然后各自试图获取对方手里的锁,造成了双方无限等待下去,这就是死锁。

死锁发生后,没有任何机制能解除死锁,只能强制结束JVM进程。

因此,在编写多线程应用时,要特别注意防止死锁。因为死锁一旦形成,就只能强制结束进程。

那么我们应该如何避免死锁呢?

避免死锁的方法

不同的加锁顺序

我们来看一个不同加锁顺序的例子:

public class DiffLockOrder {    private int amount;    public DiffLockOrder(int amount){       this.amount=amount;    }    public void transfer(DiffLockOrder target,int transferAmount){        synchronized (this){            synchronized (target){                if(amount< transferAmount){                    System.out.println("余额不足!");                }else{                    amount=amount-transferAmount;                    target.amount=target.amount+transferAmount;                }            }        }    }}

上面的例子中,我们模拟一个转账的过程,amount用来表示用户余额。transfer用来将当前账号的一部分金额转移到目标对象中。

为了保证在transfer的过程中,两个账户不被别人修改,我们使用了两个synchronized关键字,分别把transfer对象和目标对象进行锁定。

看起来好像没问题,但是我们没有考虑在调用的过程中,transfer的顺序是可以发送变化的:

DiffLockOrder account1 = new DiffLockOrder(1000);DiffLockOrder account2 = new DiffLockOrder(500);Runnable target1= ()->account1.transfer(account2,200);Runnable target2= ()->account2.transfer(account1,100);new Thread(target1).start();new Thread(target2).start();

上面的例子中,我们定义了两个account,然后两个账户互相转账,最后很有可能导致互相锁定,最后产生死锁。

使用private类变量

使用两个sync会有顺序的问题,那么有没有办法只是用一个sync就可以在所有的实例中同步呢?

有的,我们可以使用private的类变量,因为类变量是在所有实例中共享的,这样一次sync就够了:

public class LockWithPrivateStatic {    private int amount;    private static final Object lock = new Object();    public LockWithPrivateStatic(int amount){       this.amount=amount;    }    public void transfer(LockWithPrivateStatic target, int transferAmount){        synchronized (lock) {            if (amount < transferAmount) {                System.out.println("余额不足!");            } else {                amount = amount - transferAmount;                target.amount = target.amount + transferAmount;            }        }    }}

使用相同的Order

我们产生死锁的原因是无法控制上锁的顺序,如果我们能够控制上锁的顺序,是不是就不会产生死锁了呢?

带着这个思路,我们给对象再加上一个id字段:

private final long id; // 唯一ID,用来排序private static final AtomicLong nextID = new AtomicLong(0); // 用来生成IDpublic DiffLockWithOrder(int amount){  this.amount=amount;  this.id = nextID.getAndIncrement();}

在初始化对象的时候,我们使用static的AtomicLong类来为每个对象生成唯一的ID。

在做transfer的时候,我们先比较两个对象的ID大小,然后根据ID进行排序,最后安装顺序进行加锁。这样就能够保证顺序,从而避免死锁。

public void transfer(DiffLockWithOrder target, int transferAmount){        DiffLockWithOrder fist, second;        if (compareTo(target) < 0) {            fist = this;            second = target;        } else {            fist = target;            second = this;        }        synchronized (fist){            synchronized (second){                if(amount< transferAmount){                    System.out.println("余额不足!");                }else{                    amount=amount-transferAmount;                    target.amount=target.amount+transferAmount;                }            }        }}

释放掉已占有的锁

死锁是互相请求对方占用的锁,但是对方的锁一直没有释放,我们考虑一下,如果获取不到锁的时候,自动释放已占用的锁是不是也可以解决死锁的问题呢?

因为ReentrantLock有一个tryLock()方法,我们可以使用这个方法来判断是否能够获取到锁,获取不到就释放已占有的锁。

我们使用ReentrantLock来完成这个例子:

public class DiffLockWithReentrantLock {    private int amount;    private final Lock lock = new ReentrantLock();    public DiffLockWithReentrantLock(int amount){        this.amount=amount;    }    private void transfer(DiffLockWithReentrantLock target, int transferAmount)            throws InterruptedException {        while (true) {            if (this.lock.tryLock()) {                try {                    if (target.lock.tryLock()) {                        try {                            if(amount< transferAmount){                                System.out.println("余额不足!");                            }else{                                amount=amount-transferAmount;                                target.amount=target.amount+transferAmount;                            }                            break;                        } finally {                            target.lock.unlock();                        }                    }                } finally {                    this.lock.unlock();                }            }            //随机sleep一定的时间,保证可以释放掉锁            Thread.sleep(1000+new Random(1000L).nextInt(1000));        }    }}

我们把两个tryLock方法在while循环中,如果不能获取到锁就循环遍历。

--

知识分享,时代前行!

~~ 时代Java

还有更多好文章……

请查看历史文章和官网,

↓有分享,有收获~

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值