浅谈Java由于不当的执行顺序导致的死锁

2024-08-01 11:04:36

我们来讨论一个经常存在的账户转账的问题。账户A要转账给账户B。为了保证在转账的过程中A和B不被其他的线程意外的操作，我们需要给A和B加锁，然后再进行转账操作，我们看下转账的代码：

public void transferMoneyDeadLock(Account from,Account to, int amount) throws InsufficientAmountException {
    synchronized (from){
        synchronized (to){
            transfer(from,to,amount);
        }
    }
}

private void transfer(Account from,Account to, int amount) throws InsufficientAmountException {
    if(from.getBalance() < amount){
        throw new InsufficientAmountException();
    }else{
        from.debit(amount);
        to.credit(amount);
    }
}

看起来上面的程序好像没有问题，因为我们给from和to都加了锁，程序应该可以很完美的按照我们的要求来执行。

那如果我们考虑下面的一个场景：

A：transferMoneyDeadLock（accountA, accountB, 20）
B：transferMoneyDeadLock（accountB, accountA, 10）

如果A和B同时执行，则可能会产生A获得了accountA的锁，而B获得了accountB的锁。从而后面的代码无法继续执行，从而导致了死锁。

对于这样的情况，我们有没有什么好办法来处理呢？

加入不管参数怎么传递，我们都先lock accountA再lock accountB是不是就不会出现死锁的问题了呢？

我们看下代码实现：

private void transfer(Account from,Account to, int amount) throws InsufficientAmountException {
    if(from.getBalance() < amount){
        throw new InsufficientAmountException();
    }else{
        from.debit(amount);
        to.credit(amount);
    }
}

public void transferMoney(Account from,Account to, int amount) throws InsufficientAmountException {

    int fromHash= System.identityHashCode(from);
    int toHash = System.identityHashCode(to);

    if(fromHash < toHash){
        synchronized (from){
            synchronized (to){
                transfer(from,to, amount);
            }
        }
    }else if(fromHash < toHash){
        synchronized (to){
            synchronized (from){
                transfer(from,to, amount);
            }
        }
    }else{
        synchronized (lock){
        synchronized (from) {
            synchronized (to) {
                transfer(from, to, amount);
            }
            }
        }
    }
}

上面的例子中，我们使用了System.identityHashCode来获得两个账号的hash值，通过比较hash值的大小来选定lock的顺序。

如果两个账号的hash值恰好相等的情况下，我们引入了一个新的外部lock，从而保证同一时间只有一个线程能够运行内部的方法，从而保证了任务的执行而不产生死锁。

以上就是浅谈Java由于不当的执行顺序导致的死锁的详细内容，更多关于Java由于不当的执行顺序导致的死锁的资料请关注我们其它相关文章！

Java中常见死锁与活锁的实例详解

