乐观锁与悲观锁

何谓悲观锁与乐观锁乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。

这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。

悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。

传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。

乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。

在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

两种锁的使用场景从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。

但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

乐观锁常见的两种实现方式乐观锁一般会使用版本号机制或CAS算法实现。

1. 版本号机制一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。

当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

一.区别数据库悲观锁和乐观锁：1、悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

2、乐观锁（Optimistic Locking ）相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。

悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。

但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

而乐观锁机制在一定程度上解决了这个问题。

乐观锁，大多是基于数据版本（Version ）记录机制实现。

何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。

读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。

此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

根据定义可以看出区别：1，悲观锁是数据库实现的，而乐观锁可以在程序中通过版本控制实现。

2，加锁的时机不同。

悲观锁会在事务的最初就要更新的数据全部锁定，乐观锁可以在操作的最后才加锁。

（这块没怎么想清楚）这点类似于java早期的synchronized锁和现在的并发包中的锁。

synchronized锁会在程序执行到同步的方法时就加锁，并发包中则是通过cvs操作（其实就是版本控制）。

这样看synchronized属于悲观锁，并发包中的锁属于乐观锁。

二．数据库索引1.可以利用索引快速访问数据库表中的特定信息。

索引是对数据库表中一个或多个列（例如，employee ? 表的姓氏? (lname) ? 列）的值进行排序的结构。

乐观锁和悲观锁的区别乐观锁在关系数据库管理系统⾥，乐观并发控制（⼜名”乐观锁”，Optimistic Concurrency Control，缩写”OCC”）是⼀种并发控制的⽅法。

它假设多⽤户并发的事务在处理时不会彼此互相影响，各事务能够在不产⽣锁的情况下处理各⾃影响的那部分数据。

在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务⼜修改了该数据。

如果其他事务有更新的话，正在提交的事务会进⾏回滚。

乐观事务控制最早是由孔祥重（H.T.Kung）教授提出。

乐观并发控制的阶段乐观并发控制的事务包括以下阶段：1. 读取：事务将数据读⼊缓存，这时系统会给事务分派⼀个时间戳。

2. 校验：事务执⾏完毕后，进⾏提交。

这时同步校验所有事务，如果事务所读取的数据在读取之后⼜被其他事务修改，则产⽣冲突，事务被中断回滚。

3. 写⼊：通过校验阶段后，将更新的数据写⼊数据库。

乐观并发控制多数⽤于数据争⽤不⼤、冲突较少的环境中，这种环境中，偶尔回滚事务的成本会低于读取数据时锁定数据的成本，因此可以获得⽐其他并发控制⽅法更⾼的吞吐量。

相对于悲观锁，在对数据库进⾏处理的时候，乐观锁并不会使⽤数据库提供的锁机制。

⼀般的实现乐观锁的⽅式就是记录数据版本。

数据版本,为数据增加的⼀个版本标识。

当读取数据时，将版本标识的值⼀同读出，数据每更新⼀次，同时对版本标识进⾏更新。

当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第⼀次取出来的版本标识进⾏⽐对，如果数据库表当前版本号与第⼀次取出来的版本标识值相等，则予以更新，否则认为是过期数据。

实现数据版本有两种⽅式，第⼀种是使⽤版本号，第⼆种是使⽤时间戳。

使⽤版本号实现乐观锁使⽤版本号时，可以在数据初始化时指定⼀个版本号，每次对数据的更新操作都对版本号执⾏+1操作。

并判断当前版本号是不是该数据的最新的版本号。

使⽤版本号实现乐观锁使⽤版本号时，可以在数据初始化时指定⼀个版本号，每次对数据的更新操作都对版本号执⾏+1操作。

数据库防止并发冲突数据库防止并发冲突的主要方法是使用事务的隔离性（Isolation）和锁机制（Locking）。

一．事务的隔离性：１．当多个事务同时对数据库进行操作时，隔离性确保每个事务都独立运行，不受其他事务的影响。

２．数据库管理系统（DBMS）通过确保事务的原子性、一致性、隔离性和持久性（ACID属性）来管理并发操作。

二．锁机制：１．锁是用来控制对共享资源的并发访问的机制。

当事务正在修改某个数据项时，它可以锁定该数据项，以防止其他事务同时修改它。

２．根据锁定粒度，锁可以分为表锁和行锁。

表锁锁定整个表，而行锁只锁定被访问的行。

行锁通常提供更好的并发性，但实现起来更复杂。

３．锁的类型包括共享锁（允许多个事务同时读取资源）和排他锁（只允许一个事务修改资源）。

三．乐观锁和悲观锁：１．乐观锁：它假设多个事务同时冲突修改同一个数据项的可能性很小。

