乐观锁

我们通常希望避免在两个并行事务中产生如下情形： Adam的事务读取数据 X Barbara的事务读取数据 X Adam的事务修改数据 X，并将其修改为 XA Adam的事务写入数据 XA Barbara的事务修改数据 X，并将其修改为 XB Barbara的事务写入数据 XB 结果是，Adam所做的修改完全被Barbara所覆盖掉了，但是Barbara对此却毫不知晓。像这样的情况通常被称为“脏读”。显然，我们希望的结果是Adam写入 XA，而Barbara需要在写入 XB之前检查对 XA 的修改。 乐观锁的工作原理 （Optimistic Locking ） 乐观锁基于的假设是实际中冲突很少发生，即使发生，抛出一个错误也比想办法避免它们更容易接受和简单。在乐观锁中，允许一个事务正确完成，但另一个事务需要抛出异常并回滚，并且必须被重新执行或者丢弃。 我们还以Adam和Barbara为例，下面是一个使用乐观锁可能发生的情形： Adam的事务读取数据 X Barbara的事务读取数据 X Adam的事务修改数据 X，并将其修改为 XA Adam的事务写入数据 XA Barbara的事务修改数据 X，并将其修改为 XB Barbara的事务试图写入数据 XB，但是收到一个错误 Barbara需要读取数据 XA（或者重新开始一个新的事务） Barbara的事务修改数据 XA，并将其修改为

首先我们来了解一下 乐观锁与悲观锁的区别 乐观锁的思路一般是表中增加版本字段，更新时where语句中增加版本的判断，算是一种CAS（Compare And Swep）操作， 商品库存场景中number起到了版本控制（相当于version）的作用（ AND number=#{number}）。 悲观锁之所以是悲观，在于他认为本次操作会发生并发冲突，所以一开始就对商品加上锁（SELECT … FOR UPDATE）， 然后就可以安心的做判断和更新，因为这时候不会有别人更新这条商品库存。 从中我们也可以知道只要更新数据是依赖读取的数据作为基础条件的，就会有并发更新问题，需要乐观锁或者悲观锁取解决， 特别实在计数表现明显。又比如在更新数据不依赖查询的数据的就不会有问题， 例如修改用户的名称，多人同时修改，结果并不依赖于之前的用户名字，这就不会有并发更新问题。 ================================ 1. 悲观锁 顾名思义就是很悲观，每次拿数据都会认为别的线程会修改该数据，所以会给数据上锁； 这样抢到锁的线程运行，取到数据做操作， 这期间其他线程想要访问该数据时，都是阻塞block挂起状态，操作不了； 核心就是不支持多并发，是单线程操作，通过抢占时间片的方式来抢锁的使用权，把并发变成了串行。 共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。 两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。 原文: http://blog.csdn.net/hongchangfirst/article/details/26004335 作者:hongchangfirst hongchangfirst的主页: http://blog.csdn.net/hongchangfirst 转载于:https://www.cnblogs

7大服务介绍 服务名称 描述 RepositoryService Activiti 中每一个不同版本的业务流程的定义都需要使用一些定义文件，部署文件和支持数据 ( 例如 BPMN2.0 XML 文件，表单定义文件，流程定义图像文件等 )，这些文件都存储在 Activiti 内建的 Repository 中。Repository Service 提供了对 repository 的存取服务。 RuntimeService 在 Activiti 中，每当一个流程定义被启动一次之后，都会生成一个相应的流程对象实例。Runtime Service 提供了启动流程、查询流程实例、设置获取流程实例变量等功能。此外它还提供了对流程部署，流程定义和流程实例的存取服务。 TaskService 在 Activiti 中业务流程定义中的每一个执行节点被称为一个 Task，对流程中的数据存取，状态变更等操作均需要在 Task 中完成。Task Service 提供了对用户 Task 和 Form 相关的操作。它提供了运行时任务查询、领取、完成、删除以及变量设置等功能。 IdentityService Activiti 中内置了用户以及组管理的功能，必须使用这些用户和组的信息才能获取到相应的 Task。Identity Service 提供了对 Activiti 系统中的用户和组的管理功能。

