你们会用乐观锁来防止并发冲突吗

[ljzxloaf]

并发冲突似乎是个大家都在谈，但是很少有人真的去当回事的东西。

典型的如 innodb 的 mvcc 就是用乐观锁的方式去处理并发冲突，你可以通过设置不同的隔离级别让 innodb 在检测到并发修改的时候选择不同的处理方式。

在业务开发中，当用户并发修改某条数据的时候，我们也可以通过类似的方式去防止或协调冲突。
那么问题来了，在实际工作你们真的去这么做了吗？如果没有这样实践的话是啥原因呢？就我个人的经验而言，好像很少有人真的这么干。

[mshadow]

18 楼说的是主要场景。其他高并发场景一般用分布式锁。

[Huelse]

postgresql 中我们就用乐观锁，因为 mvcc 的关系

[hekkowoerld]

@helloluckydamon 大佬有对比过吗？性能大概有多大的提升？其实说白了乐观锁和悲观锁主要就是性能差异。

[ZeawinL]

看数据重要程度

[laminux29]

1.锁性能的关键在于 CPU 、主板、内存 的主频下限，这是个木桶效应问题。

2.业务量小的系统，不需要考虑这个问题，直接用数据库的序列化事务，来处理这类数据。

3.业务量大的系统，不靠数据库来处理，而是在系统的设计阶段，就会根据第一条的机器性能，把业务进行拆分，拆分到不同的业务集群里。举个例子，用户注册的用户名唯一性查询，会按照首字母 + 数据量，进行物理数据库服务器拆分，并且这类物理数据库服务器，会选用高频设备：高频 CPU + 高频主板 + 高频内存。

[RightHand]

哎，干了这么多年还没用过乐观锁。另外乐观锁这词又是哪里来的？

[duhbbx1119]

之前用的比较多的是版本控制，数据库中加个字段记录版本，update 的时候比较下

[byehair]

@hekkowoerld 并没有实际对比过，没有实际对比主要是两点原因：
1. 懒
2. 乐观锁和悲观锁的性能差异在不同条件下是不一样的，要看自旋的成本和调度的成本

假设你获取到锁的线程执行任务周期长，或者锁竞争很激烈，那么也许悲观锁性能更高
反之亦然