线程1锁定并判断A的状态后需要获得B的锁,线程2锁定并判断B的状态后需要获得A的锁,两线程同时发生,如何避免死锁?

发布于 2022-09-01 17:28:03 字数 554 浏览 28 评论 0

线程1锁定并判断A的状态后需要获得B的锁,线程2锁定并判断B的状态后需要获得A的锁,两线程同时发生,如何避免死锁?

中间的"判断状态后获得..."并不是废话,因为获得第二个锁的事件可能不会发生,也可能会发生。

比方说,账户A与账户B互为关联,若A余额不足,则从B中支取,若B余额不足则从A中支取。某一时刻,A与B同时消费,然后都发现自己余额不足,这种情况下的死锁问题如何避免?

个人想法:

① 如果不需要先判断状态(必然获得第二把锁)的话,我们可以通过账号id的大小来重新安排请求锁的顺序,以避开死锁。针对此问题,可以忽略判断条件,无论是否需要使用第二把锁,都按照顺序将两个对象锁上。这种方案是不是太粗暴了?

② 如果使用java的话,concurrent包中Lock对象有tryLock功能,但是这种方案使用的是语言特性,不知这种特性是否在各种语言中普遍存在?我期待的是一种解决思想,最好与语言无关。

我所期待的答案不限于技术,也包括设计,你甚至可以说服我放弃这种功能。

期待您的想法!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

哎呦我呸! 2022-09-08 17:28:03

锁的是数据还是线程这个问题你要先搞清楚,锁的是数据的话并不会因为上述问题导致死锁。账户在尝试扣钱的时候已经锁住各自的资源,在请求对方账户的时候因为资源已经锁住,请求直接失败,线程就直接做失败处理,不会去等待资源释放再做后续处理。如果你锁的是线程的话,那你需要一个全局的锁管理器来处理那个线程得要排队等待的问题

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文