在一次关于 Spring/Hibernate 事务的演讲中，我提出了一种观点，即方法上的 synchronized 关键字和 @Transactional 在逻辑上有很多相似之处。果然，它们是完全不同的野兽，但它们都作为方法的方面应用，并且都通过某种共享监视器(例如，记录在数据库中)控制对某些资源的访问。
人群中有几个人立即反对并声称我的比较是致命的错误。我不记得具体的论点，但我也可以在这里看到一些观点。例如，synchronized 从一开始就对整个方法起作用，事务只有在到达访问 DB 的语句时才会生效。另外，synchronized 不提供任何读/写锁定模式。
所以问题是，我的比较是否完全错误，我永远不应该使用它，或者，用适当的措辞，将它呈现给熟悉 synchronized 工作原理的有经验的工程师是否有意义但还想了解 AOP 事务？这个写法应该是什么？
一些更新。
显然，我的问题听起来像是比较数据库事务与在 Java 中输入 synchronized 方法。事实并非如此。我的想法更多的是比较 @Transactional 和 synchronized 语义上的相似性。
我提出它的原因之一也是为了说明传播行为。例如，如果 @Transactional 是 PROPAGATION_REQUIRED 它将与进入 synchronized block 有很多相似之处。对于交易:如果交易存在，我们就继续使用它，如果没有，我们将创建一个。对于 synchronized，如果我们已经有监视器，我们将继续使用它，如果没有，我们将尝试获取它。当然，对于 @Transactional，我们不会锁定方法边界。
最佳答案
如果我们将 @Transactional 视为表示锁定数据库资源的方法(因为它在事务中使用)——那么比较就有意义了。
但这就是他们的共同点。 synchronized 是在对象监视器上定义的(并且只保护它)，它在使用关键字时是已知的，而事务可能锁定多个资源(事务开始时不知道)，或者可能不锁定任何资源完全没有(乐观锁定，只读事务)。
所以最终 - 不要使用这种比较，它们的不同之处比它们的共同点要多得多。
关于java - Java synchronized关键字与Spring @Transactional注解的逻辑对比，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6479283/