因此，它不会预先锁定数据，而是在数据提交时检查是否有冲突。

如果发生冲突，则事务会被回滚。

乐观锁通常通过版本号或时间戳来实现。

２．悲观锁：它假设多个事务同时冲突修改同一个数据项的可能性很大。

因此，它会在数据被访问时立即锁定数据，直到事务完成。

四．其他并发控制策略：１．时间戳排序：每个事务都有一个唯一的时间戳。

当事务尝试修改一个数据项时，它会检查该数据项的时间戳。

如果数据项的时间戳晚于事务的时间戳，那么事务就会回滚。

２．多版本并发控制（MVCC）：这是许多现代数据库系统（如PostgreSQL和MySQL的InnoDB存储引擎）使用的一种技术。

每个数据项可以有多个版本，每个事务都看到数据的一个特定版本。

这允许多个事务同时读取同一数据项，而不会相互干扰。

为了有效地防止并发冲突，需要根据具体的应用场景和需求选择适当的并发控制策略。

锁：主流锁整体认知（悲观锁与乐观锁、CAS算法、⾃旋锁、synchronized分析）1、悲观锁与乐观锁（1）悲观锁与乐观锁悲观锁悲观锁认为⾃⼰在获取数据的时候⼀定有别的线程来修改数据，在获取数据的时候会先加锁，确保数据不会被别的线程修改锁实现:关键字synchronized、接⼝Lock的实现类适⽤场景:写操作较多，先加锁可以保证写操作时数据正确乐观锁乐观锁认为⾃已在获取数据时不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据锁实现: CAS算法，例如AtomicInteger 类的原⼦⾃增是同过CAS⾃旋实现适⽤场景:读操作较多，不加锁的特点能够使其读操作的性能⼤幅提升（2）执⾏流程悲观锁多个线程尝试获取同步资源的锁（给同步资源加锁）某个线程加锁成功并执⾏操作，其他线程进⼊等待获取到锁的线程执⾏完成之后会释放锁，然后CPU唤醒等待的线程，被唤醒的线程再次尝试获取锁乐观锁线程直接获取同步资源数据执⾏各⾃的操作更新内存中的同步资源之前先判断资源是否被其他线程修改。

没有被修改，就可以更新内存中同步资源的值；被其他线程修改的话就根据实现⽅法执⾏不同的操作（3）锁产⽣的原因进程的数据是独⽴的，线程的数据是共享的，因此只说线程的安全性，解决线程安全有以下⽅法：不跨线程共享变量,线程共享的变量改为⽅法局部级变量使状态变量为不可变的，使⽤final修饰 (将变量变为常量)在任何访问状态变量的时候使⽤同步，使⽤synchronized修饰⽅法，或使⽤同步代码块。

每个共享的可变变量都需要由唯⼀个确定的锁保护，使⽤Lock锁。

锁是⼀种保护机制，在多线程的情况下能够保证数据的⼀致性（4）锁的分类悲观锁、乐观锁、可重⼊锁、⾃旋锁、独享锁、读写锁、阻塞锁、公平锁、⾮公平锁、分段锁、对象锁、类所、轻量级锁、分布式锁等等⾮常多。

乐观锁:跟悲观锁相反，假设数据⼀般情况下不会造成冲突，只有在数据进⾏提交更新时，才会正式对数据的冲突与否进⾏检测，如果发现冲突了，则返回错误信息，让⽤户决定如何去做。

谈谈乐观锁和悲观锁前言我在网上查阅了很多关于乐观锁和悲观锁的介绍和使用场景，大都用这样的一句话来概括了- 悲观锁：比较适合写入操作比较频繁的场景，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。

- 乐观锁：比较适合读取操作比较频繁的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。

但是随着进一步的思考，我对这些结论又产生不同的看法，下面我就说说我对这个概念的理解和看法。

悲观锁你和你老婆都去银行取钱，一个账户里只有5000元，然后使用`select for update`可以避免丢失更新。

但是这个时候，你查询余额的时候接了一个电话，打了30分钟。

在这30分钟内，你啥事都没干，这样你的账户相当于被锁住了，你老婆得等你，不仅你老婆要等你，这个时候，你的商业合作伙伴要给你打钱，你的整个账户都处于锁定状态，所有依赖于你的账户的修改操作，都得暂停，因为你的账户在这个过程一直被排它锁占领者，这样你的账户在这30分钟内，处于瘫痪状态，除了你独占的事物中可以操作，其他事物全部瘫痪，如果并发很大，你的账户是一个业务很繁忙的账户（连锁商店统一扫码收款账户），很多收款业务都无法进行。

