通常，当您查看乐观锁定时，您还会使用像Hibernate这样的库或其他具有@Version支持的JPA实现。

示例可以如下所示：

public class Person {
    private String firstName;
    private String lastName;
    private int age;
    private Color favoriteColor;
    @Version
    private Long version;
}

虽然显然，如果您没有使用支持此功能的框架，则添加注释是没有意义的。@Version

然后，DDL 可以是

CREATE TABLE people (
    person_id PRIMARY KEY AUTO_INCREMENT,
    first_name VARCHAR(100) NOT NULL,
    last_name VARCHAR(100) NOT NULL,        # } I realize these column defs are not valid but this is just pseudo-code
    age INT NOT NULL,
    color_id FOREIGN KEY (colors) NOT NULL,  # Say we also have a colors table and people has a 1:1 relationship with it
    version BIGINT NOT NULL
);

该版本会发生什么情况？

1. 每次在存储实体之前，您都会检查存储在数据库中的版本是否仍然是您知道的版本。
2. 如果是，则以 1 递增的版本存储数据

为了完成这两个步骤，而不会冒着其他进程在两个步骤之间更改数据的风险，通常通过如下语句进行处理：

UPDATE Person SET lastName = 'married', version=2 WHERE person_id = 42 AND version = 1;

执行语句后，检查是否更新了行。如果您这样做了，则由于您已读取数据，因此没有其他人更改数据，否则其他人会更改数据。如果其他人更改了数据，您通常会通过您正在使用的库收到 OptimisticLockException。

此异常应导致所有更改被撤销，并且更改值的过程将重新启动，因为要更新实体的条件可能不再适用。

所以没有碰撞：

1. 进程 A 读取人员
2. 进程 A 写入人员从而增加版本
3. 进程 B 读取人员
4. 进程 B 写入人员从而增加版本

碰撞：

1. 进程 A 读取人员
2. 进程 B 读取人员
3. 进程 A 写入人员从而增加版本
4. 进程 B 在尝试保存为自读取人员以来更改的版本时收到异常

如果Color是另一个对象，你应该按照相同的方案在那里放一个版本。

什么是乐观锁定？

• 乐观锁定不是合并冲突更改的魔法。乐观锁定只会防止进程意外地被另一个进程覆盖更改。
• 乐观锁定实际上不是真正的DB锁定。它仅通过比较版本列的值来工作。您不会阻止其他进程访问任何数据，因此期望您获得OptimisticLockException

要将什么列类型用作版本？

如果许多不同的应用程序访问您的数据，则最好使用数据库自动更新的列。例如，对于MySQL

version TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

这样，实现乐观锁定的应用程序将注意到哑应用程序的变化。

如果更新实体的频率高于实体的解析或 Java 解释，则此方法可能无法检测到某些更改。此外，如果您让Java生成新的，则需要确保运行应用程序的所有机器都处于完美的时间同步状态。TIMESTAMPTIMESTAMP

如果您的所有应用程序都可以更改整数，长整型，...版本通常是一个很好的解决方案，因为它永远不会遭受不同设置的时钟的影响;-）

还有其他方案。例如，您可以使用哈希值，甚至可以在每次更改行时随机生成一个。重要的是，当任何进程保存数据以进行本地处理或在缓存中时，您都不要重复值，因为该进程将无法通过查看版本列来检测更改。String

作为最后的手段，您可以使用所有字段的值作为版本。虽然在大多数情况下，这将是最昂贵的方法，但它是在不更改表结构的情况下获得类似结果的一种方法。如果使用 Hibernate，则有@OptimisticLocking注释来强制实施此行为。在实体类上使用，以便在任何行自您读取实体后发生更改时失败，或者当另一个进程也更改了您更改的字段时失败。@OptimisticLocking(type = OptimisticLockType.ALL)@OptimisticLocking(type = OptimisticLockType.DIRTY)

@TheConstructor：很好地解释了它是什么和不是什么。当你说“乐观锁定不是合并冲突变化的魔法”时，我想发表评论。我曾经管理过一个DataFlex应用程序，该应用程序允许用户编辑表单上的记录。当他们按下“保存”按钮时，该应用程序将执行所谓的“多用户重新读取”数据 - 提取当前值 - 并与用户修改的内容进行比较。如果用户修改的字段在此期间未被更改，则只有这些字段将被写回记录（仅在重新读取+ 写入操作期间被锁定），因此，2个用户可以透明地修改同一记录上的不同字段而不会出现问题。它不需要版本戳，只需要了解修改了哪些字段。

当然，这不是一个完美的解决方案，但它在这种情况下完成了工作。它是乐观的，它确实允许不相关的更改，并且它给用户一个关于冲突更改的错误。这是在SQL之前可以做到的最好的，但今天仍然是一个很好的设计原则，也许对于更多与对象或Web相关的场景。