悲观锁

悲观锁和乐观锁定义

悲观锁和乐观锁的定义分别如下：1.悲观锁：顾名思义，就是比较悲观的锁，总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁特点：可以完全保证数据的独占性和正确性，因为每次请求都会先对数据进行加锁， 然后进行数据操作，最后再解锁，而加锁释放锁的过程会造成消耗，所以性能不高;手动加悲观锁：读锁LOCK tables test_db read释放锁UNLOCK TABLES;写锁：LOCK tables test_db WRITE释放锁UNLOCK TABLES;2.乐观锁：反之，总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。特点：乐观锁是一种并发类型的锁，其本身不对数据进行加锁通而是通过业务实现锁的功能，不对数据进行加锁就意味着允许多个请求同时访问数据，同时也省掉了对数据加锁和解锁的过程，这种方式因为节省了悲观锁加锁的操作，所以可以一定程度的的提高操作的性能

[create_time]2022-11-07 19:51:07[/create_time]2022-11-17 14:14:47[finished_time]1[reply_count]0[alue_good]南有乔木yxl[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.4ba573b7.zOJpjpVDpHq-AMjVDwKfsQ.jpg?time=7294&tieba_portrait_time=7294[avatar]超过43用户采纳过TA的回答[slogan]这个人很懒，什么都没留下![intro]185[view_count]

悲观锁 和 乐观锁 区别

乐观锁和悲观锁的区别如下：1、悲观锁是当线程拿到资源时，就对资源上锁，并在提交后，才释放锁资源，其他线程才能使用资源。2、乐观锁是当线程拿到资源时，上乐观锁，在提交之前，其他的锁也可以操作这个资源，当有冲突的时候，并发机制会保留前一个提交，打回后一个提交，让后一个线程重新获取资源后，再操作，然后提交。和git上传代码一样，两个线程都不是直接获取资源本身，而是先获取资源的两个copy版本，然后在这两个copy版本上修改。3、悲观锁和乐观锁在并发量低的时候，性能差不多，但是在并发量高的时候，乐观锁的性能远远优于悲观锁。4、常用的synchronized是悲观锁，lock是乐观锁。

[create_time]2022-11-15 00:11:01[/create_time]2015-10-04 18:12:20[finished_time]4[reply_count]0[alue_good]乾莱信息咨询[uname]https://pic.rmb.bdstatic.com/bjh/user/62ac8245037c35cef5dd05b07789a9ca.jpeg[avatar]百度认证:内蒙古乾莱科技官方账号[slogan]这个人很懒，什么都没留下![intro]1362[view_count]

悲观锁和乐观锁定义是什么？

悲观锁和乐观锁定义：乐观锁：乐观锁在操作数据时非常乐观，认为别人不会同时修改数据。因此乐观锁不会上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：如果别人修改了数据则放弃操作，否则执行操作。悲观锁：悲观锁在操作数据时比较悲观，认为别人会同时修改数据。因此操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据。悲观锁实现方式悲观锁的实现，往往依靠数据库提供的锁机制。在数据库中，悲观锁的流程如下：1.在对记录进行修改之前，先尝试为该记录加上排它锁(exclusive locking)。2.如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。3.如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。4.期间如果有其他对该记录做修改或加排它锁的操作，都会等待解锁或直接抛出异常。

[create_time]2022-03-23 13:01:39[/create_time]2022-04-01 16:36:10[finished_time]1[reply_count]0[alue_good]鹰志说生活[uname]https://pic.rmb.bdstatic.com/bjh/user/5925626c11487b92bdaa0bc20acf2d00.jpeg[avatar]专注于分享生活经验，科普生活小常识[slogan]专注于分享生活经验，科普生活小常识[intro]204[view_count]

乐观锁和悲观锁的区别

乐观锁和悲观锁的区别如下：1、悲观锁是当线程拿到资源时，就对资源上锁，并在提交后，才释放锁资源，其他线程才能使用资源。2、乐观锁是当线程拿到资源时，上乐观锁，在提交之前，其他的锁也可以操作这个资源，当有冲突的时候，并发机制会保留前一个提交，打回后一个提交，让后一个线程重新获取资源后，再操作，然后提交。和git上传代码一样，两个线程都不是直接获取资源本身，而是先获取资源的两个copy版本，然后在这两个copy版本上修改。3、悲观锁和乐观锁在并发量低的时候，性能差不多，但是在并发量高的时候，乐观锁的性能远远优于悲观锁。4、常用的synchronized是悲观锁，lock是乐观锁。

[create_time]2022-09-21 15:25:52[/create_time]2022-10-06 15:25:52[finished_time]1[reply_count]0[alue_good]乾莱信息咨询[uname]https://pic.rmb.bdstatic.com/bjh/user/62ac8245037c35cef5dd05b07789a9ca.jpeg[avatar]百度认证:内蒙古乾莱科技官方账号[slogan]这个人很懒，什么都没留下![intro]1[view_count]

悲观锁和乐观锁，什么情况

乐观锁和悲观锁的区别如下：1、悲观锁是当线程拿到资源时，就对资源上锁，并在提交后，才释放锁资源，其他线程才能使用资源。2、乐观锁是当线程拿到资源时，上乐观锁，在提交之前，其他的锁也可以操作这个资源，当有冲突的时候，并发机制会保留前一个提交，打回后一个提交，让后一个线程重新获取资源后，再操作，然后提交。和git上传代码一样，两个线程都不是直接获取资源本身，而是先获取资源的两个copy版本，然后在这两个copy版本上修改。3、悲观锁和乐观锁在并发量低的时候，性能差不多，但是在并发量高的时候，乐观锁的性能远远优于悲观锁。4、常用的synchronized是悲观锁，lock是乐观锁。

[create_time]2022-11-15 00:11:05[/create_time]2012-12-06 19:21:56[finished_time]3[reply_count]0[alue_good]乾莱信息咨询[uname]https://pic.rmb.bdstatic.com/bjh/user/62ac8245037c35cef5dd05b07789a9ca.jpeg[avatar]百度认证:内蒙古乾莱科技官方账号[slogan]这个人很懒，什么都没留下![intro]2043[view_count]

JAVA 悲观锁 乐观锁 区别 （认真者采纳）

悲观锁(Pessimistic
Lock),
顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
乐观锁(Optimistic
Lock),
顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

[create_time]2019-05-07 07:54:21[/create_time]2019-03-18 07:10:05[finished_time]1[reply_count]4[alue_good]惠淑懿斯祯[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.98af9866.7jmK0ci1J9SMXCU1Y4Ri4A.jpg?time=10584&tieba_portrait_time=10584[avatar]TA获得超过3万个赞[slogan]这个人很懒，什么都没留下![intro]27[view_count]

oracle中乐观锁、悲观锁与共享锁、排他锁区别

个人理解：
排他分为，乐观排他 悲观排他，就是乐观锁和悲观锁的意思，
乐观与悲观针对的是数据库而言，
乐观排他后，别人也能进行数据修改，但是当你提交时候发现数据被修改了就会报错。
悲观排他后，别人是动不了这些数据的。
共享锁不甚了解

[create_time]2013-05-10 13:57:45[/create_time]2012-08-20 17:24:13[finished_time]4[reply_count]7[alue_good]叮豆bV[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.895c7ce4.3M1a2n8nacke8CWbqF0l8A.jpg?time=5805&tieba_portrait_time=5805[avatar]TA获得超过300个赞[slogan]这个人很懒，什么都没留下![intro]4556[view_count]

如果悲观锁采用读写锁的话，感觉乐观锁没有比悲观锁强的时候

先申明概念：

1、悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
2、乐观锁（ Optimistic Locking ）
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

所以悲观锁和乐观锁最大的区别是是否一直锁定资源，悲观锁在事物的全流程锁定数据，乐观锁不锁定数据（用读写锁是阻塞事物，而用乐观锁则会导致回滚。这个是一种事物冲突后的不同锁的表象）。乐观锁的最大特点是在最后检查数据是否被修改，如果已被别人修改过，则回滚数据，避免脏数据。至于事物是否冲突和加锁没有直接联系，该冲突的还是会冲突，不管你加悲观锁和乐观锁都会冲突。

悲观锁和乐观锁都是为了解决丢失更新问题或者是脏读。悲观锁和乐观锁的重点就是是否在读取记录的时候直接上锁。悲观锁的缺点很明显，需要一个持续的数据库连接，这在web应用中已经不适合了。

一个比较清楚的场景

下面这个假设的实际场景可以比较清楚的帮助我们理解这个问题：

a. 假设当当网上用户下单买了本书，这时数据库中有条订单号为001的订单，其中有个status字段是’有效’,表示该订单是有效的；
b. 后台管理人员查询到这条001的订单，并且看到状态是有效的
c. 用户发现下单的时候下错了，于是撤销订单，假设运行这样一条SQL: update order_table set status = ‘取消’ where order_id = 001;
d. 后台管理人员由于在b这步看到状态有效的，这时，虽然用户在c这步已经撤销了订单，可是管理人员并未刷新界面，看到的订单状态还是有效的，于是点击”发货”按钮，将该订单发到物流部门，同时运行类似如下SQL，将订单状态改成已发货:update order_table set status = ‘已发货’ where order_id = 001

观点1：只有冲突非常严重的系统才需要悲观锁；
分析：这是更准确的说法；
“所有悲观锁的做法都适合于状态被修改的概率比较高的情况，具体是否合适则需要根据实际情况判断。”，表达的也是这个意思，不过说法不够准确；的确，之所以用悲观锁就是因为两个用户更新同一条数据的概率高，也就是冲突比较严重的情况下，所以才用悲观锁。

观点2：最后提交前作一次select for update检查，然后再提交update也是一种乐观锁的做法
分析：这是更准确的说法；
的确，这符合传统乐观锁的做法，就是到最后再去检查。但是wiki在解释悲观锁的做法的时候，’It is not appropriate for use in web application development.’， 现在已经很少有悲观锁的做法了，所以我自己将这种二次检查的做法也归为悲观锁的变种，因为这在所有乐观锁里面，做法和悲观锁是最接近的，都是先select for update，然后update

*****除了上面的观点1和观点2是更准确的说法，下面的所有观点都是错误的***********

观点3：这个问题的原因是因为数据库隔离级别是uncommitted read级别；
分析：这个观点是错误的；
这个过程本身就是在read committed隔离级别下发生的，从a到d每一步，尤其是d这步，并不是因为读到了未提交的数据，仅仅是因为用户界面没有刷新[事实上也不可能做自动刷新，这样相当于数据库一发生改变立刻要刷新了，这需要监听数据库了，显然这是简单问题复杂化了];

观点4：悲观锁是指一个用户在更新数据的时候，其他用户不能读取这条记录；也就是update阻塞读才叫悲观锁；
分析：这个观点是错的；
这在db2背景的开发中尤其常见；因为db2默认就是update会阻塞读；但是这是各个数据库对读写的时候上锁的并发处理实现不一样。但这根本不是悲观锁乐观锁的区别。Oracle可以做到写不阻塞读仅仅是因为做了多版本并发控制(Multiversion concurrency control), http://en.wikipedia.org/wiki/Multiversion_concurrency_control;但是在Oracle里面，一样可以做乐观锁和悲观锁的控制。这本质上是应用层面的选择。

观点5：Oracle实际上用的就是乐观锁
分析：这个观点是错的；
前面说了，Oracle的确可以做到写不阻塞读，但是这不是悲观锁和乐观锁的问题。这是因为实现了多版本并发控制。按照wiki的定义，悲观锁和乐观锁是在应用层面选择的。Oracle的应用只要在第二步做了select for update，就是悲观锁的做法；况且Oracle在任何隔离级别下，除了分布式事务两阶段提交的短暂时间，其他所有情况下都不存在写阻塞读的情况，如果按照这个观点的话那Oracle已经不能做悲观锁了-_-

观点6：不需要这么麻烦，只需要在d这步，最后提交更新的时候再做一个普通的select检查一下就可以；[就是double check的做法]
分析：这个观点是错的。
这个做法其实在http://www.hetaoblog.com/database-lost-update-pessimistic-lock/，’3. 传统悲观锁做法的变通’这节已经说明了，如果要这么做的话，仍然需要在最后提交更新前double check的时候做一个select for update， 否则select结束到update提交前的时间仍然有可能记录被修改；

观点7：应该尽可能使用悲观锁；
分析：这个观点是错的；
a. 根据悲观锁的概念，用户在读的时候(b这步)就会将记录锁住，直到更新结束的时候才会将锁释放，所以整个锁的过程时间比较长；
b. 另外，悲观锁需要有一个持续的数据库连接，这在当今的web应用中已经几乎不存在；wiki上也说了, 悲观锁‘is not appropriate for use in web application development.’

所以，现在大部分应用都应该是乐观锁的；

[create_time]2017-11-26 19:16:06[/create_time]2014-09-17 00:46:06[finished_time]2[reply_count]8[alue_good]anglewang98[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.86b0ba8f.QpuPWwfMvrI3M5iT8vyXhA.jpg?time=2910&tieba_portrait_time=2910[avatar]TA获得超过534个赞[slogan]这个人很懒，什么都没留下![intro]2562[view_count]

悲观锁和乐观锁的用处和区别？

乐观锁和悲观锁的区别如下：1、悲观锁是当线程拿到资源时，就对资源上锁，并在提交后，才释放锁资源，其他线程才能使用资源。2、乐观锁是当线程拿到资源时，上乐观锁，在提交之前，其他的锁也可以操作这个资源，当有冲突的时候，并发机制会保留前一个提交，打回后一个提交，让后一个线程重新获取资源后，再操作，然后提交。和git上传代码一样，两个线程都不是直接获取资源本身，而是先获取资源的两个copy版本，然后在这两个copy版本上修改。3、悲观锁和乐观锁在并发量低的时候，性能差不多，但是在并发量高的时候，乐观锁的性能远远优于悲观锁。4、常用的synchronized是悲观锁，lock是乐观锁。

[create_time]2022-11-15 00:11:00[/create_time]2013-11-29 17:44:11[finished_time]7[reply_count]0[alue_good]乾莱信息咨询[uname]https://pic.rmb.bdstatic.com/bjh/user/62ac8245037c35cef5dd05b07789a9ca.jpeg[avatar]百度认证:内蒙古乾莱科技官方账号[slogan]这个人很懒，什么都没留下![intro]29229[view_count]

mysql 悲观锁和乐观锁的区别

悲观锁与乐观锁是两种常见的资源并发锁设计思路，也是并发编程中一个非常基础的概念。本文将对这两种常见的锁机制在数据库数据上的实现进行比较系统的介绍。
悲观锁（Pessimistic Lock）
悲观锁的特点是先获取锁，再进行业务操作，即“悲观”的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。通常所说的“一锁二查三更新”即指的是使用悲观锁。通常来讲在数据库上的悲观锁需要数据库本身提供支持，即通过常用的select … for update操作来实现悲观锁。当数据库执行select for update时会获取被select中的数据行的行锁，因此其他并发执行的select for update如果试图选中同一行则会发生排斥（需要等待行锁被释放），因此达到锁的效果。select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。
这里需要注意的一点是不同的数据库对select for update的实现和支持都是有所区别的，例如oracle支持select for update no wait，表示如果拿不到锁立刻报错，而不是等待，mysql就没有no wait这个选项。另外mysql还有个问题是select for update语句执行中所有扫描过的行都会被锁上，这一点很容易造成问题。因此如果在mysql中用悲观锁务必要确定走了索引，而不是全表扫描。
乐观锁（Optimistic Lock）
乐观锁的特点先进行业务操作，不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的，因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。
乐观锁在数据库上的实现完全是逻辑的，不需要数据库提供特殊的支持。一般的做法是在需要锁的数据上增加一个版本号，或者时间戳，然后按照如下方式实现：

1. SELECT data AS old_data, version AS old_version FROM …;
2. 根据获取的数据进行业务操作，得到new_data和new_version
3. UPDATE SET data = new_data, version = new_version WHERE version = old_version
if (updated row > 0) {
// 乐观锁获取成功，操作完成
} else {
// 乐观锁获取失败，回滚并重试
}

[create_time]2017-12-06 16:28:52[/create_time]2017-12-06 17:44:53[finished_time]1[reply_count]1[alue_good]智者总要千虑[uname]https://gips0.baidu.com/it/u=557050501,3912290178&fm=3012&app=3012&autime=1660579115&size=b200,200[avatar]说的都是干货，快来关注[slogan]这个人很懒，什么都没留下![intro]502[view_count]

mysql数据库怎么设置乐观锁

乐观锁与悲观锁不同的是，它是一种逻辑上的锁，而不需要数据库提供锁机制来支持
当数据很重要，回滚或重试一次需要很大的开销时，需要保证操作的ACID性质，此时应该采用悲观锁
而当数据对即时的一致性要求不高，重试一次不太影响整体性能时，可以采用乐观锁来保证最终一致性，同时有利于提高并发性
通常，乐观锁采用版本号/时间戳的形式实现：给数据额外增加一个版本号字段进行控制；更新时，若提交的数据所带的版本号与当前记录的版本号一致，则允许变更执行并更新版本号；若不一致，则意味着产生冲突，根据业务需求直接丢弃并返回失败，或者尝试合并
在MySQL的实践中，常见的一种使用乐观锁的方法，是在需要使用乐观锁的表中，新增一个version字段
例如：
create table product_amount (
id int not null primary key auto_increment,
product_name varchar(64) not null,
selling_amount int not null,
storing_amount int not null,
version int not null
);
当需要更新销售中的商品数量（selling_amount）时，使用如下的SQL语句：
update product_amount set selling_amount = #{selling_amount}, version = #{new_version} where id=#{id} and version = #{old_version};
若该语句返回1，则表示更新成功；若返回0，则表示前后的version不一致，产生冲突，更新失败
对于更新仓库中的商品数据（storing_amount）时，也是同理
不过，这样为每行记录都统一设置一个version字段的乐观锁方式，存在一个问题：上例中，如果同时需要单独对selling_amount及storing_amount进行update（两条SQL语句分别单独执行），那么后执行的一条会因为先执行的一条更新了version字段而失败，而这种失败显然是没有必要的，白白浪费了开销
一种比较好的方式是为每个需要乐观锁的字段单独设置版本号，例如对上例的改造：
create table product_amount (
id int not null primary key auto_increment,
product_name varchar(64) not null,
selling_amount int not null,
selling_version int not null,
storing_amount int not null,
storing_version int not null
);
selling_amount和storing_amount分别拥有自己的乐观锁版本号（selling_version和storing_version），更新时分别只关注自己的版本号，这样就不会因为版本号被其它字段修改而失败，提高了并发性

[create_time]2016-08-30 09:18:42[/create_time]2016-08-30 10:43:43[finished_time]1[reply_count]8[alue_good]奔跑的窝牛的家[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.5670b4b5.LjA8E22ylXmRoheshxICbQ.jpg?time=5593&tieba_portrait_time=5593[avatar]每个回答都超有意思的[slogan]这个人很懒，什么都没留下![intro]3394[view_count]

mysql如何实现乐观锁

乐观锁与悲观锁不同的是，它是一种逻辑上的锁，而不需要数据库提供锁机制来支持
当数据很重要，回滚或重试一次需要很大的开销时，需要保证操作的ACID性质，此时应该采用悲观锁
而当数据对即时的一致性要求不高，重试一次不太影响整体性能时，可以采用乐观锁来保证最终一致性，同时有利于提高并发性
通常，乐观锁采用版本号/时间戳的形式实现：给数据额外增加一个版本号字段进行控制；更新时，若提交的数据所带的版本号与当前记录的版本号一致，则允许变更执行并更新版本号；若不一致，则意味着产生冲突，根据业务需求直接丢弃并返回失败，或者尝试合并
在MySQL的实践中，常见的一种使用乐观锁的方法，是在需要使用乐观锁的表中，新增一个version字段
例如：
create table product_amount (
id int not null primary key auto_increment,
product_name varchar(64) not null,
selling_amount int not null,
storing_amount int not null,
version int not null
);
当需要更新销售中的商品数量（selling_amount）时，使用如下的SQL语句：
update product_amount set selling_amount = #{selling_amount}, version = #{new_version} where id=#{id} and version = #{old_version};
若该语句返回1，则表示更新成功；若返回0，则表示前后的version不一致，产生冲突，更新失败
对于更新仓库中的商品数据（storing_amount）时，也是同理
不过，这样为每行记录都统一设置一个version字段的乐观锁方式，存在一个问题：上例中，如果同时需要单独对selling_amount及storing_amount进行update（两条SQL语句分别单独执行），那么后执行的一条会因为先执行的一条更新了version字段而失败，而这种失败显然是没有必要的，白白浪费了开销
一种比较好的方式是为每个需要乐观锁的字段单独设置版本号，例如对上例的改造：
create table product_amount (
id int not null primary key auto_increment,
product_name varchar(64) not null,
selling_amount int not null,
selling_version int not null,
storing_amount int not null,
storing_version int not null
);
selling_amount和storing_amount分别拥有自己的乐观锁版本号（selling_version和storing_version），更新时分别只关注自己的版本号，这样就不会因为版本号被其它字段修改而失败，提高了并发性

[create_time]2018-06-21 15:56:53[/create_time]2018-07-04 10:29:59[finished_time]1[reply_count]3[alue_good]折柳成萌[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.c57ab76a.SMxaAr5ZiLsbYSX0IpKglg.jpg?time=7434&tieba_portrait_time=7434[avatar]繁杂信息太多，你要学会辨别[slogan]这个人很懒，什么都没留下![intro]884[view_count]

数据库update默认的是悲观锁定还是乐观锁

是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。针对于不同的业务场景，应该选用不同的并发控制方式。所以，不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在DBMS中，悲观锁正是利用数据库本身提供的锁机制来实现的。

[create_time]2023-05-18 10:12:19[/create_time]2023-06-02 10:12:19[finished_time]1[reply_count]0[alue_good]猪八戒网[uname]https://pic.rmb.bdstatic.com/c958ab6d003b1ca8df45ae4fa0226ac5.jpeg[avatar]百度认证:重庆猪八戒网络有限公司官方账号[slogan]猪八戒网（zbj.com）创建于2006年，现已形成猪八戒网、天蓬网和线下八戒工场的“双平台+一社区”服务模式，是中国领先的人才共享平台。 [intro]14[view_count]