在`select for update`所在的事物中select的数据，是被你这个事物独占的，如果该事物耗时很长，并且，你锁定的行又处在很多大并发的写操作中，麻烦就来了，这种`select for update`的锁定方式，防止丢失更新，表现形式上，是一种悲观锁定方式，它在操作的时候，必须要独占数据，它总认为有人会来修改它，很悲观犹如惊弓之鸟，很有可能是，他10000次操作，只有1次，出现了有人修改，9999次，都没人动，但是他依然很悲观，采用了独占式锁定。

乐观锁都用过svn，我们从svn服务器中下载了文件到本地，然后对他进行修改，然后提交回svn。

数据库中并发控制的乐观锁与悲观锁比较在数据库管理系统中，为了保证并发操作的正确性和一致性，需要进行并发控制。

乐观锁和悲观锁是两种常见的并发控制方法。

本文将比较乐观锁和悲观锁的特点、适用场景以及优缺点。

一、乐观锁概述乐观锁是一种乐观的并发控制方式，它假设并发访问不会发生冲突，只在事务提交时检查是否有冲突。

乐观锁使用版本号或时间戳作为标记来检测冲突。

当发现冲突时，乐观锁会回滚事务并重新执行。

二、悲观锁概述悲观锁是一种悲观的并发控制方式，它假设并发访问会发生冲突，因此在操作之前会对数据进行加锁，阻止其他事务的访问。

只有当前事务完成操作后，其他事务才能访问该数据。

三、乐观锁与悲观锁的比较1. 特点比较：a. 乐观锁：假设并发冲突较少，并发操作不会发生阻塞，只在事务提交时检测冲突。

b. 悲观锁：假设并发冲突较多，加锁导致其他事务被阻塞，直到当前事务完成操作。

2. 适用场景比较：a. 乐观锁：适用于读请求较多、冲突较少的场景，例如读多写少的应用。

b. 悲观锁：适用于写请求较多、冲突较多的场景，例如高并发写入数据库的应用。

3. 实现方式比较：a. 乐观锁：使用版本号或时间戳来检测冲突，事务提交时检查数据是否被修改。

b. 悲观锁：使用锁机制来保证数据的独占性，例如共享锁和排它锁。

4. 性能比较：a. 乐观锁：由于避免加锁操作，可以提高并发性能，适用于并发情况较少的场景。

b. 悲观锁：由于加锁操作可能导致阻塞，性能较乐观锁稍差，适用于并发情况较多的场景。

5. 开发复杂度比较：a. 乐观锁：需要在数据表中添加版本号或时间戳字段，并在事务提交时检查冲突。

b. 悲观锁：需要使用锁机制，例如共享锁和排它锁，并在代码中显式加锁和解锁。

6. 异常处理比较：a. 乐观锁：如果发现冲突，事务将回滚并重新执行，需要处理并发冲突的异常情况。

b. 悲观锁：如果发现冲突，其他事务需要等待锁被释放，可能会引起超时等异常情况。

7. 数据的可见性比较：a. 乐观锁：在事务提交前，其他事务不可见已提交的数据，可能会造成数据不一致的问题。

数据库是现代信息系统中必不可少的组成部分，而数据库管理的性能和效率往往取决于并发控制与锁策略的优化。

在这篇文章中，我们将讨论数据库管理中的并发控制与锁策略，并探讨其实现原理和应用场景。

一、并发控制的概念和重要性并发控制是指在多个用户同时对数据库进行读写操作时，如何保证数据的一致性和完整性的技术手段。

在多用户场景下，若不进行并发控制，可能会出现数据不一致的情况，从而影响系统的可靠性和稳定性。

因此，合理的并发控制策略是数据库管理的关键。

二、锁策略的基本原理1. 悲观锁悲观锁是指在事务执行期间，将数据加锁以阻止其他事务对该数据进行修改或读取。

当一个事务需要修改某个数据时，它会首先请求加锁，成功加锁后才能进行后续操作。

悲观锁适用于资源竞争激烈、冲突较多的场景，但会降低并发性能。

2. 乐观锁乐观锁是指在事务执行期间，不主动加锁，而是通过版本号、时间戳等方式判断数据是否被其他事务修改，从而保证数据的一致性。

当一个事务需要修改数据时，它会检查数据版本，如果发现其他事务已经修改过，则回滚当前事务，重新读取数据后再进行修改。

三、并发控制与锁策略的实现技术1. 两阶段锁协议两阶段锁协议是一种常用的并发控制技术，它将事务的执行过程划分为两个阶段，即加锁阶段和解锁阶段。

在加锁阶段，事务可以获取锁，读取或修改数据；而在解锁阶段，事务必须释放所有的锁，确保数据的完整性和一致性。

两阶段锁协议通过保证事务的一致性和互斥性来实现并发控制。

