内存悲观锁是什么概念

郑全

首先，需要明确一点：“内存悲观锁”并不是一个在计算机科学或数据库领域有严格、通用定义的独立术语。 它通常是在讨论数据库并发控制机制（特别是锁机制）时，用来描述一种特定锁的行为特征或实现方式。

我们可以从两个层面来理解它：

1. 核心含义：一种“悲观”的锁策略，作用于“内存”数据结构

这其实是“悲观锁”和“内存锁”两个概念的结合。

• 悲观锁：这是一种并发控制思想。它“悲观”地认为，数据在并发访问时非常可能发生冲突（例如，两个事务同时修改同一行数据）。因此，在访问数据之前，就预先获取锁，将数据“锁住”，确保在自己操作期间，其他事务无法修改，从而避免冲突。操作完成后才释放锁。它的核心是“先锁后访问”。

  
  
  • 对比乐观锁：乐观锁认为冲突概率很低，因此先直接修改数据，在提交时再检查是否有冲突（例如通过版本号）。如果有冲突，则回滚事务。它的核心是“先访问，提交时检查冲突”。
    

• 内存锁：指这个锁的元信息（例如：哪个事务锁定了哪条记录、锁的类型是读锁还是写锁等）是维护在数据库服务器的内存中的，而不是持久化到磁盘上。这意味着锁的获取和释放速度非常快，但一旦数据库服务崩溃或重启，所有的锁信息都会丢失。

  
  

所以，“内存悲观锁”可以理解为：一种采用悲观策略（先加锁再操作）、并且其锁信息只保存在内存中的锁机制。

2. 在数据库中的具体语境（以MySQL/InnoDB为例）

在实际数据库系统中，最典型的“内存悲观锁”例子就是 InnoDB存储引擎的行级锁。

• 悲观：InnoDB默认使用行级锁来实现事务隔离。当执行UPDATE、DELETE或SELECT ... FOR UPDATE语句时，InnoDB会自动为涉及的行加上排他锁（X锁）或共享锁（S锁）。这就是典型的“悲观”策略——在修改前先锁定。
• 内存：InnoDB维护了一个称为 锁管理器 的结构，它使用一个哈希表来存储所有的锁信息（锁对象、事务ID、锁模式等）。这个哈希表完全位于内存中。这就是“内存”部分的体现。
  

因此，在MySQL DBA或开发者的日常交流中，如果说“内存悲观锁”，他们很可能指的就是InnoDB这套基于内存哈希表的行级锁机制。

关键特性与影响

理解了它的含义后，我们可以总结其关键特性和影响：

• 高性能：由于锁操作（检查、获取、释放）都在内存中完成，速度极快，这是实现高并发事务处理的基础。
• 锁开销：每个锁都需要在内存中占用空间（哈希表条目）。如果系统有极大量的并发行锁（例如，全表扫描时对每行都加锁），可能导致内存消耗过大。
• 无持久性：锁信息不持久化。数据库崩溃重启后，锁自然消失。这通常不是问题，因为崩溃恢复过程会通过日志（Redo Log/Undo Log）来保证数据的一致性，并自动处理中断的事务（提交或回滚）。
• 死锁检测：InnoDB的锁管理器支持死锁检测。检测算法也是在内存中运行的，会主动发现死锁环并回滚代价最小的事务来解除死锁。
  

与“表级锁”或“意向锁”的区别

• 表级锁（如MyISAM的锁）：锁的粒度是整个表，并发性能差。虽然也可以说是“悲观”的，但通常不特别强调“内存”，因为其实现相对简单。
• 意向锁：是InnoDB中一种表级锁，但它与行锁共存。它的作用是“表明一个事务即将对表中的某些行加锁”。意向锁也是内存悲观锁体系的一部分，它解决了行锁与表锁之间的冲突检查问题。
  

总结

你可以把“内存悲观锁”看作一个描述性术语，它精准地概括了像InnoDB行锁这样的现代数据库锁机制的核心特点：

• 策略上：是悲观的（先锁后用）。
• 实现上：是内存的（锁信息存于内存哈希表，高效但易失）。
• 目的上：是为了实现高并发、高一致性的事务处理。
  

当你在技术讨论中听到这个词时，基本可以将其等同于 “数据库内存中的行级悲观锁机制”。