非互斥同步锁

乐观锁

• 认为自己在处理操作的时候不会有其他线程阿里干扰，所以并不会锁住被操作对象
• 在更新的时候，去对比在我修改的期间数据有没有被其他人改变过，如果没有被改变过，就说明真的是只有我自己在操作，那我就正常去修改数据；如果数据和我一开始拿到的不一样了，说明其他人在这段时间内修改过数据，那么我就不能继续刚才的更新数据过程了，我会选择放弃、报错、重试等
• 乐观锁的实现一般都是利用CAS算法来实现的

典型例子

• 悲观锁：synchronized和Lock相关的类
• 乐观锁的典型例子就是原子类、并发容器等
• Git：Git就是乐观锁的典型例子，当我们往远程仓库push的时候，git会检查远程仓库的版本是不是领先于我们现在的版本，如果远程仓库的版本号和本地的不一样，就表示有其他人修改了远端代码，那么我们这次提交就失败，如果远端和本地的版本号一致，我们就可以顺利提交版本到远端仓库
• 数据库：select for update就是悲观锁；使用version控制数据库的数据，那么就是乐观锁

package lock.lock;import java.util.concurrent.atomic.AtomicInteger;public class PessimismOptimismLock {int a;public static void main(String[] args) {AtomicInteger atomicInteger = new AtomicInteger();atomicInteger.incrementAndGet();}public synchronized void testMethod() {a++;}}

悲观锁和乐观锁开销对比

• 悲观锁的开始开销要高于乐观锁，但是特点是一劳永逸，临界区持锁时间就算越来越差，也不会对互斥锁的开销造成影响
• 相反，虽然乐观锁一开始的开销比悲观锁小，但是如果自旋时间很长或者不停重试，那么消耗的资源也会越来越多

悲观锁和乐观锁的使用场景

• 悲观锁：适合并发写入多的情况，适用于临界区持锁时间比较长的情况，悲观锁可以避免大量的无用自旋等消耗，典型情况：
  • 临界区有I/O操作
  • 临界区代码复杂或循环量大
  • 临界区竞争非常激烈
• 乐观锁：适合并发写入少，大部分是读取的场景，不加锁能让读取性能大幅提高

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！