2. 多版本并发控制多版本并发控制是一种乐观锁策略，它通过记录数据的不同版本来实现并发控制。

当一个事务读取数据时，系统会根据事务开始时间和事务结束时间来选择合适的数据版本，从而避免数据冲突。

多版本并发控制可以提高系统的并发性能，但也会增加存储开销。

四、并发控制与锁策略的应用场景1. 银行系统在银行系统中，用户可能会同时进行多个操作，如转账、存款、取款等。

为了保证用户账户余额的正确性和一致性，需要使用并发控制和锁策略来避免数据冲突和并发访问。

应用乐观锁和悲观锁处理并发访问问题在并发访问问题中，乐观锁和悲观锁是两种解决并发冲突的不同策略。

乐观锁假设并发冲突的概率较低，因此在进行数据操作时不会立即加锁，而是先进行操作，然后再检查是否发生冲突。

如果存在冲突，则进行回滚或者重试；悲观锁则是一种悲观策略，它认为并发冲突的概率较高，因此在进行数据操作前会先加锁，直到操作完成后再释放锁，以保证数据的一致性和完整性。

乐观锁一般通过版本号或时间戳来实现。

在一个表中增加一个version字段，每次更新数据时，将version字段的值加1，当一个事务要提交更新时，首先比较它的version值是否等于最新的数据版本号，如果相等，则提交更新，如果不相等，则表示有其他事务已经并发修改了数据，需要进行回滚或者重试。

乐观锁的优点是不需要加锁，性能较好，但是需要对数据库进行乐观锁相关的操作，增加了复杂性。

悲观锁一般通过数据库的锁机制来实现。

在进行数据操作之前，先对数据进行加锁，阻止其他事务对该数据进行操作，直到当前事务完成后才会释放锁。

悲观锁的优点是能够保证数据的一致性和完整性，但是需要进行加锁和解锁操作，会增加系统开销和资源消耗。

在实际应用中，选择合适的锁策略取决于并发冲突的概率、数据操作的复杂性、系统性能和响应时间的要求等因素。

乐观锁适用于以下情况：1.并发冲突的概率较低，大部分情况下都能成功地进行操作，只有少数情况下才会发生冲突。

2.数据操作的复杂性较高，使用悲观锁会对系统性能产生较大的影响。

3.系统要求响应时间较短，不能因为加锁而导致系统响应时间延长。

例如，一个简单的在线购物系统中，用户下单时需要减少库存数量，如果使用悲观锁，每个用户必须等待前一个用户完成库存减少操作后才能进行操作，这样会导致并发性能下降。

而如果使用乐观锁，用户可以先减少库存数量，然后再检查库存是否足够，如果不足则回滚。

这样，大部分情况下用户可以快速下单并减少库存数量，只有在极少数情况下才会出现库存不足的情况。

乐观锁和悲观锁基本概念乐观锁和悲观锁是两种思想，⽤于解决并发场景下的数据竞争问题。

乐观锁：乐观锁在操作数据时⾮常乐观，认为别⼈不会同时修改数据。

因此乐观锁不会上锁，只是在执⾏更新的时候判断⼀下在此期间别⼈是否修改了数据：如果别⼈修改了数据则放弃操作，否则执⾏操作。

悲观锁：悲观锁在操作数据时⽐较悲观，认为别⼈会同时修改数据。

因此操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他⼈不能修改数据。

实现⽅式在说明实现⽅式之前，需要明确：乐观锁和悲观锁是两种思想，它们的使⽤是⾮常⼴泛的，不局限于某种编程语⾔或数据库。

悲观锁的实现⽅式是加锁，加锁既可以是对代码块加锁（如Java的synchronized关键字），也可以是对数据加锁（如MySQL中的排它锁）。

乐观锁的实现⽅式主要有两种：CAS机制和版本号机制，下⾯详细介绍。

1、CAS（Compare And Swap）CAS操作包括了3个操作数：需要读写的内存位置(V)进⾏⽐较的预期值(A)拟写⼊的新值(B)CAS操作逻辑如下：如果内存位置V的值等于预期的A值，则将该位置更新为新值B，否则不进⾏任何操作。

许多CAS的操作是⾃旋的：如果操作不成功，会⼀直重试，直到操作成功为⽌。

CAS包含了Compare和Swap两个操作，CAS是由CPU⽀持的原⼦操作，其原⼦性是在硬件层⾯进⾏保证的。

2、版本号机制除了CAS，版本号机制也可以⽤来实现乐观锁。

版本号机制的基本思路是在数据中增加⼀个字段version，表⽰该数据的版本号，每当数据被修改，版本号加1。

当某个线程查询数据时，将该数据的版本号⼀起查出来；当该线程更新数据时，判断当前版本号与之前读取的版本号是否⼀致，如果⼀致才进⾏操作。

