JPA 乐观锁定与同步 Java 方法
使用JPA乐观锁定，我们可以通过@Version字段控制一个数据库表是否同时被另一个事务更新，从而允许在数据库中存储可靠的数据。
如果Java应用程序只有一个CRUD服务负责数据库中的特定实体，我们也可以同步它的方法并管理信息在数据库中的存储顺序。
所以我的问题是，这些场景之间有什么区别？是否存在任何性能优势或者甚至是可遵循的最佳实践？
共有2个答案
将同步视为悲观锁定：您必须在开始工作之前保留锁定，而不是仅在完成工作时检查是否违反了锁定（提交期间的乐观锁定）。两者的目的截然不同：
- 乐观锁只是为了保证没有不一致的数据库状态（防止在不知情的情况下覆盖数据），但它不能保证您不会得到Op的锁异常和更改数据库行的失败。出于这个原因，乐观锁的性能要好得多。
- 悲观锁定保证您永远不会写入一行失败，并且您将知道它的最新值（只要您在使用此实体的任何地方进行同步）
一般来说：不要使用同步来锁定实体，JPA中有悲观锁定支持，它锁定实际的DB行：http://docs.oracle.com/javaee/6/tutorial/doc/gkjiu.html
方法同步的缺点：
-
< li >您将序列化属于该实体类的所有实体实例的更新。两个并发线程将无法更新两个不同的实例。 < li >它在集群中不起作用。 < li >维护更加困难。如果对实体的操作变得更加复杂，从而有可能在多个服务中更新实体，或者您需要在同一个事务中更新不同的此类实体类的实例，那么您必须同步它们。 < li >第3点)增加了死锁的几率。 < li >您必须确保执行持有必要同步锁的整个事务，否则，如果您在提交事务之前释放锁，并发事务可能会获得锁并继续更改相同的数据。 < li >根据使用情况，即使线程/事务不是并发的，如果没有版本控制，您也不知道数据是否同时发生了变化(例如，您获取数据，根据数据修改客户端上的某些内容，然后其他人更改该数据，然后您保存您的修改)。
-
我在Oracle的博客上读到一篇关于JPA和锁定模式的文章。 我不完全理解和锁定模式类型之间的区别。 模式： 当用户选择这种模式时，他必须将EntityManager的状态flush（）放到数据库中，以手动增加版本字段。因此，所有其他乐观事务都将失效（回滚）。在事务结束时还会对版本进行检查，以提交或回滚事务。 这似乎很清楚，但什么时候应该使用模式与模式？我看到的唯一标准是，当我希望事务优先于其他事
-
本文向大家介绍Java并发问题之乐观锁与悲观锁，包括了Java并发问题之乐观锁与悲观锁的使用技巧和注意事项，需要的朋友参考一下 首先介绍一些乐观锁与悲观锁: 悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。再
-
我们有一个系统，我们偶尔会得到一个乐观的锁定异常。我们在代码中已经解决了这个问题，但现在我正在查看JPA 2，并看到它有一个用于处理这个问题的注释（@版本） 我们的问题是，一个表上有多个事务，如果表锁已满，则即使未对相同的记录进行更改，也会导致乐观锁定异常。 我们在JBoss 4.2服务器上使用hibernate，数据库可以是MySQL或SQL服务器。 如果改为使用@Version，这会在两个数据
-
在多用户环境中，在同一时间可能会有多个用户更新相同的记录，会产生冲突，解决方案有两种：乐观锁、悲观锁。 悲观锁在这里不讲，自行Google。 乐观锁假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性，不完整则更新失败。 乐观锁实现方式 使用整数表示数据版本号.更新时检查版本号是否一致,如果相等,则更新成功,且版本号+1.如果不等,则数据已经被修改过,更新失败。 使用时间戳来实现。 本质上也
-
我们决定在web应用程序中使用乐观锁定，以增加并发性，而不使用悲观锁定。 我们在web上看到的解决方案之一是使用带有注释的重试拦截器将方法标记为可重试。 问题是，我们希望对带有@Transactional注释的方法进行注释，但拦截器由于某种原因未能重试它们。（拦截器完全重试非事务性方法。） 所以：
-
问题内容： 我找不到有关MySQL中乐观锁定的任何详细信息。我读到开始事务使两个实体上的更新保持同步，但是，它不会停止两个用户同时更新数据而引起冲突。 显然乐观锁定会解决这个问题吗？这在MySQL中如何应用。是否有SQL语法/关键字呢？还是MySQL具有默认行为？ 谢谢你们。 问题答案： 关键是，乐观锁定不是数据库功能，不适用于MySQL或其他功能：乐观锁定是一种使用带有标准指令的DB进行的实践。