一、为什么需要锁（并发控制）？ 在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。 典型的冲突有： 1.丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改为2，用户B把值从2改为6，则用户A丢失了他的更新。 2.脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改为2，用户A读到的值仍为6。 为了解决这些并发带来的问题。 我们需要引入并发控制机制。 二、 并发控制机制 锁,即给我们选定的目标数据上锁，使其无法被其他程序修改。 1.悲观锁：指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态 2.乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁不能解决脏读的问题。 三、乐观锁的实现 使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为 数据库 表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候

前言 Java提供了种类丰富的锁，每种锁因其特性的不同，在适当的场景下能够展现出非常高的效率。本文旨在对锁相关源码（本文中的源码来自JDK 8和Netty 3.10.6）、使用场景进行举例，为读者介绍主流锁的知识点，以及不同的锁的适用场景。 Java中往往是按照是否含有某一特性来定义锁，我们通过特性将锁进行分组归类，再使用对比的方式进行介绍，帮助大家更快捷的理解相关知识。下面给出本文内容的总体分类目录： 1. 乐观锁 VS 悲观锁 乐观锁与悲观锁是一种广义上的概念，体现了看待线程同步的不同角度。在Java和数据库中都有此概念对应的实际应用。 先说概念。对于同一个数据的并发操作，悲观锁认为自己在使用数据的时候一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改。Java中，synchronized关键字和Lock的实现类都是悲观锁。 而乐观锁认为自己在使用数据时不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。如果这个数据没有被更新，当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新，则根据不同的实现方式执行不同的操作（例如报错或者自动重试）。 乐观锁在Java中是通过使用无锁编程来实现，最常采用的是CAS算法，Java原子类中的递增操作就通过CAS自旋实现的。 根据从上面的概念描述我们可以发现

悲观锁： 总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。 悲观锁适用于多写场景，冲突一般较多。 乐观锁： 总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用 版本号机制和CAS算法实现 。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。 乐观锁适用于多读的应用类型，这样可以提高吞吐量。 乐观锁的缺点： 1. ABA 问题 如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 "ABA"问题。 解决：JDK 1.5 以后的 AtomicStampedReference

前段时间有人问我java中的乐观锁和悲观锁的问题，我被问愣神了，乐观锁和悲观锁我到是听说过，在数据库里面应用极广，但是java里面就好像没有听说过，后来我详细去看了下《java编程思想》，的确在java里面有乐观锁的描述。 1.什么是java中的乐观锁和悲观锁 悲观锁：悲观锁是认为肯定有其他线程来争夺资源，因此不管到底会不会发生争夺，悲观锁总是会先去锁住资源。 乐观锁：所谓的乐观锁就是当去做某个修改或其他操作的时候它认为不会有其他线程来做同样的操作（竞争），这是一种乐观的态度，通常是基于CAS原子指令来实现的。关于CAS可以参见这篇文章 java并发包的CAS操作 ，CAS通常不会将线程挂起，因此有时性能会好一些。 2. java中CAS的实现 CAS就是Compare and Swap的意思，比较并操作。很多的cpu直接支持CAS指令。CAS是项乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。 JDK1.5中引入了底层的支持，在int、long和对象的引用等类型上都公开了CAS的操作

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量， 像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。 两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。 来源： oschina 链接： https://my.oschina.net/u/567457/blog/544265

今天被人问了下乐观锁和悲观锁，突然在脑子里好模糊，但又感觉以前很熟悉的东西竟然忘得这么干净。所以恶补加记录一下。 乐观锁和悲观锁是对于数据库并发情况下产生的两个对立的概念，所以首先确认一点 并发！并发！才存在这两个概念，他们是对并发数据库操作不同的处理方式。 乐观锁：乐观的认为不会发生并发冲突，依赖新增字段（version，你可以起一个其它的名字）来检验数据的合法，举例：查询数据 后，对version+1操作，然后修改记录 where 条件 version（当前）小于传递回来的值才修改，否则放弃修改。 悲观锁：悲观的认为所有的操作都会发生并发冲突，因此只能以数据库自身的锁才能实现，对资源的强占有。举例：在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。 从上述简介：能看出，很明显的区别，可以根据自己的页面进行选择，但还有一点必须明白，悲观锁会导致性能大幅度下降。 qq技术交流群：208779755 个人公众号：海涛聊技术 来源： oschina 链接： https://my.oschina.net/u/817581/blog/1841120