扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这篇文章主要讲解了“java中如何用一把锁保护多个资源”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“java中如何用一把锁保护多个资源”吧!
创新互联建站从2013年创立,是专业互联网技术服务公司,拥有项目成都网站制作、成都做网站网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元乌恰做网站,已为上家服务,为乌恰各地企业和个人服务,联系电话:13518219792
如果多个资源没有关系,那就是保护一个资源模型的复制,同样非常简单,且看下图:
比如现实中银行取款和修改密码操作。 银行取款操作对应的资源是「余额」, 修改密码操作对应的资源是「密码」,余额和密码两个资源完全没有关系,所以各自用自家的锁保护自家的资源就好了
如果多个资源没有关系,程序猿的世界该有多美好,可惜并不是,我们保护的资源多数情况都有关联关系
拿经典的银行转账案例来说明,账户 A 给账户 B 转账,账户 A 余额减少 100 元,账户 B 余额增加 100 元,这个操作要是原子性的,那么资源「A 余额」和资源「B 余额」就这样"有了关系",先来看程序:
class Account { private int balance; // 转账 synchronized void transfer( Account target, int amt){ if (this.balance > amt) { this.balance -= amt; target.balance += amt; } } }
用 synchronized 直接保护 transfer 方法,然后操作资源「A 余额」和资源「B 余额」就可以了
⚠️: 真的是这样吗?
先停止向下看,在你的笔记本上按照文章开头的三步走来画个图看一看,是否和下图一样呢?
我们通常容易忽略锁和资源的指向关系,我们想当然的用锁 this 来保护 target 资源了,也就没有起到保护作用
假设 A,B,C 账户初始余额都是 200 原,A 向 B 转账 100,B 向 C 转账 100
我们期盼最终的结果是:账户 A 余额: 100 元 账户 B 余额: 200 元 账户 C 余额: 300 元
假线程 1「A 向 B 转账」与线程 2「B 向 C 转账」两个操作同时执行,根据 JMM 模型可知,线程 1 和线程 2 读取线程 B 当前的余额都是 200 元:
线程 1 执行 transfer 方法锁定的是 A 的实例(A.this),并没有锁定 B 的实例
线程 2 执行 transfer 方法锁定的是 B 的实例(B.this),并没有锁定 C 的实例
所以线程 1 和线程 2 可以同时进入 transfer 临界区,上面你认为对的模型其实就会变成这个样子:
还记得 happens-before 规则 这篇文章提到的监视器锁规则和传递性规则吗?
####监视器锁规则 对一个锁的解锁 happens-before 于随后对这个锁的加锁 ####传递性规则 如果 A happens-before B, 且 B happens-before C, 那么 A happens-before C
资源 B.balance 存在于两个"临界区"中,所以这个"临界区"对 B.balance 来说形同虚设,也就不满足监视器锁规则,进而导致传递性规则也不生效,说白了,前序线程的更改结果对后一个线程不可见
这样最终导致:
**账户 B 的余额可能是 100: ** 线程 1 写 B.balance 100(balance = 300) 先于线程 2 写 B.balance(balance = 100),也就是说线程 1 的结果会被线程 2 覆盖,导致最终账户 B 的余额为 100
账户 B 的余额可能是 300:与上述情况相反,线程 1 写 B.balance 100(balance = 300) 后于线程 2 写 B.balance(balance = 100),也就是说线程 2 的结果线程 1 覆盖,导致最终账户 B 的余额为 300
就是不能得到我们理想结果 200,感觉生活无比的艰难,那怎么办呢?
上面的问题就是为资源创建的锁不能保护所有关联的资源,那我们就想办法解决这个问题,来看下面代码:
class Account { private int balance; // 转账 void transfer(Account target, int amt){ synchronized(Account.class) { if (this.balance > amt) { this.balance -= amt; target.balance += amt; } } } }
我们将 this 锁变为 Account.class 锁,Account.class 是虚拟机加载 Account 类时创建的,肯定是唯一的(双亲委派模型解释了为何该对象是唯一的), 所有 Account 对象都共享 Account.class, 也就是说,Account.class 锁能保护所有 Account 对象,我们将上面程序再用模型解释一下
感谢各位的阅读,以上就是“java中如何用一把锁保护多个资源”的内容了,经过本文的学习后,相信大家对java中如何用一把锁保护多个资源这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流