本文介绍了Java中常见死锁与活锁的实例详解,分享给大家,具体如下: 顺序死锁:过度加锁,导致由于执行顺序的原因,互相持有对方正在等待的锁资源死锁:多个线程在相同的资源上发生等待由于调用顺序而产生的死锁 public class Test { Object leftLock = new Object(); Object rightLock = new Object(); public static void main(String[] args) { final Test test = ne
java实现死锁的示例代码

什么是死锁我们先看看这样一个生活中的例子:在一条河上有一座桥,桥面较窄,只能容纳一辆汽车通过,无法让两辆汽车并行.如果有两辆汽车A和B分别由桥的两端驶上该桥,则对于A车来说,它走过桥面左面的一段路(即占有了桥的一部分资源),要想过桥还须等待B车让出右边的桥面,此时A车不能前进:对于B车来说,它走过桥面右边的一段路(即占有了桥的一部分资源),要想过桥还须等待A车让出左边的桥面,此时B车也不能前进.两边的车都不倒车,结果造成互相等待对方让出桥面,但是谁也不让路,就会无休止地等下去.这种现象就是死锁
Java多线程产生死锁的必要条件

线程死锁是指由于两个或者多个线程互相持有对方所需要的资源,导致这些线程处于等待状态,无法前往执行.当线程进入对象的synchronized代码块时,便占有了资源,直到它退出该代码块或者调用wait方法,才释放资源,在此期间,其他线程将不能进入该代码块.当线程互相持有对方所需要的资源时,会互相等待对方释放资源,如果线程都不主动释放所占有的资源,将产生死锁. 死锁是操作系统里里面的一个重要的概念,死锁通常发生在并发的场景里. 死锁是多个进程或线程,彼此争抢资源而陷入僵局的一种情况. 在笔者参加的多次
Java中死锁的原理实战分析

本文实例讲述了Java中死锁的原理.分享给大家供大家参考,具体如下: 一点睛当两个线程相互等待对方释放同步监视器时就会发生死锁,Java虚拟机没有监测.也没有采用措施来处理死锁情况,所以多线程编程时应该采取措施避免死锁的出现. 一旦出现死锁,整个程序既不会发生任何异常,也不会给出任何提示,只是所有线程处于阻塞状态,无法继续. 二代码 class A { public synchronized void foo( B b ) { System.out.println("当前线程名: &quo
java中常见的死锁以及解决方法代码

在java中我们常常使用加锁机制来确保线程安全,但是如果过度使用加锁,则可能导致锁顺序死锁.同样,我们使用线程池和信号量来限制对资源的使用,但是这些被限制的行为可能会导致资源死锁.java应用程序无法从死锁中恢复过来,因此设计时一定要排序那些可能导致死锁出现的条件. 1.一个最简单的死锁案例当一个线程永远地持有一个锁,并且其他线程都尝试获得这个锁时,那么它们将永远被阻塞.在线程A持有锁L并想获得锁M的同时,线程B持有锁M并尝试获得锁L,那么这两个线程将永远地等待下去.这种就是最简答的死锁形式(
Java多线程死锁示例

本文实例演示了Java多线程死锁.分享给大家供大家参考,具体如下: package com.damlab.fz; public class DeadLock { public static void main(String[] args) { Resource r1 = new Resource(); Resource r2 = new Resource(); // 每个线程都拥有r1,r2两个对象 Thread myTh1 = new MyThread1(r1, r2); Thread myT
Java 多线程死锁的产生以及如何避免死锁

一.死锁的定义多线程以及多进程改善了系统资源的利用率并提高了系统的处理能力.然而,并发执行也带来了新的问题--死锁.所谓死锁是指多个线程因竞争资源而造成的一种僵局(互相等待),若无外力作用,这些进程都将无法向前推进. 下面我们通过一些实例来说明死锁现象. 先看生活中的一个实例,2个人一起吃饭但是只有一双筷子,2人轮流吃(同时拥有2只筷子才能吃).某一个时候,一个拿了左筷子,一人拿了右筷子,2个人都同时占用一个资源,等待另一个资源,这个时候甲在等待乙吃完并释放它占有的筷子,同理,乙也在等待甲吃
详解java中产生死锁的原因及如何避免

1. Java中导致死锁的原因 Java中死锁最简单的情况是,一个线程T1持有锁L1并且申请获得锁L2,而另一个线程T2持有锁L2并且申请获得锁L1,因为默认的锁申请操作都是阻塞的,所以线程T1和T2永远被阻塞了.导致了死锁.这是最容易理解也是最简单的死锁的形式.但是实际环境中的死锁往往比这个复杂的多.可能会有多个线程形成了一个死锁的环路,比如:线程T1持有锁L1并且申请获得锁L2,而线程T2持有锁L2并且申请获得锁L3,而线程T3持有锁L3并且申请获得锁L1,这样导致了一个锁依赖的环路:T1依
Java模拟死锁发生之演绎哲学家进餐问题案例详解

本文实例讲述了Java模拟死锁发生之演绎哲学家进餐问题.分享给大家供大家参考,具体如下: 一点睛常见的死锁形式:当线程1已经占据资源R1,并持有资源R1上的锁,而且还在等待资源R2的锁:而线程2已经占据资源R2,并且持有资源R2上的锁,却正在等待资源R1上的锁.如果两个线程不释放自己占据的资源锁,而且还申请对方资源上的锁,申请不到时只能等待,而且它们只能永远的等待下去. 二实战 1 代码 public class DeadLockDemo { /** knife锁 */ private s
浅谈Java由于不当的执行顺序导致的死锁

我们来讨论一个经常存在的账户转账的问题.账户A要转账给账户B.为了保证在转账的过程中A和B不被其他的线程意外的操作,我们需要给A和B加锁,然后再进行转账操作, 我们看下转账的代码: public void transferMoneyDeadLock(Account from,Account to, int amount) throws InsufficientAmountException { synchronized (from){ synchronized (to){ transfer(fr
浅谈Python3多线程之间的执行顺序问题

一个多线程的题:定义三个线程ID分别为ABC,每个线程打印10遍自己的线程ID,按ABCABC--的顺序进行打印输出. 我的解法: from threading import Thread, Lock # 由_acquire解锁执行后释放_release锁 def _print(_id: str, _acquire: Lock, _release: Lock) -> None: for i in range(10): _acquire.acquire() print(f"id:{_id}&
浅谈@Value和@Bean的执行顺序问题

问题描述使用@Autowired处理多个同种类型的bean,出现@Value和@Bean的执行顺序问题. 首先使用扫描包+注解的方式注册User类型的不同bean,分别是user.user1,注册方式如下 package com.fanyinhang.bean; import lombok.AllArgsConstructor; import lombok.Data; import lombok.NoArgsConstructor; import org.springframework.bea
浅谈Java 类中各成分加载顺序和内存中的存放位置

一.什么时候会加载类? 使用到类中的内容时加载:有三种情况 1.创建对象:new StaticCode(); 2.使用类中的静态成员:StaticCode.num=9; StaticCode.show(); 3.在命令行中运行:java StaticCodeDemo 二.类所有内容加载顺序和内存中的存放位置利用语句进行分析: 1.Person p=new Person("zhangsan",20); 该句话所做的事情: 1.在栈内存中,开辟main函数的空间,建立main函数的变量
浅谈java 执行jar包中的main方法

浅谈java 执行jar包中的main方法通过 OneJar 或 Maven 打包后 jar 文件,用命令: java -jar ****.jar 执行后总是运行指定的主方法,如果 jar 中有多个 main 方法,那么如何运行指定的 main 方法呢? 用下面的命令试试看: java -classpath ****.jar ****.****.className [args] "****.****"表示"包名": "className"表示&
浅谈Java finally语句到底是在return之前还是之后执行(必看篇)

网上有很多人探讨Java中异常捕获机制try...catch...finally块中的finally语句是不是一定会被执行?很多人都说不是,当然他们的回答是正确的,经过我试验,至少有两种情况下finally语句是不会被执行的: (1)try语句没有被执行到,如在try语句之前就返回了,这样finally语句就不会执行,这也说明了finally语句被执行的必要而非充分条件是:相应的try语句一定被执行到. (2)在try块中有System.exit(0);这样的语句,System.exit(0);
浅谈Java文件被执行的历程

Java的编译过程 Java程序从源文件创建到程序运行要经过两大步骤 1.源文件由编译器编译成字节码(ByteCode) 2.字节码由java虚拟机解释运行.因为java程序既要编译同时也要经过JVM的解释运行,所以说Java被称为半解释语言("semi-interpreted" language). 一个例子下面我们通过一个简单的 OneTest.java,来看一下一个java文件从编译到运行的历程. Public class OneTest{ public static void
浅谈java指令重排序的问题

指令重排序是个比较复杂.觉得有些不可思议的问题,同样是先以例子开头(建议大家跑下例子,这是实实在在可以重现的,重排序的概率还是挺高的),有个感性的认识 /** * 一个简单的展示Happen-Before的例子. * 这里有两个共享变量:a和flag,初始值分别为0和false.在ThreadA中先给 a=1,然后flag=true. * 如果按照有序的话,那么在ThreadB中如果if(flag)成功的话,则应该a=1,而a=a*1之后a仍然为1,下方的if(a==0)应该永远不会为 * 真,
浅谈Java内存区域与对象创建过程

一.java内存区域 Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域.这些区域都有各自的用途,以及创建和销毁的时间,有的区域随着虚拟机进程的启动而存在,有的区域则依赖用户线程的启动和结束而建立和销毁.根据<Java虚拟机规范(JavaSE7版)>的规定,Java虚拟机所管理的内存将会包括以下几个运行时数据区域. 1.程序计数器(线程私有) 程序计数器(Program Counter Register)是一块较小的内存空间,它可以看作是当前线程所执行的字节码
浅谈java常用的几种线程池比较

1. 为什么使用线程池诸如 Web 服务器.数据库服务器.文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程来源的大量短小的任务.请求以某种方式到达服务器,这种方式可能是通过网络协议(例如 HTTP.FTP 或 POP).通过 JMS 队列或者可能通过轮询数据库.不管请求如何到达,服务器应用程序中经常出现的情况是:单个任务处理的时间很短而请求的数目却是巨大的. 构建服务器应用程序的一个简单模型是:每当一个请求到达就创建一个新线程,然后在新线程中为请求服务.实际上对于原型开发这

浅谈Java由于不当的执行顺序导致的死锁

相关推荐

随机推荐