锁：主要是为了解决共享数据并发访问的一致性、有效性问题。
悲观锁与乐观锁是两种常见的资源并发锁设计思路
1、悲观锁（Pessimistic Lock）
特点：先获取锁，再进行业务操作，即“悲观”的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。
通常所说的“一锁二查三更新”即指的是使用悲观锁。数据库上的悲观锁需要数据库本身提供支持。
2、乐观锁（Optimistic Lock）
特点：先进行业务操作，最后一步获取锁。在完成业务操作后需要实际更新数据的最后一步再去拿锁。
乐观锁在数据库上的实现完全是逻辑的，不需要数据库提供特殊的支持。
乐观锁优缺点：
优点：
从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销，大大提升了大并发量下的系统整体性能表现。
缺点：
乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，应该充分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对
外公开）。
总结：
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。
乐观锁在不发生取锁失败的情况下开销比悲观锁小，但是一旦发生失败回滚开销则比较大，因此适合用在取锁失败概率比较小的场景，可以提升系统并发性能