1 乐观锁（Optimistic Locking ）
乐观锁（Optimistic Locking ）相对于悲观锁而言，乐观锁机制采取更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性 。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（version）记录机制实现 。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 version字段来实现。读取数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本与数据库表对应记录的当前版本进行比对，如果提交的数据版本号等于数据库表当前版本号，则予以更新，否则认为是过期数据。
读完上面这一段，我们应该已经知道乐观锁的意思了，也就是说大部分乐观锁其实就是加了版本号version字段，根据这个字段实现的乐观锁机制，那么还有什么方式可以实现乐观锁呢，聪明的你肯定已经想到了CAS，对的，CAS（compare and swap）比较并修改，CAS需要三个参数，内存地址V，旧的预期值A和新值B，只有当V的值等于A时，才会将V的值改为B。
目前乐观锁的实现方式上我们知道了有版本号机制和CAS机制，那么这两种机制会带来什么问题呢？
首先就是CAS会有ABA问题的出现，什么是ABA问题呢？ABA问题就是张三放桌子100块钱，中间李四拿100块钱用了，用完之后又放了100块到桌子上，等张三回来，发现还是100块，就以为还是他的100块，其实，这个100块钱已经发生了变化，这就是经典的ABA问题。这种问题怎么解决了，也就是上面我们所说的版本号机制，加入版本号（版本号必须是顺序递增的）之后，判断版本，只有当版本号相同时才更改值，然后版本号+1；在更新值的时候如果发现版本号不匹配也就不再进行更改了，这样就可以避免ABA问题了
但是CAS自旋会一直尝试获取锁，如果一直获取不到锁的情况下，此时CPU就会爆表，带来非常大的开销。所以综上所述，乐观锁比较适合读多写少的场景，这样冲突就真的很少发生，也就降低了加锁的成本；但是如果经常产生冲突，应用不断的尝试加锁，反而会影响系统性能，此时就不如使用悲观锁了！
2 悲观锁
悲观锁就是：不管做啥，都假设是冲突的场景，场景：不管谁来获取资源，都要先拿到锁，这也就是通俗点讲悲观锁的概念了，下面还是按照惯例看下正统说法：
悲观锁，正如其名，具有强烈的独占和排他性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。 那么，既然如此的话悲观锁又都有什么优缺点呢，首先优点就是，保证多线程下顺序读写，防止脏数据产生，缺点就是并发场景下性能显著下降。
所以与乐观锁相对应的悲观锁的适用场景就是读少写多 的场景，这种场景下，冲突多，所以悲观锁很适合。目前我了解的悲观锁实现方式有Lock和Synchronized，其次就是MySQL的for update语句：MySQL中查询语句，select ... for update 此时就是对数据加了排它锁，排它锁也是一种悲观锁。所以我们对该数据的访问会对该数据进行加锁，后面来的对该数据的操作都会排队等侯，直到拿到锁。
除了MySql中查询语句使用的悲观锁，工作中还有好多地方用到了乐观锁悲观锁，比如说，java.util.concurrent.Atomic下的原子变量是使用CAS机制，Elasticsearch是使用了version的乐观锁机制。