所以要是别人再问你乐观锁和悲观锁是什么，你千万别说它是一种具体的锁，它只是一种锁的设计思想，他可以有很多具体的实现类
这是一篇介绍悲观锁和乐观锁的入门文章。旨在让那些不了解悲观锁和乐观锁的小白们弄清楚什么是悲观锁，什么是乐观锁。不同于其他文章，本文会配上相应的图解让大家更容易理解。通过该文，你会学习到如下的知识。
在介绍悲观锁和乐观锁之前，让我们看一下锁。锁，在我们生活中随处可见，我们的门上有锁，我们存钱的保险柜上有锁，是用来保护我们财产安全的。程序中也有锁，当多个线程修改共享变量时，我们可以给修改操作上锁（syncronized）。当多个用户修改表中同一数据时，我们可以给该行数据上锁（行锁）。
锁（Lock）: 在介绍悲观锁和乐观锁之前，让我们看一下锁。锁，在我们生活中随处可见，我们的门上有锁，我们存钱的保险柜上有锁，是用来保护我们财产安全的。程序中也有锁，当多个线程修改共享变量时，我们可以给修改操作上锁（syncronized）。当多个用户修改表中同一数据时，我们可以给该行数据上锁（行锁）。因此，锁其实是在并发下控制多个操作的顺序执行，以此来保证数据安全的变动。 并且，锁是一种保证数据安全的机制和手段，而并不是特定于某项技术的。悲观锁和乐观锁亦是如此。
在并发访问情况下，很有可能出现不可重复读等等读现象。为了更好的应对高并发，封锁、时间戳、乐观并发控制(乐观锁)、悲观并发控制(悲观锁)都是并发控制采用的主要技术方式。
总是假设最坏的情况，每次拿数据的时候，都认为别人也会修改，所以每次都会加锁。当要对数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制，在修改数据之前先锁定，再修改的方式被称之为悲观并发控制【Pessimistic Concurrency Control，缩写“PCC”，又名“悲观锁”】。
最近，五一小长假的放假时间调整了，决定趁着假期出去玩一玩。我和女朋友商量好，我负责制定行程，她负责购买出行用品。相安无事，我正在各家比价中，不知道发生了什么，女朋友买买买竟然不高兴了。
中秋小长假快来了，决定趁着假期出去玩一玩。我和女朋友商量好，我负责制定行程，她负责购买出行用品。相安无事，我正在各家比价中，不知道发生了什么，女朋友买买买竟然不高兴了。
①、按操作划分：DML锁，DDL锁 ②、按锁的粒度划分：表级锁、行级锁、页级锁 ③、按锁级别划分：共享锁、排他锁 ④、按加锁方式划分：自动锁、显示锁 ⑤、按使用方式划分：乐观锁、悲观锁
当我们要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
乐观锁本质上并不属于锁，它只是一种冲突检测机制，但被这样称呼的时间比较长，就被称为乐观锁。乐观锁允许并发的获取内容进行读写，但在提交的时候会进行并发控制。比如 A, B 同时获得了一个数据，而且都要对其进行处理，A 先提交了该条数据，B 后来也要提交该条数据，这时候乐观锁的策略检测到两者发生了冲突，便会拒绝 B 提交的内容，并抛出冲突，交给 B 进行处理。 乐观锁的处理策略，通常是版本控制，或者是时间戳控制（本质与前者相同）。对数据进行一个版本的记录，每次提交后都标上版本号。当提交时的版本号小于等于当前版本号，则抛出异常，待解决冲突后重新执行。 笔者看到这里，就想到了一个很常见的乐观锁——即笔者项目中使用的 SVN 源代码版本控制器。我和同事一起编辑同一个 java 文件，是被允许的，但如果我们两个人提交的内容有冲突，则 SVN 会提示我们冲突，并让我们决定如何解决冲突（采用谁的内容，或者如何合并内容），然后再提交（再提交就是将冲突抛出后再解决的过程）。
悲观锁与乐观锁是两种常见的资源并发锁设计思路，也是并发编程中一个非常基础的概念。之前有写过一篇文章关于并发的处理思路和解决方案，这里我单独将对这两种常见的锁机制在数据库数据上的实现进行比较系统的介绍一次吧。
在Java并发场景中，会涉及到各种各样的锁如公平锁，乐观锁，悲观锁等等，这篇文章介绍各种锁的分类：
之前分享过一篇有关MySQL锁的文章，得到了部分阅读者的良好反馈，这里在网上搜索了几道有关锁的面试题。
记得在上大学那会开始，在大学的课堂上，常常会听到老师讲什么共享锁，排它锁各种锁的词汇，以前仅仅听过一次就没有管了，并没有进行深入的研究
在实验环境MySQL5.6、存储引擎：InnoDB中，揭开“锁”的神秘面纱，捋一捋我对这几个概念的想法
悲观锁和乐观锁是并发控制常用的两种技术手段。 并发控制是用来确保 多个事务同时读写DB中同一条数据时不破坏事务的隔离性、统一性以及数据库的统一性。
当我们想要在业务中引入“乐观锁”时，应该要思考清楚它的概念，为了更加形象的理解“乐观锁”，我们可以先看一下认识下悲观锁。
本文作者系Scott（中文名陈晓辉），现任大连华信资深分析师 ，ORACLE数据库专家，曾就职于甲骨文中国。个人主页：segmentfault.com/u/db_perf ，经其本人授权发布。
悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。 悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。 Java synchronized 就属于悲观锁的一种实现，每次线程要修改数据时都先获得锁，保证同一时刻只有一个线程能操作数据，其他线程则会被block。
乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。
悲观锁的特点是先获取锁，再进行业务操作，即“悲观”的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。通常所说的“一锁二查三更新”即指的是使用悲观锁。通常来讲在数据库上的悲观锁需要数据库本身提供支持，即通过常用的select … for update操作来实现悲观锁。当数据库执行select for update时会获取被select中的数据行的行锁，因此其他并发执行的select for update如果试图选中同一行则会发生排斥（需要等待行锁被释放），因此达到锁的效果。select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。
在电商秒杀等高并发场景中，仅仅开启事务还是无法避免数据冲突。比如用户A和用户B获取某一商品的库存并尝试对其修改，A, B查询的商品库存都为5件，结果A下单5件，B也下单5件，这就出现问题了。解决方案就是操作( 查询或修改)某个商品库存信息时对其加锁。锁有悲观锁和乐观锁。
现在有这么一个业务场景，线上通过手机app下单买祈福灯，支付成功后，线下寺庙点亮。存在多个 用户同时选择同一个灯的情况出现，如下图。此时，正常情况应为一个用户下单成功，其余显示灯已被选。由于，支付和下单是单独分开的，只要focus on下单就ok了。简而言之，就是一个并发现单的问题。
友情提示：此篇文章大约需要阅读 4分钟17秒，不足之处请多指教，感谢你的阅读。订阅本站 在关系型数据库中，悲观锁与乐观锁是解决资源并发场景的解决方案，接下来将详细讲解?一下这两个并发解决方案的实际使用
背景 考虑下面两个并发带来的问题： 1、丢失更新：一个事务的更新结果覆盖了其它事务的更新结果，即所谓的更新丢失。 2、脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。 例如： 两个用户同时修改商品库存表，A、B同时进入，看到的库存都是100，A购买一件把库存修改为99(100-1)。此时B购买两件把库存修改为98(100-2)，因为A、B同时读到的库存都是100，B并不能看到A做的库存更新，所以造成B脏读，造成A丢失更新。 所以为了解决这些并发带来的问题。 我们需要引入并发控制机制--锁。
乐观锁和悲观锁问题，是出现频率比较高的面试题。本文将由浅入深，逐步介绍它们的基本概念、实现方式(含实例)、适用场景，以及可能遇到的面试官追问，希望能够帮助你打动面试官。
行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。有可能会出现死锁的情况。 行级锁按照使用方式分为共享锁和排他锁。
如果说在 TiDB 3.0 中，悲观锁是 “千呼万唤始出来，犹抱琵琶半遮面”。那么在 TiDB 4.0 中，悲观锁在经历了市场与时光的考验后，无论是性能还是稳定性都能够 “轻拢慢撚抹复挑，初为《霓裳》后《六幺》”。TiDB 4.0 悲观锁，欢迎大家尝鲜与反馈。本文将从使用者的角度，介绍悲观锁的使用与注意事项，主要分为以下几方面：
1. update t_table set a =1; // 数据库的增删改操作默认都会加排他锁
两个用户同时修改商品库存表，A、B同时进入，看到的库存都是100，A购买一件把库存修改为99(100-1)。此时B购买两件把库存修改为98(100-2)，因为A、B同时读到的库存都是100，B并不能看到A做的库存更新，所以造成B脏读，造成A丢失更新。
介绍：悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
Java锁，指的是应用中使用的锁；应用中在处理线程安全的问题时，常常使用synchronized 或者ReentrantLock等锁来保证线程安全。
之前我们介绍了行级锁，顾名思义行级锁就只是锁住一行或多行数据，因为针对的是行去锁的，因为一个表格内会有很多行数据，要在这些数据中去锁定其中几行数据，是比较耗费资源。而表级锁则是可以锁住整个表，所以相对于行级来说没那么耗费资源，表级锁有两个模式：只读模式和只写模式，这和文件权限里的只读只写有点类似。
我们开的的各式各样系统中，系统运行需要CPU、内存、I/O、磁盘等等资源。但除了硬资源外，还有最为重要的软资源：数据。
在如今分布式、高并发、各种负载纵横天下的时代，支持高访问量成为检验一个系统合不合格的重要标准，然而我们除了在运算过程中要求系统更加效率外，在最终的数据存储过程中也希望其能够准确。
有一个资源正在被操作的时候，不希望被其它人操作，此时就需要通过加锁来防止这种情况的出现。
在进行并发操作时，我们可能会遇到资源竞争的情况，例如多个goroutine同时修改同一个数据库记录。这时，我们需要使用锁来保证数据的一致性。在Gorm中，可以使用事务锁定来实现这一目的。
在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作读某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。
首先环境是：Spring Boot 2.1.0 + data-jpa + mysql + lombok
乐观锁和悲观锁是数据库并发控制中的两个重要概念。在多用户并发访问数据库时，为了防止数据出现不一致的情况，需要采取锁机制来保证数据的一致性。下面我将分别对乐观锁和悲观锁进行详细的介绍，并比较它们的优缺点。
锁是计算机用以协调多个进程间并发访问同一共享资源的一种机制。MySQL中为了保证数据访问的一致性与有效性等功能，实现了锁机制，MySQL中的锁是在服务器层或者存储引擎层实现的。
首先，悲观锁与乐观锁是根据操作时是否锁住资源来判别的。悲观锁获取到锁时，必须要锁住资源；乐观锁则不会。一开始两线程争抢锁：
在MySQL中，锁是用于控制对数据库对象的并发访问的一种机制。锁可以防止多个事务同时对同一数据进行修改或删除，以确保数据的完整性和一致性。
MyISAM采⽤表级锁(table-level locking)。 InnoDB⽀持⾏级锁(row-level locking)和表级锁,默认为⾏级锁
最近意外发现之前对悲观锁乐观锁的理解有误，所以重新学习了一下。 1.悲观锁 悲观锁介绍（百科）： 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。 使用场景举例：以MySQL InnoDB为例 商品goods表中有一个字段status
在数据库的实际使用过程中，我们常常会遇到不希望数据被同时写或者读的情景，例如秒杀场景下，两个请求同时读到系统还有库存1个，然后又先后把库存更新为0，这时候就会出现超卖的情况，这时候货物的实际库存和我们的记录就会对应不上了。
相信很多Java开发的朋友都会被java中的各种锁所迷惑，你是不是经常听到“可重入锁”、“互斥锁”、“轻量级锁”等关键词，其实Java中的锁的分类很多，不过这种分类都是针对场景的，好多人分不清或者记不住，是因为不知道这些锁为啥是这样的分类，本文瑞哥就用简洁的语言带大家走入Java中的锁，让我们直接开始！
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
