乐观锁

JPQL(JPA的查询语句) 最基本的JPQL的格式 只能写java的类名和属性名 SELECT o[o.property,o.property*] FROM Entity o [WHERE conditions] [GROUP BY conditions] [HAVING conditions] [ORDER BY o.property[ASC|DESC]] JPQL本质是JPA通过antlr-2.7.7.jar翻译成sql并且封装执行的。 JPQL书写规则 JPA的查询语言,类似于sql 1.里面不能出现表名,列名,只能出现java的类名,属性名，区分大小写 2.出现的sql关键字是一样的意思,不区分大小写 3.不能写select * 要写select 别名 集合的操作（size） 集合在JPA中经常出现，对集合的操作（size） sql里面没有size(最终换成sql的count查询) 注意：使用size就是操作集合，那么我们就必需配置员工与部分双向的关系，让部门也可以找到对应的员工 查询出有员工的部门【size】//必须配置双向一对多:部门和员工 JOIN JPA中的JOIN和LEFT JOIN（使用SQL/JPQL对比） sql:select * 表1 join 表2 on 条件 jpql: 1. 不写 on 子句 2. 模型 模型的别名 join 写前面模型别名

使用场景举例：我们以mysql的存储引擎 InnoDB为例(如果不采用锁机制) 因此在上述情况中我们可以采用悲观锁 在上面的情况中，商品被查询出来，有一个处理订单的过程，我们可以使用悲观锁机制，当我们查出这个goods信息后，就把当前的数据锁定起来，直到我们修改完毕再解锁，所以在我们处理该goods的时候，就避免了第三者来修改 下面来简单演示一下吧 for update ; 注意：这里有个问题在是使用悲观锁的时候，如果第一个事务没有commit我们是不能进行该相同数据的写操作的，但是读操作分两种情况，在事务中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一笔数据时会等待其它事务结束后才执行，一般SELECT ... 则不受此影响。 拿上面的实例来说，当我执行select status from t_goods where id=1 for update;后。我在另外的事务中如果再次执行select status from t_goods where id=1 for update;则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行select status from t_goods where id=1;则能正常查询出数据，不会受第一个事务的影响。 补充：MySQL select…for

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/Mrs_chens/article/details/90690812 乐观锁/悲观锁 前言 今天博主将为大家分享乐观还是悲观，你选择哪一种锁？（乐观锁/悲观锁），不喜勿喷，如有异议欢迎讨论！ 锁的分类 公平锁/非公平锁 可重入锁 独享锁/共享锁 互斥锁/读写锁 乐观锁/悲观锁 分段锁 偏向锁/轻量级锁/重量级锁 自旋锁 乐观锁(Optimistic Locking) 所谓的乐观，实际上是相对于悲观锁来说，百度百科中的解释。 乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销， 特别是对长事务而言，这样的开销往往无法承受。相对悲观锁而言，乐观锁更倾向于开发运用。 上面的内容都是乐观锁在百度百科中的解释，我们需要去找一个场景来进行解释的。 我们就从最经典的案例“老王取钱”来说 1图中有三个存在，分别表示老王，和老王账户，还有一个就是版本信息。版本信息默认是1，这时候老王要买点东西，结果发现钱不太够，那就去银行取点钱去呗，果断的来了银行 然后告诉柜员，取5000块钱，然后柜员就会从他的账户余额里面扣除5000，就是-5000 这时候告诉柜员要取钱，柜员就回去读卡了，发现版本信息是1， 然后就在这时候

顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。 两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。 乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题，可能会出现脏读的情况。

Ŀ¼ Java 按照锁的实现分为乐观锁和悲观锁，乐观锁和悲观锁并不是一种真实存在的锁，而是一种设计思想，乐观锁和悲观锁对于理解 Java 多线程和数据库来说至关重要，那么本篇文章就来详细探讨一下这两种锁的概念以及实现方式。 悲观锁 是一种悲观思想，它总认为最坏的情况可能会出现，它认为数据很可能会被其他人所修改，所以悲观锁在持有数据的时候总会把 资源 或者 数据 锁住，这样其他线程想要请求这个资源的时候就会阻塞，直到等到悲观锁把资源释放为止。传统的关系型数据库里边就用到了很多这种锁机制， 比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 悲观锁的实现往往依靠数据库本身的锁功能实现。 Java 中的 Synchronized 和 ReentrantLock 等独占锁(排他锁)也是一种悲观锁思想的实现，因为 Synchronzied 和 ReetrantLock 不管是否持有资源，它都会尝试去加锁，生怕自己心爱的宝贝被别人拿走。 乐观锁的思想与悲观锁的思想相反，它总认为资源和数据不会被别人所修改，所以读取不会上锁，但是乐观锁在进行写入操作的时候会判断当前数据是否被修改过(具体如何判断我们下面再说)。乐观锁的实现方案一般来说有两种： 版本号机制 和 CAS实现 。乐观锁多适用于多度的应用类型，这样可以提高吞吐量。 在Java中 java.util.concurrent.atomic

