“乐观锁”是咱们程序员在面试的过程中经常会碰到的，那么这里我们来聊一下它的重要性。
所以要是别人再问你乐观锁和悲观锁是什么，你千万别说它是一种具体的锁，它只是一种锁的设计思想，他可以有很多具体的实现类
首先，悲观锁与乐观锁是根据操作时是否锁住资源来判别的。悲观锁获取到锁时，必须要锁住资源；乐观锁则不会。一开始两线程争抢锁：
乐观锁和悲观锁是数据库并发控制中的两个重要概念。在多用户并发访问数据库时，为了防止数据出现不一致的情况，需要采取锁机制来保证数据的一致性。下面我将分别对乐观锁和悲观锁进行详细的介绍，并比较它们的优缺点。
这是一篇介绍悲观锁和乐观锁的入门文章。旨在让那些不了解悲观锁和乐观锁的小白们弄清楚什么是悲观锁，什么是乐观锁。不同于其他文章，本文会配上相应的图解让大家更容易理解。通过该文，你会学习到如下的知识。
在介绍悲观锁和乐观锁之前，让我们看一下锁。锁，在我们生活中随处可见，我们的门上有锁，我们存钱的保险柜上有锁，是用来保护我们财产安全的。程序中也有锁，当多个线程修改共享变量时，我们可以给修改操作上锁（syncronized）。当多个用户修改表中同一数据时，我们可以给该行数据上锁（行锁）。
乐观锁本质上并不属于锁，它只是一种冲突检测机制，但被这样称呼的时间比较长，就被称为乐观锁。乐观锁允许并发的获取内容进行读写，但在提交的时候会进行并发控制。比如 A, B 同时获得了一个数据，而且都要对其进行处理，A 先提交了该条数据，B 后来也要提交该条数据，这时候乐观锁的策略检测到两者发生了冲突，便会拒绝 B 提交的内容，并抛出冲突，交给 B 进行处理。 乐观锁的处理策略，通常是版本控制，或者是时间戳控制（本质与前者相同）。对数据进行一个版本的记录，每次提交后都标上版本号。当提交时的版本号小于等于当前版本号，则抛出异常，待解决冲突后重新执行。 笔者看到这里，就想到了一个很常见的乐观锁——即笔者项目中使用的 SVN 源代码版本控制器。我和同事一起编辑同一个 java 文件，是被允许的，但如果我们两个人提交的内容有冲突，则 SVN 会提示我们冲突，并让我们决定如何解决冲突（采用谁的内容，或者如何合并内容），然后再提交（再提交就是将冲突抛出后再解决的过程）。
锁（Lock）: 在介绍悲观锁和乐观锁之前，让我们看一下锁。锁，在我们生活中随处可见，我们的门上有锁，我们存钱的保险柜上有锁，是用来保护我们财产安全的。程序中也有锁，当多个线程修改共享变量时，我们可以给修改操作上锁（syncronized）。当多个用户修改表中同一数据时，我们可以给该行数据上锁（行锁）。因此，锁其实是在并发下控制多个操作的顺序执行，以此来保证数据安全的变动。 并且，锁是一种保证数据安全的机制和手段，而并不是特定于某项技术的。悲观锁和乐观锁亦是如此。
当我们想要在业务中引入“乐观锁”时，应该要思考清楚它的概念，为了更加形象的理解“乐观锁”，我们可以先看一下认识下悲观锁。
相信很多Java开发的朋友都会被java中的各种锁所迷惑，你是不是经常听到“可重入锁”、“互斥锁”、“轻量级锁”等关键词，其实Java中的锁的分类很多，不过这种分类都是针对场景的，好多人分不清或者记不住，是因为不知道这些锁为啥是这样的分类，本文瑞哥就用简洁的语言带大家走入Java中的锁，让我们直接开始！
比如我在数据库里要修改一个id=1,并且version=1的一条数据，乐观锁会先去查询id=1的version是否等于1，如果等于就修改，如果不等于就不修改
具有排它性（我锁住当前数据后，比人看不到此数据），悲观锁一般是由数据库机制来做到的。
在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。
在Java并发场景中，会涉及到各种各样的锁如公平锁，乐观锁，悲观锁等等，这篇文章介绍各种锁的分类：
在当今的软件开发领域，数据库操作是不可或缺的一部分。然而，随着并发操作的增加，如何正确地处理并发问题是每个开发者都需要面对的挑战。本文将深入探讨JPA（Java Persistence API）和Hibernate这两种ORM（对象关系映射）工具中的乐观锁和悲观锁的使用及其适用场景。
ES的并发控制是一种机制，用于处理多个同时对同一份数据进行读写操作的情况，以确保数据的一致性和正确性。
最近，五一小长假的放假时间调整了，决定趁着假期出去玩一玩。我和女朋友商量好，我负责制定行程，她负责购买出行用品。相安无事，我正在各家比价中，不知道发生了什么，女朋友买买买竟然不高兴了。
中秋小长假快来了，决定趁着假期出去玩一玩。我和女朋友商量好，我负责制定行程，她负责购买出行用品。相安无事，我正在各家比价中，不知道发生了什么，女朋友买买买竟然不高兴了。
有博客提到，乐观锁比悲观锁快的场景在于读多写少，但是在没有竞争的情况下，乐观锁的UPDATE和悲观锁的UPDATE都需要获取锁、释放锁，为什么乐观锁更快呢？ 笔者猜测，这里的"写"当然指的是上文中的"UPDATE"操作，但读指的是"SELECT ... FOR UPDATE"而不是"SELECT ..."操作。因为如果是前者，是要与写操作竞争锁的，那么由于乐观锁只在更新时才尝试获取锁，在上文的(1)阶段中，其它读操作就能顺利获得锁后完成；而由于悲观锁在一开始就获取锁，其它读操作容易跟着阻塞在锁的获取内。
AtomicInteger是基于CAS实现的一个线程安全的整型类，Unsafe调用CPU底层指令实现原子操作
在平常开发中，我们经常会用到多线程的开发，在使用多线程的时候，我们就需要注意线程安全的问题，特别是重要的操作共享变量时，线程安全的问题又是重中之重。我们今天就来了解一下锁中的乐观锁和悲观锁。 在面试中，如果是Java后天研发的工程师，很有可能会考到这一个知识点。所以今天也就来说下这个。 两者的概念 乐观锁 根据表面上来看每次去拿数据的时候认为别人都不会修改。所以不会上锁，有着更宽松的锁机制，减少了性能的开销。 在更新的时候会根据版本号进行判断是否有程序去修改这个数据，例如版本号等机制，使用版本号的机制在进行
乐观锁是一种假设资源不会被冲突影响的并发控制策略。它假设多个事务在同一时间内不会发生冲突，因此不需要加锁。当事务提交时，如果检测到数据发生了改变，就会抛出异常，让开发者决定如何处理这个冲突。
乐观锁（ Optimistic Lock ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
页锁就是在 页的粒度 上进行锁定，锁定的数据资源比行锁要多，因为一个页中可以有多个行记录。当我 们使用页锁的时候，会出现数据浪费的现象，但这样的浪费最多也就是一个页上的数据行。页锁的开销 介于表锁和行锁之间，会出现死锁。锁定粒度介于表锁和行锁之间，并发度一般。
当我们要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。
参考：https://tech.meituan.com/2018/11/15/java-lock.html
Java锁，指的是应用中使用的锁；应用中在处理线程安全的问题时，常常使用synchronized 或者ReentrantLock等锁来保证线程安全。
首先我们理解下两种不同思路的锁，乐观锁和悲观锁。 这两种锁机制，是在多用户环境并发控制的两种所机制。下面看百度百科对乐观锁和悲观锁两种锁机制的定义：
悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
在MySQL中，悲观锁依赖数据库提供的锁机制来实现。在InnoDB引擎中，使用悲观锁需要先关闭MySQL数据库的自动提交属性，然后通过select ... for update来进行加锁。
举个场景：多线程、多进程应用在对数据库的同一数据进行非幂等操作时，如果没有添加相应的锁机制进行校验、判断，通常会导致数据的脏写。抛开分布式锁这种解决思路，简单的来讲，可以优先考虑从数据库层面去解决这个问题。
在并发访问情况下，很有可能出现不可重复读等等读现象。为了更好的应对高并发，封锁、时间戳、乐观并发控制(乐观锁)、悲观并发控制(悲观锁)都是并发控制采用的主要技术方式。
在并发编程中，读写锁 ReentrantReadWriteLock 的性能已经算是比较高的了，因为它将悲观锁的粒度分的更细，在它里面有读锁和写锁，当所有操作为读操作时，并发线程是可以共享读锁同时运行的，这样就无需排队执行了，所以执行效率也就更高。
乐观锁和悲观锁是两种思想，用于解决并发场景下的数据竞争问题。它们的使用是非常广泛的，不局限于某种编程语言或数据库。乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。
在一些时候我们需要对redis中的多个数据进行复制或者删除等操作，但是这些命令不是一起执行的，他们都是单独的一个命令。所以redis提供了一些命令让多个操作一起执行，并不被中断。这些命令有：watch、multi、exec、unwatch和discard。
乐观锁和悲观锁并不是一种真实存在的锁，而是一种设计思想，乐观锁和悲观锁对于理解后端多线程和数据库来说至关重要，那么本篇文章就来详细探讨一下这两种锁的概念以及实现方式。
绍了关于ES嵌套索引的增删改，本篇就接着上篇主题继续深入聊一下，上篇的添加和更新操作，其实是不安全的，所有的数据库db系统都会存在并发问题像关系型数据库MySQL，Oracle，SQL Server默认采用的是悲观锁。 在ElasticSearch中采用的乐观锁，下面先熟悉下什么是乐观锁和悲观锁： 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到
前面我们讨论了《如何基于幂等表实现幂等处理》，本文我们就来看看如何基于乐观锁、悲观锁来做幂等处理。
线程拿到了最初的预期值A，然而在将要进行CAS的时候，被其他线程抢占了执行权，把此值从A变成了B
乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。
悲观锁和乐观锁是并发控制常用的两种技术手段。 并发控制是用来确保 多个事务同时读写DB中同一条数据时不破坏事务的隔离性、统一性以及数据库的统一性。
如果你觉得文字太长，可以直接先看文末思维导图总结，小编已为你整理了作者的主要观点，供你回顾与快速阅读~
读了第15章，大致感觉到了CAS的乐观锁特性。“锁”这个词太有意思了，你能体会到几个意思？
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。在Java中，synchronized从偏向锁、轻量级锁到重量级锁，全是悲观锁。JDK提供的Lock实现类全是悲观锁； 手动加悲观锁 读锁：LOCK tables test_db read，释放锁：UNLOCK TABLES; 写锁：LOCK tables test_db WRITE，释放锁：UNLOCK TABLES; 读锁与写锁 如果要更新数据，那么加锁的时候就直接加写锁，一个线程持有写锁的时候别的线程无论读还是写都需要等待； 如果是读取数据仅为了前端展示，那么加锁时就明确地加一个读锁，其他线程如果也要加读锁，不需要等待，可以直接获取（读锁计数器+1）； 虽然读写锁感觉与乐观锁有点像，但是读写锁是悲观锁策略。因为读写锁并没有在更新前判断值有没有被修改过，而是在加锁前决定应该用读锁还是写锁； ●优点：可以完全保证数据的独占性和正确性，因为每次请求都会先对数据进行加锁， 然后进行数据操作，最后再解锁，而加锁释放锁的过程会造成消耗，所以性能不高; ●缺点：因为每次请求都会先对数据进行加锁， 然后进行数据操作，最后再解锁，而加锁释放锁的过程会造成消耗，所以性能不高;
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
