Java锁，指的是应用中使用的锁；应用中在处理线程安全的问题时，常常使用synchronized 或者ReentrantLock等锁来保证线程安全。
乐观锁本质上并不属于锁，它只是一种冲突检测机制，但被这样称呼的时间比较长，就被称为乐观锁。乐观锁允许并发的获取内容进行读写，但在提交的时候会进行并发控制。比如 A, B 同时获得了一个数据，而且都要对其进行处理，A 先提交了该条数据，B 后来也要提交该条数据，这时候乐观锁的策略检测到两者发生了冲突，便会拒绝 B 提交的内容，并抛出冲突，交给 B 进行处理。 乐观锁的处理策略，通常是版本控制，或者是时间戳控制（本质与前者相同）。对数据进行一个版本的记录，每次提交后都标上版本号。当提交时的版本号小于等于当前版本号，则抛出异常，待解决冲突后重新执行。 笔者看到这里，就想到了一个很常见的乐观锁——即笔者项目中使用的 SVN 源代码版本控制器。我和同事一起编辑同一个 java 文件，是被允许的，但如果我们两个人提交的内容有冲突，则 SVN 会提示我们冲突，并让我们决定如何解决冲突（采用谁的内容，或者如何合并内容），然后再提交（再提交就是将冲突抛出后再解决的过程）。
乐观锁和悲观锁是两种思想，用于解决并发场景下的数据竞争问题。它们的使用是非常广泛的，不局限于某种编程语言或数据库。乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。
所以要是别人再问你乐观锁和悲观锁是什么，你千万别说它是一种具体的锁，它只是一种锁的设计思想，他可以有很多具体的实现类
乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。
当我们想要在业务中引入“乐观锁”时，应该要思考清楚它的概念，为了更加形象的理解“乐观锁”，我们可以先看一下认识下悲观锁。
页锁就是在 页的粒度 上进行锁定，锁定的数据资源比行锁要多，因为一个页中可以有多个行记录。当我 们使用页锁的时候，会出现数据浪费的现象，但这样的浪费最多也就是一个页上的数据行。页锁的开销 介于表锁和行锁之间，会出现死锁。锁定粒度介于表锁和行锁之间，并发度一般。
乐观锁（ Optimistic Lock ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
首先我们理解下两种不同思路的锁，乐观锁和悲观锁。 这两种锁机制，是在多用户环境并发控制的两种所机制。下面看百度百科对乐观锁和悲观锁两种锁机制的定义：
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
之前的一篇文章中，关于RC 和 RR 隔离级别的问题，在文章尾部建议在大部分场景下，为了高并发和性能的需求，我们都建议使用RC的数据库隔离级别。这里被读者指出，这样的建议是有问题的，基于这个事情，读者也给我一些建议。这里我也进行了一些研究。
在 Java 中，我们可以使用乐观锁和悲观锁来保证数据的一致性和并发性。下面是对乐观锁和悲观锁的介绍以及它们的实现方式。
悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
首先，悲观锁与乐观锁是根据操作时是否锁住资源来判别的。悲观锁获取到锁时，必须要锁住资源；乐观锁则不会。一开始两线程争抢锁：
如何确保一个方法，或者一块代码在高并发情况下，同一时间只能被一个线程执行，单体应用可以使用并发处理相关的 API 进行控制，但单体应用架构演变为分布式微服务架构后，跨进程的实例部署，显然就没办法通过应用层锁的机制来控制并发了。
对于我们开发的网站，如果网站的访问量非常大的话，那么我们就需要考虑相关的并发访问问题了。而并发问题是绝大部分的程序员头疼的问题，
背景 前几天有人在群里问，“正交测试法”在工作中用不用的到。借此说一下我的看法。 正文 在测试工作中，多数系统都需要设计我称之为“竞争条件测试”的用例。何为“竞争条件测试”，即多个进程或线程操作统一资
在我们开发的项目中，大量的请求，或者同时的操作，很容易导致系统在业务上发生并发的问题。通常讲到并发，解决方案无非就是前端限制重复提交，后台进行悲观锁或者乐观锁限制。
对于我们开发的网站，如果网站的访问量非常大的话，那么我们就需要考虑相关的并发访问问题了。而并发问题是绝大部分的程序员头疼的问题，但话又说回来了，既然逃避不掉，那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧。
回去之后搜了一下解决方法，其中的一种解决方法就是通过给数据库加锁，也可以防止库存超卖的情况
在当今的软件开发领域，数据库操作是不可或缺的一部分。然而，随着并发操作的增加，如何正确地处理并发问题是每个开发者都需要面对的挑战。本文将深入探讨JPA（Java Persistence API）和Hibernate这两种ORM（对象关系映射）工具中的乐观锁和悲观锁的使用及其适用场景。
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。在Java中，synchronized从偏向锁、轻量级锁到重量级锁，全是悲观锁。JDK提供的Lock实现类全是悲观锁； 手动加悲观锁 读锁：LOCK tables test_db read，释放锁：UNLOCK TABLES; 写锁：LOCK tables test_db WRITE，释放锁：UNLOCK TABLES; 读锁与写锁 如果要更新数据，那么加锁的时候就直接加写锁，一个线程持有写锁的时候别的线程无论读还是写都需要等待； 如果是读取数据仅为了前端展示，那么加锁时就明确地加一个读锁，其他线程如果也要加读锁，不需要等待，可以直接获取（读锁计数器+1）； 虽然读写锁感觉与乐观锁有点像，但是读写锁是悲观锁策略。因为读写锁并没有在更新前判断值有没有被修改过，而是在加锁前决定应该用读锁还是写锁； ●优点：可以完全保证数据的独占性和正确性，因为每次请求都会先对数据进行加锁， 然后进行数据操作，最后再解锁，而加锁释放锁的过程会造成消耗，所以性能不高; ●缺点：因为每次请求都会先对数据进行加锁， 然后进行数据操作，最后再解锁，而加锁释放锁的过程会造成消耗，所以性能不高;
线程安全是多线程场景下才会产生的问题，线程安全可以理解为某个方法或者实例对象在多线程环境中使用而不会出现问题。
乐观锁和悲观锁并不是一种真实存在的锁，而是一种设计思想，乐观锁和悲观锁对于理解后端多线程和数据库来说至关重要，那么本篇文章就来详细探讨一下这两种锁的概念以及实现方式。
这几年O2O火爆，10个创业公司里就有9个是O2O的电商，相信支付抢购什么的以前听起来高大上的东西现在很多码农都会需要自己去实现。
有些业务逻辑在执行过程中要求对数据进行排他性的访问，于是需要通过一些机制保证在此过程中数据被锁住不会被外界修改，这就是所谓的锁机制。 Hibernate支持悲观锁和乐观锁两种锁机制。悲观锁，顾名思义悲观的认为在数据处理过程中极有可能存在修改数据的并发事务（包括本系统的其他事务或来自外部系统的事务），于是将处理的数据设置为锁定状态。悲观锁必须依赖数据库本身的锁机制才能真正保证数据访问的排他性，关于数据库的锁机制和事务隔离级别在《Java面试题大全（上）》中已经讨论过了。乐观锁，顾名思义，对并发事务持乐观态度（认为对数据的并发操作不会经常性的发生），通过更加宽松的锁机制来解决由于悲观锁排他性的数据访问对系统性能造成的严重影响。最常见的乐观锁是通过数据版本标识来实现的，读取数据时获得数据的版本号，更新数据时将此版本号加1，然后和数据库表对应记录的当前版本号进行比较，如果提交的数据版本号大于数据库中此记录的当前版本号则更新数据，否则认为是过期数据无法更新。Hibernate中通过Session的get()和load()方法从数据库中加载对象时可以通过参数指定使用悲观锁；而乐观锁可以通过给实体类加整型的版本字段再通过XML或@Version注解进行配置。
Java 按照锁的实现分为乐观锁和悲观锁，乐观锁和悲观锁并不是一种真实存在的锁，而是一种设计思想，乐观锁和悲观锁对于理解 Java 多线程和数据库来说至关重要，那么本篇文章就来详细探讨一下这两种锁的概念以及实现方式。
在Java并发场景中，会涉及到各种各样的锁如公平锁，乐观锁，悲观锁等等，这篇文章介绍各种锁的分类：
悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。 悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。 Java synchronized 就属于悲观锁的一种实现，每次线程要修改数据时都先获得锁，保证同一时刻只有一个线程能操作数据，其他线程则会被block。
在上一篇文章中，介绍了什么是锁，以及锁的使用场景，本文继续给大家继续做深入的介绍，介绍JAVA为我们提供的不同种类的锁。
多线程并发访问同一个资源问题，假如线程A获取变量之后修改变量值，线程C在此时也获取变量值并且修改，两个线程同时并发处理一个变量，就会导致并发问题。
在上一节中，我们给大家介绍了什么是锁，以及锁的使用场景，我相信大家对锁的定义，以及锁的重要性都有了比较清晰的认识。在这一节中，我们会给大家继续做深入的介绍，介绍JAVA为我们提供的不同种类的锁。
首先环境是：Spring Boot 2.1.0 + data-jpa + mysql + lombok
悲观锁是一种对数据修改持有悲观态度的并发控制方式。它总是假设最坏的情况，每次读取数据时都默认其他线程会更改数据，因此需要加锁操作。
当要更新一条记录的时候，希望这条记录没有被别人更新，也就是说实现线程安全的数据更新 乐观锁实现方式：
作为一个Java开发多年的人来说，肯定多多少少熟悉一些锁，或者听过一些锁。今天就来做一个锁相关总结。
乐观锁和悲观锁问题，是出现频率比较高的面试题。本文将由浅入深，逐步介绍它们的基本概念、实现方式(含实例)、适用场景，以及可能遇到的面试官追问，希望能够帮助你打动面试官。
在实验环境MySQL5.6、存储引擎：InnoDB中，揭开“锁”的神秘面纱，捋一捋我对这几个概念的想法
一般可以分为两类，一个是悲观锁，一个是乐观锁，悲观锁一般就是我们通常说的数据库锁机制，乐观锁一般是指用户自己实现的一种锁机制。
提到锁，大家肯定想到的是sychronized关键字。是用它可以解决一切并发问题，但是，对于系统吞吐量要求更高的话，我们这提供几个小技巧。帮助大家减小锁颗粒度，提高并发能力。
读写锁允许多个线程同时读共享变量，适用于读多写少。 那在读多写少的场景中，有没有更快的技术方案呢？还真有，JDK在1.8提供StampedLock，其性能比读写锁还好。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