悲观锁 ，它们认为当使用数据的时候一定有其它线程来修改，所以在获取数据的时候就会加锁，确保不会被其它线程修改。 synchronized 代码块： public synchronized void update() { //同步资源 } 代码块： public void update() { Lock lock = new ReentrantLock(); lock.lock(); try { //同步资源 } finally { lock.unlock(); } } ，它认为使用数据的时候不会有别的线程来修改数据，所以不会加锁。只要在自身要进行update操作的时候，才会去判断之前的数据是否被别的线程修改了。如果没有被修改则会修改成功，相反则会修改不成功。这里最典型的是java.util.concurrent并发包中的递增操作就通过CAS自旋实现的。 CAS 代码块： public class TestLock { AtomicInteger atomicInteger = new AtomicInteger(0); public int add() { return atomicInteger.incrementAndGet(); } } 总结 ABA问题(JDK1.5之后已有解决方案)： CAS需要在操作值的时候检查内存值是否发生变化，没有发生变化才会更新内存值

2018年10月24日 周三 19:40 乐观锁与悲观锁.rtf 2018年7月29日 周日 18:55 乐观锁与悲观锁 概念 : 这里抛开数据库来谈乐观锁和悲观锁,扯上数据库总会觉得和Java离得很远. 悲观锁 : 一段执行逻辑加上悲观锁,不同线程同时执行时,只能有一个线程执行,其他的线程在入口处等待,直到锁被释放. 乐观锁 : 一段执行逻辑加上乐观锁,不同线程同时执行时,可以同时进入执行,在最后更新数据的时候要检查这些数据是否被其他线程修改了(版本和执行初是否相同),没有修改则进行更新,否则放弃本次操作. 从解释上可以看出,悲观锁具有 很强的独占性 ,也是最安全的.而乐观锁 很开放 , 效率高 , 安全性比悲观锁低,因为在乐观锁检查数据版本一致性时也可能被其他线程修改数据. 从下面的例子中可以看出来这里说的安全差别. 乐观锁例子 : /** * 乐观锁 * * 场景:有一个对象value,需要被两个线程调用,由于是共享数据,存在脏数据的问题 * 悲观锁可以利用synchronized实现,这里不提. * 现在用乐观锁来解决这个脏数据问题 * * @author lxz * */ public class OptimisticLock { public static int value = 0; // 多线程同时调用的操作对象 /** * A线程要执行的方法 */ public

乐观锁介绍： 乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。那么我们如何实现乐观锁呢，一般来说有以下2种方式： 1.使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。用下面的一张图来说明： 如上图所示，如果更新操作顺序执行，则数据的版本（version）依次递增，不会产生冲突。但是如果发生有不同的业务操作对同一版本的数据进行修改，那么，先提交的操作（图中B）会把数据version更新为2，当A在B之后提交更新时发现数据的version已经被修改了，那么A的更新操作会失败。 2.乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓

乐观锁与悲观锁 北京这两天天气不好，时晴时阴，最近有有点累，所以在家里休息了两天，看了一下乐观锁与悲观锁，虽然没有茅塞顿开，但是也有点收获。 先想一想为什么要使用锁？ 在用户访问你的网站时，同一时间可能会有多个用户更新相同的记录，这时候他们同时访问数据库，这就会产生冲突，这就是著名的并发（高并发）。 高并发会产生什么后果呢？ 丢失更新 ：一个事务的更新覆盖了其他事务的更新，这就是所谓的更新丢失。列如管理员A把数据库中的2改成了6，管理员B把值从6又改成了2，这个时候，用户A就丢失了他的更新。 脏读 ：当一个事务读取其他完成一半事务的记录时，就会发生脏读，列如：管理员AB读取数据库时看到的都是6 ，用户B把值改为2，用户A读取到的值仍是6 . 超卖： 如果maysql中没有锁的存在的话，他会产生超卖的情况，你库存只有十个，但是一百个用户同时去访问你的数据库，这时候就会产生超卖。可能你就会卖出12件商品。 解决高并发的方法： 悲观锁： 假设会发生并发冲突，屏蔽一切可能违反数据完整性的操作, 认为会多人操作同一条数据,因此操作数据时直接把数据锁住，直到一个人操作完成后才会释放锁；上锁期间其他人不能修改数据。 乐观锁： 假设不会发生并发冲突，只在操作时检查是否违反数据完整性，如果别人修改了数据则放弃操作，否则执行操作。而乐观锁不能解决脏读，因为他在操作时才会去检查，而脏读是在操作中产生的。

为什么需要锁 在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。 典型的冲突有： 丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改为2，用户B把值从2改为6，则用户A丢失了他的更新。 脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改为2，用户A读到的值仍为6。 乐观锁和悲观锁如何处理并发问题 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。 乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。那么我们如何实现乐观锁呢，一般来说有以下2种方式： 　　1.使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候