需要注意的是，这⾥使⽤了版本号作为判断数据变化的标记，实际上可以根据实际情况选⽤其他能够标记数据版本的字段，如时间戳等。

优缺点和适⽤场景乐观锁和悲观锁并没有优劣之分，它们有各⾃适合的场景；下⾯从两个⽅⾯进⾏说明。

总结乐观锁和悲观锁乐观锁和悲观锁，就是对数据库进⾏操作时使⽤的，乐观锁是update是开始，悲观锁是查询记录那⼀刻开始，两者结束都是commit或者rollback悲观锁，⼀直锁，不让改乐观锁，只在更新的时候判断⼀下别⼈有没有改过这个数据，保证商品只被卖出⼀次，可以使⽤版本号等机制，可以提⾼数据吞吐量并发控制机制，当⼀个⽤户锁住了数据之后，其他⽤户就不能访问悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别⼈会修改，所以每次在拿数据的时候都会上锁，这样别⼈想拿这个数据就会block直到它拿到锁。

传统的关系型⾥边就⽤到了很多这种锁机制，⽐如⾏锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别⼈不会修改，所以不会上锁，但是在更新的时候会判断⼀下在此期间别⼈有没有去更新这个数据，可以使⽤版本号等机制。

乐观锁适⽤于多读的应⽤类型，这样可以提⾼吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

两种锁各有优缺点，不可认为⼀种好于另⼀种，像乐观锁适⽤于写⽐较少的情况下，即冲突真的很少发⽣的时候，这样可以省去了锁的开销，加⼤了系统的整个吞吐量。

但如果经常产⽣冲突，上层应⽤会不断的进⾏retry，这样反倒是降低了性能，所以这种情况下⽤悲观锁就⽐较合适。

1、⽆论是选择悲观锁策略，还是乐观锁策略。

如果⼀个对象被上了锁，那么该对象都会受这个锁的控制和影响。

如果这个锁是个排它锁，那么其它会话都不能修改它。

2、选择悲观锁策略，还是乐观锁策略，这主要是由应⽤和业务需求来确定的。

如果你的应⽤和业务经常会出现从我看到要修改的记录的值，到我修改完成该记录这个时间段内，该记录有较⼤概率被其它会话所修改。

换句话说就是，在我真正去做出修改时，这个记录的值很可能已经与我当初看到的不同了。

数据库悲观锁和乐观锁⼀、OracleOracle数据库悲观锁与乐观锁是本⽂我们主要要介绍的内容。

有时候为了得到最⼤的性能，⼀般数据库都有并发机制，不过带来的问题就是数据访问的冲突。

为了解决这个问题，⼤多数数据库⽤的⽅法就是数据的锁定。

数据的锁定分为两种⽅法，第⼀种叫做悲观锁，第⼆种叫做乐观锁。

什么叫悲观锁呢，悲观锁顾名思义，就是对数据的冲突采取⼀种悲观的态度，也就是说假设数据肯定会冲突，所以在数据开始读取的时候就把数据锁定住。

⽽乐观锁就是认为数据⼀般情况下不会造成冲突，所以在数据进⾏提交更新的时候，才会正式对数据的冲突与否进⾏检测，如果发现冲突了，则让⽤户返回错误的信息，让⽤户决定如何去做。

先从悲观锁开始说。

在SqlServer等其余很多数据库中，数据的锁定通常采⽤页级锁的⽅式，也就是说对⼀张表内的数据是⼀种串⾏化的更新插⼊机制，在任何时间同⼀张表只会插1条数据，别的想插⼊的数据要等到这⼀条数据插完以后才能依次插⼊。

带来的后果就是性能的降低，在多⽤户并发访问的时候，当对⼀张表进⾏频繁操作时，会发现响应效率很低，数据库经常处于⼀种假死状态。

⽽Oracle ⽤的是⾏级锁，只是对想锁定的数据才进⾏锁定，其余的数据不相⼲，所以在对Oracle表中并发插数据的时候，基本上不会有任何影响。

注：对于悲观锁是针对并发的可能性⽐较⼤，⽽⼀般在我们的应⽤中⽤乐观锁⾜以。

Oracle的悲观锁需要利⽤⼀条现有的连接，分成两种⽅式，从SQL语句的区别来看，就是⼀种是for update，⼀种是for update nowait的形式。

⽐如我们看⼀个例⼦。

⾸先建⽴测试⽤的数据库表。

CREATE TABLE TEST(ID,NAME,LOCATION,VALUE,CONSTRAINT test_pk PRIMARY KEY(ID))AS SELECT deptno, dname, loc, 1 FROM scott.dept这⾥我们利⽤了Oracle的Sample的scott⽤户的表，把数据copy到我们的test表中。

