乐观锁

目录 Java 锁之乐观锁和悲观锁 悲观锁 乐观锁 两种锁的使用场景 乐观锁的实现方式 版本号机制 CAS 算法 乐观锁的缺点 ABA 问题 循环开销大 CAS与synchronized的使用情景 Java 锁之乐观锁和悲观锁 Java 按照锁的实现分为乐观锁和悲观锁，乐观锁和悲观锁并不是一种真实存在的锁，而是一种设计思想，乐观锁和悲观锁对于理解 Java 多线程和数据库来说至关重要，那么本篇文章就来详细探讨一下这两种锁的概念以及实现方式。 悲观锁 悲观锁 是一种悲观思想，它总认为最坏的情况可能会出现，它认为数据很可能会被其他人所修改，所以悲观锁在持有数据的时候总会把 资源 或者 数据 锁住，这样其他线程想要请求这个资源的时候就会阻塞，直到等到悲观锁把资源释放为止。传统的关系型数据库里边就用到了很多这种锁机制， 比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 悲观锁的实现往往依靠数据库本身的锁功能实现。 Java 中的 Synchronized 和 ReentrantLock 等独占锁(排他锁)也是一种悲观锁思想的实现，因为 Synchronzied 和 ReetrantLock 不管是否持有资源，它都会尝试去加锁，生怕自己心爱的宝贝被别人拿走。 乐观锁 乐观锁的思想与悲观锁的思想相反，它总认为资源和数据不会被别人所修改，所以读取不会上锁

最近面试,面试官提到了悲观锁和乐观锁,感觉回答的不是很好,特此总结记录. 简单来说,悲观锁就是凡事都认为会出现最坏的情形,而乐观锁就是认为凡事都以最好的情形发展,对应一个消极,一个积极. 悲观锁 具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态.(摘自百度百科) 传统关系型数据库里面的很多锁就是采用的这种机制,例如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。java里面的synchronize和ReentrantLock等重入锁就是采用的这种机制; 乐观锁 总是认为不会产生并发问题，每次去取数据的时候总认为不会有其他线程对数据进行修改，因此不会上锁，但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS操作实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。 乐观锁的两种实现方式: 1.版本号机制 即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现

乐观锁 每次获取数据的时候，都不会担心数据被修改，所以每次获取数据的时候都不会进行加锁，但是在更新数据的时候需要判断该数据是否被别人修改过。如果数据被其他线程修改，则不进行数据更新，如果数据没有被其他线程修改，则进行数据更新。由于数据没有进行加锁，期间该数据可以被其他线程进行读写操作。一般使用version方式和CAS操作方式。 Version方式： 一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。 核心SQL代码：update table set x=x+1, version=version+1 where id=#{id} and version=#{version}; 　　 CAS操作方式： 即compare and swap 或者 compare and set，涉及到三个操作数，数据所在的内存值，预期值，新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。 乐观锁使用场景 比较适合 读取操作比较频繁的场景 ，如果出现大量的写入操作

mybatis plus 乐观锁 ***************************************** 相关注解 @Documented @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD}) public @interface Version { } 支持的数据类型： int 、 Integer、long、Long、Date、Timestamp、LocalDateTime 支持的方法： updataById(id)，update(Entity entity,Wrapper wrapper) 操作示例： pojo @ApiModel(value="Student对象", description="") public class Student extends Model<Student> { private static final long serialVersionUID=1L; @TableId(value = "id", type = IdType.AUTO) private Integer id; private String name; private Integer age; @Version private Integer version; 。。。。 } ************

