Java synchronized关键字和Spring @Transactional注释的逻辑比较
发布时间：2020-12-15 08:41:30 所属栏目：Java 来源：网络整理
导读：在关于 Spring / Hibernate事务的演示之一中,我提出了一个意见,即在方法上同步关键字,而@Transactional在逻辑上有许多相似之处.果然它们是完全不同的野兽,但它们都作为方法应用于方法,并且都通过某种共享监视器控制对某些资源的访问(例如,在db中记录). 人群
|
在关于
Spring / Hibernate事务的演示之一中,我提出了一个意见,即在方法上同步关键字,而@Transactional在逻辑上有许多相似之处.果然它们是完全不同的野兽,但它们都作为方法应用于方法,并且都通过某种共享监视器控制对某些资源的访问(例如,在db中记录).
人群中有几个人立即反对并声称我的比较是错误的.我不记得具体的论点,但我也可以在这里看到一些观点.例如,从开头和事务开始,整个方法的同步工作只有在达到访问DB的语句时才会生效. Plus synchronized不提供任何读/写锁定模式. 所以问题是,我的比较是完全错误的,我永远不应该使用它,或者,如果用适当的措辞,将它呈现给经验丰富的工程师是否有意义,他们知道同步的工作原理但是却试图了解AOP交易？这个措辞应该是什么？ 一点更新. 显然我的问题听起来像比较数据库事务与在Java中输入synchronized方法.事实并非如此.我的想法更多的是比较@Transactional和synchronized的语义相似性. 我提出它的原因之一也是为了说明传播行为.例如,如果@Transactional是PROPAGATION_REQUIRED,它将与输入synchronized块有许多相似之处.对于交易：如果交易存在,我们只是继续使用它,如果没有,我们将创建一个.对于同步,如果我们已经有监视器,我们继续它,如果不是,我们将尝试获取它.当然对于@Transactional我们不会锁定方法边界. 解决方法
如果我们将@Transactional视为表示锁定数据库资源的方法(因为它在事务中使用) – 那么比较就有了一些意义.
然而,这就是他们的共同点. synchronized是在对象监视器上定义的(并且仅保护它),这在使用关键字时是已知的,而事务可以锁定多个资源(在事务开始时不知道),或者可能不锁定任何资源根本(乐观锁定,只读事务). 所以最终 – 不要使用这种比较,它们有很多不同之处,而不是共同点. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |