乐观锁和悲观锁是什么？在性能上有什么不同？

一、乐观锁

定义：乐观锁是另一种并发控制策略。它假设在数据处理过程中，大多数情况下不会有其他事务同时修改相同的数据。所以在操作数据时不会立即加锁，而是在更新数据时检查数据是否被其他事务修改过。如果数据没有被修改，就正常更新；如果发现数据已经被修改，则根据业务逻辑决定是重试更新还是抛出异常。

实现方式：一种常见的实现方式是使用版本号（Version）或者时间戳（Timestamp）。在数据表中添加一个版本号字段，每次更新数据时，同时更新版本号。当一个事务要更新数据时，它会先读取数据的版本号，在更新时检查版本号是否与之前读取的一致。如果一致，说明数据没有被其他事务修改，可以正常更新；如果不一致，说明数据已经被其他事务更新过了，此时可以根据业务需求进行处理。

适用场景：乐观锁适用于读多写少的场景，因为它减少了加锁和解锁的开销，提高了系统的并发性能。例如，在内容管理系统中对文章的浏览（读操作）远远多于对文章的修改（写操作），使用乐观锁可以在保证数据一致性的同时，提高系统的整体性能。另外，在一些分布式系统或者高并发的互联网应用中，由于悲观锁可能会导致长时间的等待和性能问题，乐观锁也是一种很好的选择。

二、悲观锁

定义：悲观锁是一种并发控制的机制。它假定在数据处理过程中，很可能会有其他事务同时访问和修改相同的数据，所以在操作数据之前就先对数据进行加锁。在锁被释放之前，其他事务不能对被锁定的数据进行读写操作，从而保证了数据的一致性和完整性。

实现方式：在关系型数据库中，悲观锁通常使用数据库提供的锁机制来实现。例如，在 SQL 中，可以使用SELECT... FOR UPDATE语句（在 MySQL 等数据库中）来对查询的数据行进行加锁。这意味着在事务提交或回滚之前，其他事务不能对这些行进行修改。

适用场景：悲观锁适用于数据冲突概率比较高的场景。比如在金融系统中对账户余额的修改、库存管理系统中对商品库存数量的扣减等操作。这些操作要求数据的准确性很高，而且并发修改可能会导致严重的问题，所以使用悲观锁可以有效地避免并发冲突。

三、在性能上的区别

1、悲观锁性能特点

加锁开销：悲观锁在事务开始时就对数据进行加锁，这会带来一定的性能开销。在高并发环境下，如果大量事务都在等待获取锁，就会造成线程阻塞，增加系统的响应时间。例如，在一个电商平台的秒杀活动中，如果对商品库存的修改操作使用悲观锁，大量并发请求同时尝试获取锁来扣减库存，会导致许多请求处于等待状态，系统性能会受到严重影响。

锁的持续时间：悲观锁的持有时间相对较长，从事务开始获取锁，一直到事务提交或回滚才释放锁。在这段时间内，其他事务无法访问被锁定的数据，这可能会导致数据库的并发性能下降。例如，在一个复杂的金融交易系统中，一个事务可能需要对多个相关的账户进行操作，使用悲观锁时，整个操作过程中这些账户数据都被锁定，其他事务只能等待，使得系统整体的吞吐量降低。

数据库资源占用：悲观锁会占用较多的数据库资源，因为它需要数据库系统维护锁的状态信息。在数据库服务器繁忙时，过多的锁可能会导致资源耗尽，影响其他正常的数据库操作。例如，在一个大型的企业资源规划（ERP）系统中，如果频繁使用悲观锁，可能会使数据库的内存、CPU 等资源被大量消耗在锁的管理上，从而影响系统的稳定性和性能。

2、乐观锁性能特点

无锁阶段的高效性：乐观锁在读取数据时不需要加锁，所以在数据读取阶段可以实现很高的并发性能。多个事务可以同时读取相同的数据，不会相互阻塞。这对于读多写少的应用场景非常有利，例如，在一个新闻资讯网站中，用户对新闻内容的浏览（读操作）远多于对新闻内容的编辑（写操作），使用乐观锁可以让大量的浏览请求同时进行，提高系统的响应速度。

更新阶段的有条件检查：在更新数据时，乐观锁通过检查版本号或时间戳等条件来判断数据是否被修改。如果数据未被修改，更新操作可以快速完成。虽然在数据被修改的情况下可能需要重试或进行额外的处理，但这种情况在读多写少的场景中发生的概率相对较低。例如，在一个简单的博客系统中，多个用户同时对一篇博客文章进行评论（写操作）的情况较少，当偶尔出现评论同时提交的情况时，通过乐观锁的版本控制机制可以快速处理，不会对系统性能造成太大的影响。

减少锁的资源占用：由于乐观锁不需要像悲观锁那样维护锁的状态信息，所以它对数据库资源的占用相对较少。这使得数据库系统能够将更多的资源用于实际的数据处理和查询操作，提高了系统的整体效率。例如，在一个分布式的数据存储系统中，使用乐观锁可以避免因锁的管理而带来的网络开销和资源消耗，使得系统在处理大量数据时能够更加高效地运行。

了解更多数据仓库与数据集成关干货内容请关注>>>FineDataLink官网

免费试用、获取更多信息，点击了解更多>>>体验FDL功能