synchronized / Lock / CAS synchronized和Lock实现的同步锁机制，都属于悲观锁，而CAS属于 乐观锁 悲观锁在高并发的场景下，激烈的锁竞争会造成线程阻塞，而大量阻塞线程会导致系统的上下文切换，增加系统的性能开销 乐观锁 乐观锁：在操作共享资源时，总是抱着乐观的态度进行，认为自己能够完成操作 但实际上，当多个线程同时操作一个共享资源时，只有一个线程会成功，失败的线程不会被挂起，仅仅只是返回 乐观锁相比于悲观锁来说，不会带来死锁、饥饿等活性故障问题，线程间的相互影响也远远比悲观锁要小 乐观锁没有因竞争而造成的系统上下文切换，所以在性能上更胜一筹 实现原理 CAS是实现乐观锁的核心算法，包含3个参数：V（需要更新的变量），E（预期值）、N（最新值） 只有V等于E时，V才会被设置为N 如果V不等于E了，说明其它线程已经更新了V，此时该线程不做操作，返回V的真实值 CAS实现原子操作 AtomicInteger是基于CAS实现的一个线程安全的整型类，Unsafe调用CPU底层指令实现原子操作 复制 12345678 // java.util.concurrent.atomic.AtomicIntegerpublic final int getAndIncrement() { return unsafe.getAndAddInt(this,

转帖：谢谢分享 锁（ locking ） 业务逻辑的实现过程中，往往需要保证数据访问的排他性。如在金融系统的日终结算处理中，我们希望针对某个 cut-off 时间点的数据进行处理，而不希望在结算进行过程中（可能是几秒种，也可能是几个小时），数据再发生变化。此时，我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓的 “锁” ，即给我们选定的目标数据上锁，使其无法被其他程序修改。Hibernate 支持两种锁机制：即通常所说的 “悲观锁（ Pessimistic Locking ）”和 “乐观锁（ Optimistic Locking ）” 。 悲观锁（ Pessimistic Locking ） 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。 一个典型的倚赖数据库的悲观锁调用： select * from account where name=”Erica” for update 这条 sql 语句锁定了 account 表中所有符合检索条件（name=

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

对于我们开发的网站，如果网站的访问量非常大的话，那么我们就需要考虑相关的并发访问问题了。而并发问题是绝大部分的程序员头疼的问题，但话又说回来了，既然逃避不掉，那我们就要想想应对措施，今天我们就一起讨论一下常见的并发和同步吧。 首先为了更好的理解并发和同步，我们需要首先明白两个重要的概念： 同步和异步 同步和异步的区别和联系 所谓同步，就是一个线程执行一个方法或函数的时候，会阻塞其它线程，其他线程要等待它执行完毕才能继续执行。 异步，就是多个线程之间没有阻塞，多个线程同时执行。 通俗一点来说，同步就是一件事一件事的做，异步就是做一件事，不影响做其他事情。 例如：吃饭和说话，只能一件一件的来，因为只有一张嘴。 但是吃饭和听音乐是异步的，可以一起进行，因为听音乐并不影响我们吃饭。 对于Java程序员来说，Synchronized最为熟悉了，如果它作用于一个类的话，那么就是一个线程访问类的方法时，其他线程就会阻塞，相反，如果没有这个关键字来修饰的话，不同线程就可以在同一时间访问同一个方法，这就是异步。 脏读和不可重复读 脏读 脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这是，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读取的这个数据是脏数据(Dirty Data)

谈到了MySQL悲观锁，但是悲观锁并不是适用于任何场景，它也有它存在的一些不足，因为 悲观锁大多数情况下依靠数据库的锁机制实现 ，以保证操作最大程度的独占性。 如果加锁的时间过长，其他用户长时间无法访问，影响了程序的并发访问性，同时这样对数据库性能开销影响也很大 ，特别是对长事务而言，这样的开销往往无法承受。所以与悲观锁相对的，我们有了乐观锁，具体参见下面介绍： 乐观锁介绍： 乐观锁（ Optimistic Locking ） 相对悲观锁而言， 乐观锁假设认为数据一般情况下不会造成冲突 ，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。那么我们如何实现乐观锁呢，一般来说有以下2种方式： 1.使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现 方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录 的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数 据。用下面的一张图来说明： 如上图所示

悲观锁(Pessimistic Lock) 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 乐观锁(Optimistic Lock) 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量， 像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。 总结： 无论是乐观锁还是悲观锁，都有各自的优缺点。当写的操作频繁时可以使用悲观锁。写操作少，读操作多时使用乐观锁，这样可以减少系统的开销。 来源： oschina 链接： https://my.oschina.net/u/2367628/blog/648581