悲观锁和乐观锁并不是某个具体的“锁”而是一种并发编程的基本概念，是根据看待并发同步的角度。乐观锁和悲观锁最早出现在数据库的设计当中，后来逐渐被Java的并发包所引入。
悲观锁
悲观锁认为对于同一个数据的并发操作一定是会发生修改的，采取加锁的形式，悲观地认为，不加锁的并发操作一定会出问题。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中Synchronized和ReentrantLock等独占锁就是悲观锁思想实现的。
乐观锁
乐观锁正好和悲观锁相反，它获取数据的时候，并不担心数据被修改，每次获取数据的时候也不会加锁，只是在更新数据的时候，通过判断现有的数据是否和原数据一致来判断数据是否被其他线程操作，如果没被其他线程修改则进行数据更新，如果被其他线程修改则不进行数据更新。Lock是乐观锁的典型实现案例。
典型案例
(1)悲观锁：synchronized关键字和Lock接口相关类
Java中悲观锁的实现包括synchronized关键字和Lock相关类等，我们以Lock接口为例，例如Lock的实现类ReentrantLock，类中的lock()等方法就是执行加锁，而unlock()方法是执行解锁。处理资源之前必须要先加锁并拿到锁，等到处理完了之后再解开锁，这就是非常典型的悲观锁思想。
(2)乐观锁：原子类
乐观锁的典型案例就是原子类，例如AtomicInteger在更新数据时，就使用了乐观锁的思想，多个线程可以同时操作同一个原子变量。
(3)大喜大悲：数据库
数据库中同时拥有悲观锁和乐观锁的思想。例如，我们如果在MySQL选择selectforupdate语句，那就是悲观锁，在提交之前不允许第三方来修改该数据，这当然会造成一定的性能损耗，在高并发的情况下是不可取的。相反，我们可以利用一个版本version字段在数据库中实现乐观锁。在获取及修改数据时都不需要加锁，但是我们在获取完数据并计算完毕，准备更新数据时，会检查版本号和获取数据时的版本号是否一致，如果一致就直接更新，如果不一致，说明计算期间已经有其他线程修改过这个数据了，那我就可以选择重新获取数据，重新计算，然后再次尝试更新数据。
数据库的悲观锁示例：
select*fromaccountwherename="Erica"forupdate
这条sql语句锁定了account表中所有符合检索条件(name="Erica")的记录。本次事务提交之前(事务提交时会释放事务过程中的锁)，外界无法修改这些记录.。
数据库的乐观锁示例：
假设取出数据的时候version为1
UPDATEstudent
SET
name=‘小李’,
version=2WHEREid=ANDversion=1
CAS介绍
Java中的乐观锁大部分都是通过CAS(CompareAndSwap，比较并交换)操作实现的，CAS是一个多线程同步的原子指令，CAS操作包含三个重要的信息，即内存位置、预期原值和新值。如果内存位置的值和预期的原值相等的话，那么就可以把该位置的值更新为新值，否则不做任何修改。
补充说明:虽然ReentrantLock也是通过CAS实现的,但是是悲观锁。
缺点:ABA问题.
CAS可能会造成ABA的问题，ABA问题指的是，线程拿到了最初的预期原值A，然而在将要进行CAS的时候，被其他线程抢占了执行权，把此值从A变成了B，然后其他线程又把此值从B变成A，然而此时的A值已经并非原来的A值了，但最初的线程并不知道这个情况，在它进行CAS的时候，就会误认为它从来没有被修改过，只对比了预期原值为A就进行了修改，这就造成了ABA的问题。
以警匪剧为例，假如某人把装了W现金的箱子放在了家里，几分钟之后要拿它去赎人，然而在趁他不注意的时候，进来了一个小偷，用空箱子换走了装满钱的箱子，当某人进来之后看到箱子还是一模一样的，他会以为这就是原来的箱子，就拿着它去赎人了，这种情况肯定有问题，因为箱子已经是空的了，这就是ABA的问题。
JDK在1.5时提供了AtomicStampedReference类也可以解决ABA的问题，此类维护了一个“版本号”Stamp，每次在比较时不止比较当前值还比较版本号，这样就解决了ABA的问题。
综合分析实例:
如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时(如更改用户帐户余额)，如果采用悲观锁机制，也就意味着整个操作过程中(从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间)，数据库记录始终处于加锁状态，可见，如果面对几百上千个并发，这样的情况将导致怎样的后果。乐观锁机制在一定程度上解决了这个问题。
乐观锁，大多是基于数据版本(version)记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。同时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号等于数据库表当前版本号，则予以更新，否则认为是过期数据。
对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个version字段，当前值为1；而当前帐户余额字段(balance)为$。
1操作员A此时将其读出(version=1)，并从其帐户余额中扣除$50($-$50)。
2在操作员A操作的过程中，操作员B也读入此用户信息(version=1)，并从其帐户余额中扣除$20($-$20)。
3操作员A完成了修改工作，将version=1的数据连同帐户扣除后余额(balance=$50)，提交至数据库更新，此时由于提交数据版本等于数据库记录当前版本，数据被更新，同时数据库记录version更新为2(setversion=version+1whereversion=1)。
4操作员B完成了数据录入操作，也将version=1的数据试图向数据库提交(balance=$80)，但此时比对数据库记录版本时发现，操作员B提交的数据版本号为1，数据库记录当前版本也为2，不满足“提交版本必须等于记录当前版本才能执行更新“的乐观锁策略，因此，操作员B的提交被驳回。
这样，就避免了操作员B用基于version=1的旧数据修改的结果覆盖操作员A的操作结果的可能。
悲观锁乐观锁优缺点:
优点:
悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制避免了长事务中的数据库加锁开销，大大提升了大并发量下的系统整体性能表现。
缺点：
需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整(如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开)。
使用场景
有一种说法认为，悲观锁由于它的操作比较重量级，不能多个线程并行执行，而且还会有上下文切换等动作，所以悲观锁的性能不如乐观锁好，应该尽量避免用悲观锁，这种说法是不正确的。因为虽然悲观锁确实会让得不到锁的线程阻塞，但是这种开销是固定的。悲观锁的原始开销确实要高于乐观锁，但是特点是一劳永逸，就算一直拿不到锁，也不会对开销造成额外的影响。反观乐观锁虽然一开始的开销比悲观锁小，但是如果一直拿不到锁，或者并发量大，竞争激烈，导致不停重试，那么消耗的资源也会越来越多，甚至开销会超过悲观锁。所以，同样是悲观锁，在不同的场景下，效果可能完全不同。
(1)悲观锁适合用于并发写入多、临界区代码复杂、竞争激烈等场景，这种场景下悲观锁可以避免大量的无用的反复尝试等消耗。
(2)乐观锁适用于大部分是读取，少部分是修改的场景，也适合虽然读写都很多，但是并发并不激烈的场景。在这些场景下，乐观锁不加锁的特点能让性能大幅提高。