Mysql锁机制--乐观锁悲观锁===============从⽂章中，我们知道 Mysql 并发事务会引起更新丢失问题，解决办法是锁。

所以本⽂将对锁（乐观锁、悲观锁）进⾏分析。

第⼀部分悲观锁1 概念（来⾃百科）悲观锁，正如其名，它指的是对数据被外界（包括当前系统的其它事务，以及来⾃外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排它性，否则，即使在本系统中实现了加锁机制，也⽆法保证外部系统不会修改数据）。

还可以简单理解，就是Java中的 Synchronized 关键字。

只要对代码加了 Synchronized 关键字，JVM 底层就能保证其线程安全性。

那么，在 Mysql 中如何实现悲观锁呢？下⾯分别以命令⾏以及Java代码的⽅式进⾏演⽰。

2 命令⾏演⽰2.1 准备数据DROP DATABASE IF EXISTS cyhTest;CREATE DATABASE cyhTest;USE cyhTest;DROP TABLE IF EXISTS employee;CREATE TABLE IF NOT EXISTS employee (id INTEGER NOT NULL,money INTEGER,version INTEGER,PRIMARY KEY (id))ENGINE = INNODB;INSERT INTO employee VALUE (1, 0, 1);SELECT*FROM employee;⽬前数据库中只有⼀条记录，且初始Money=02.2 测试测试准备：还是两个会话（终端），左边会话是⽩⾊背景、右边会话是⿊⾊背景关闭⾃动提交：set autocommit = 0;现在开始测试：第⼀步：两个终端均关闭⾃动提交左边：右边：第⼆步：左边利⽤ select .... for update 的悲观锁语法锁住记录第三步：右边也尝试利⽤ select .... for update 的悲观锁语法锁住记录可以看到，Sql语句被挂起（被阻塞）！提⽰：如果被阻塞的时间太长，会提⽰如下：第四步：左边执⾏更新操作并提交事务Sql语句：update employee set money=0+1where id =1;commit;结果：分析：Money 的旧值为0，所以更新时 Money=0+1⼀执⾏ commit 后，注意查看右边Sql语句的变化第五步：查看右边Sql语句的变化分析：被左边悲观锁阻塞了 11.33 秒Money=1，这是左边更新后的结果2.3 结论可以看到，当左边（事务A）使⽤了 select ... for update 的悲观锁后，右边（事务B）再想使⽤将被阻塞，同时，阻塞被解除后事务B能看到事务A对数据的修改，所以，这就可以很好地解决并发事务的更新丢失问题啦（诚然，这也是⼈家悲观锁的分内事）3 Java代码演⽰3.1 准备确保数据库⽤户名和密码对应；执⾏ test.sql ⽂件中的脚本；3.2 业务逻辑代码XML ⽂件中的 Mapper：<select id="findByIdWithPessimisticLock" resultType="com.cyh.entity.Employee">SELECT * FROM employee WHERE id = #{id} FOR UPDATE</select>提⽰：这⾥是 SELCT ... FOR UPDATEService 中的业务逻辑：1 @Transactional(rollbackFor = RuntimeException.class)2public void increaseMoneyWithPessimisticLock(Integer id) {3 Employee employee = employeeMapper.findByIdWithPessimisticLock(id);4final Integer oldMoney = employee.getMoney();5 ("oldMoney: {}", oldMoney);6 employee.setMoney(oldMoney + 1);7 employeeMapper.updateEmployee(employee);8 }提⽰：第3⾏中的 findByIdWithPessimisticLock() ⽅法就对应上⾯XML⽂件中的Mapper，有悲观锁3.3 测试代码private void increaseMoneyWithPessimisticLock() {int threadCount = 100;while (threadCount-- > 0) {new Thread(() -> employeeService.increaseMoneyWithPessimisticLock(1)).start();}}提⽰：100根线程，每个线程将Money值加1，预期结果是1003.4 执⾏测试&查看结果SELECT*FROM employee;Money=100，是预期结果。

悲观锁乐观锁乐观锁与悲观锁是一种广义上的概念，体现了看待线程同步的不同角度。

在Java和数据库中都有此概念对应的实际应用。

1.1 概念•悲观锁:对于同一数据的并发操作，悲观锁认为其他线程在使用时必须修改数据，所以在获取数据时会先锁定数据，以保证数据不会被其他线程修改。

•乐观锁:乐观锁不认为其他线程在使用时会修改数据，所以他不会加锁。

他只是在更新数据时判断其他线程之前是否更新过数据。

如果此数据尚未更新，则当前线程会成功写入自己修改的数据。

如果数据已经被其他线程更新，根据不同的实现会执行不同的操作(比如报错或者自动重试)。

