Check to verify that the optimistic lock can be set, that is, there is no external exclusive lock.
当同一条记录有其他的 exclusive lock 时，无法再上 O 锁。
The lock does not protect against external changes to data, but it does help to identify them.
O 锁不能保证当前访问的数据被其他进程或者用户修改，但能够有助于检测出这种 external change 的情况。
O 锁的升级情况：
-
检查读取数据和乐观锁的一致性。
-
检查并验证乐观锁到排他锁的转换，不会与现有锁发生冲突。
-
将当前外部持有的所有乐观锁设置为无效(即所谓的 invalidation 操作)，将此更改传播到乐观锁的外部所有者。
-
当前的乐观锁转换为排它锁。
-
修改当前数据，此后这修改对所有人可见。
-
锁被释放。
其中上述步骤1～4必须是原子操作。
可能出现的锁冲突场景
- 如果资源已经被用户 A 加上了 E 锁，则其他用户对同一资源试图加 O 锁的请求会失败。
结果是，其他用户无法切换到 Change 模式。
- 用户 A 已经成功加上了 O 锁，即切换到了 change mode，但是当用户 A 试图保存修改的数据时，另一个用户持有的 O 锁已经提前升级成了 E 锁。
In conflicts, an optimistic lock (lock mode O) behaves like a shared lock (type S hared), which means it conflicts with type E or type X locks.
当冲突发生时，O 锁的行为和共享锁一致。
如果存在属于其他所有者的 E 锁，则无法设置乐观锁。 至于这个 E 锁是其他用户直接分配的，还是通过传统的O 锁升级而成的，并不重要。
现有的乐观锁还可以防止其他所有者直接上 E 或 X 锁。
下图显示了无法设置乐观锁的情况，因为对象上已经设置了排他锁。
属于不同所有者的乐观锁彼此兼容。 第一个尝试将乐观锁转换为排他锁的所有者可以成功完成此操作（前提是未设置其他普通共享锁）。 其他乐观锁变得无效（从锁表中删除）。 果您尝试更改它们，则无法设置排他锁。
下图是一个例子：
事务 1 将乐观锁转换为 E 锁。 这使得事务2（锁定同一个对象）的O锁无效。 这意味着事务2无法转换O锁，冲突必须由程序员解决。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/24475491/viewspace-2977056/ ，如需转载，请注明出处，否则将追究法律责任。