乐观锁在Java中是通过使用无锁编程来实现，最常采用的是CAS算法。

Java原子类中的递增操作就通过CAS自旋实现的。

1.2 Java中使用•悲观锁：Java中，synchronized关键字和Lock的实现类都是悲观锁。

•乐观锁：Java原子类中的递增操作就通过CAS自旋实现的。

1.3 Mysql中使用•悲观锁：手动提交事务，select ... for update;要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用automit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。

//我们可以使用命令设置MySQL为非automit模式：set automit=0;//设置完automit后，我们就可以执行我们的正常业务了。

具体如下：//0.开始事务begin;/begin work;/start transaction; (三者选一就可以) //1.查询出商品信息，锁定这行数据select status from t_goods where id=1 for update;//2.根据商品信息生成订单insert into t_orders (id,goods_id) values (null,1);//3.修改商品status为2update t_goods set status=2;//4.提交事务mit;/mit work;•乐观锁：使用版本号update tablexxx setname=#name#,version=version+1 where id=#id# andversion=#versionid字段要求是主键或者唯一索引，这样的话就是行锁，不然的话就是是锁表，会死人的1.4 总结悲观锁适合有很多写操作的场景。

java悲观锁和乐观锁原理在并发编程中，悲观锁和乐观锁是两种常见的锁机制，用于解决多线程访问共享资源时可能发生的数据冲突问题。

本文将详细介绍悲观锁和乐观锁的原理以及它们的应用场景和优缺点。

悲观锁是一种保守的锁机制，它假设在并发访问时会发生冲突，因此在访问共享资源之前会先对其进行加锁。

悲观锁的典型应用是通过使用关键字synchronized或使用ReentrantLock类来实现。

在使用悲观锁时，当一个线程获得了锁之后，其他线程必须等待该线程释放锁才能访问共享资源。

悲观锁的原理是通过互斥来保证数据的一致性。

当一个线程获得了锁之后，其他线程将无法继续执行，只能等待锁的释放。

这种机制确保了同一时间只有一个线程可以访问共享资源，从而避免了数据冲突的发生。

悲观锁的优点是简单易用，可以有效地避免数据冲突。

然而，悲观锁的缺点是在并发量较高的情况下，由于需要频繁地进行加锁和释放锁操作，会导致大量的线程阻塞和唤醒，从而降低系统的性能。

相对于悲观锁，乐观锁是一种乐观的锁机制，它假设在并发访问时不会发生冲突，因此不会对共享资源进行加锁。

乐观锁的典型应用是通过使用版本号或时间戳来实现。

在使用乐观锁时，当一个线程要更新共享资源时，它会先读取该资源的版本号或时间戳，然后进行计算和比较，如果发现其他线程已经修改了该资源，则放弃更新并进行重试。

乐观锁的原理是通过版本号或时间戳来标记共享资源的状态，当一个线程要更新共享资源时，它会先读取该资源的状态，并在更新之前进行比较，如果发现其他线程已经修改了该资源，则放弃更新并进行重试。

这种机制可以减少锁的使用，从而提高系统的并发性能。

乐观锁的优点是在并发量较低的情况下，由于不需要频繁地进行加锁和释放锁操作，可以提高系统的性能。

然而，乐观锁的缺点是在并发量较高的情况下，由于需要进行重试操作，会增加系统的开销。

悲观锁和乐观锁各有其适用的场景。

悲观锁适用于并发量较高，且对数据一致性要求较高的场景。

Oracle的悲观锁和乐观锁为了得到最大的性能，一般数据库都有并发机制，不过带来的问题就是数据访问的冲突。

为了解决这个问题，大多数数据库用的方法就是数据的锁定。

数据的锁定分为两种方法，第一种叫做悲观锁，第二种叫做乐观锁。

什么叫悲观锁呢，悲观锁顾名思义，就是对数据的冲突采取一种悲观的态度，也就是说假设数据肯定会冲突，所以在数据开始读取的时候就把数据锁定住。

而乐观锁就是认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让用户返回错误的信息，让用户决定如何去做。

先从悲观锁开始说。

在SqlServer等其余很多数据库中，数据的锁定通常采用页级锁的方式，也就是说对一张表内的数据是一种串行化的更新插入机制，在任何时间同一张表只会插1条数据，别的想插入的数据要等到这一条数据插完以后才能依次插入。

带来的后果就是性能的降低，在多用户并发访问的时候，当对一张表进行频繁操作时，会发现响应效率很低，数据库经常处于一种假死状态。

而Oracle用的是行级锁，只是对想锁定的数据才进行锁定，其余的数据不相干，所以在对Oracle表中并发插数据的时候，基本上不会有任何影响。

注：对于悲观锁是针对并发的可能性比较大，而一般在我们的应用中用乐观锁足以。

Oracle的悲观锁需要利用一条现有的连接，分成两种方式，从SQL语句的区别来看，就是一种是for update，一种是for update nowait的形式。

比如我们看一个例子。

首先建立测试用的数据库表。

CREATE TABLE TEST(ID,NAME,LOCATION,VALUE,CONSTRAINT test_pk PRIMARYKEY(ID))AS SELECT deptno, dname, loc, 1 FROM scott.dept这里我们利用了Oracle的Sample的scott用户的表，把数据copy到我们的test表中。

读写锁原理
读写锁是一种用于并发编程的同步机制，它允许多个线程同时读取共享资源，但只允许单个线程写入共享资源。

读写锁的基本原理是，当有读操作时，多个线程可以同时获得读锁，但当有写操作时，任何线程都无法获得读锁或写锁，直到写操作完成。

读写锁的实现方式主要有两种：悲观锁和乐观锁。

1. 悲观锁：
悲观锁的思想是，认为写操作可能经常发生，所以读操作需要获取独占锁。

在读操作时，其他线程无法获取写锁，从而保证了数据的一致性。

只有在所有的读操作完成后，才允许写操作执行。

悲观锁的实现会引入较大的开销，因为每次读操作都需要获取锁，使得多个线程无法并行读取共享资源。

2. 乐观锁：
乐观锁的思想是，认为读操作是安全的，因此允许多个线程同时读取共享资源。

乐观锁并不会阻塞读操作，只有在写操作要执行时，才会验证是否有其他线程进行并发写操作。

乐观锁可以提高读操作的并发性能，但在写操作时需要进行额外的验证。

这通常通过使用版本号或时间戳等机制来实现，以确保数据的一致性。

读写锁可以提高多线程并发读取共享资源的效率，尤其在读操作远远多于写操作时，能够更好地利用系统资源。

但需注意，过多的写操作可能会导致读操作长时间等待，可能引起线程饥饿问题，需要合理调度和权衡。

操作系统中的锁的分类操作系统中的锁分为两⼤类：悲观锁和乐观锁。

1. 悲观锁悲观锁，Pessimistic Lock，即这种锁的“想法”很悲观——⽅法执⾏如果不加锁就会出事，所以操作必须上锁，⼀个⼀个的来。

其中重量级锁、⾃旋锁和⾃适应⾃旋锁属于悲观锁。

1.1 重量级锁当进⼊⼀个同步、线程安全的⽅法时，需要先获得该⽅法的锁，⽽退出这个⽅法时，则需要释放锁。

如果线程A获取不到该锁，则意味着该⽅法有别的线程在执⾏，这时线程A会马上进⼊阻塞状态，直到持有锁的线程释放锁，才会从阻塞状态被唤醒，再尝试去获取该⽅法的锁。

重量级锁的特点是：获取不到锁，马上进⼊阻塞状态由于重量级锁的特点，导致了它的效率有时候会很慢。

试想，当线程A发现锁被占⽤，⽴即进⼊阻塞状态，之后的0.0001秒，这个锁便被释放了，那么它⼜会从阻塞状态进⼊运⾏状态。

我们都知道，线程从运⾏状态进⼊阻塞状态，需要保存线程的执⾏状态、上下⽂等数据，以及设计到⽤户态到内核态的转换，⾮常耗时，同样从阻塞状态到运⾏状态也是⼀样的道理。

因此重量级锁这个马上进⼊阻塞状态的特点，往往会耗费很多的时间在线程的状态转换中。

1.2 ⾃旋锁⾃旋锁是在重量级锁的基础上，做出了⼀些改进，它在线程判断⽅法有别的线程执⾏之后，不会⽴马进⼊阻塞状态，⽽是等待⼀段时间，也就是在⼀段固定的循环时间内，看看这个锁有没有被释放。

如果⼀直没有被释放，线程才会进⼊阻塞状态。

⾃旋锁的特点是：获取不到锁，等⼀段固定时间，再进⼊阻塞状态1.3⾃适应⾃旋锁⾃适应⾃旋锁是在⾃旋锁的基础上，对⼀段固定时间作出了⼀些调整：不需要⼈为去指定这⼀段固定时间究竟是多久，⽽是根据线程最近获得锁的状态来调整循环次数，尽量去减少等待时间，从⽽减少CPU的消耗。

2. 乐观锁乐观锁，Optimistic Lock，即这种锁的“想法”很乐观——⽅法执⾏不⽤加锁，要是出现了冲突再想办法去解决。

不加锁，就应该⽤其他的⽅法去控制⽅法的同步和线程安全，也就是CAS机制。