前阵子技术群里有人问常见的锁到底怎么分类结果回答五花八门有人报互斥锁、读写锁有人直接把数据库的行锁表锁拍上来还有人反问“你是说Win11锁屏壁纸不更新那个锁吗”十来个人聊了半天最后谁也没给出一个能直接拿去用的答案。这个场景其实很典型——锁这个概念散落在并发编程、数据库、分布式系统、操作系统、移动端刷机甚至办公软件里每个领域的人都只熟悉自己那一亩三分地串不起来。做开发和维护线上系统这十年我越来越觉得“锁”是计算机体系里最绕、也最容易被低估的概念。它无处不在CPU指令级的自旋锁、JVM里的synchronized、MySQL的Record Lock、Redis里的分布式锁再到你电脑锁屏、Excel保护单元格、手机解锁BootLoader本质都是同一个思想——通过某种机制保证资源访问的唯一性、安全性和合法性。这篇文章就把散落各处的常见锁分类串起来按领域拆开讲再带上排查思路和面试题速记。不管你是准备跳槽面试、正在查线上死锁还是单纯想搞懂身边这些“锁”应该都能捞到点有用的。1. 一张图看懂“锁”的本质1.1 锁的三个基本问题我排查各种锁问题久了发现无论什么锁先回答三个问题思路就清晰了锁保护的是什么资源谁有机会持有这个锁什么条件下释放这三个问题能覆盖从门锁到分布式锁的几乎所有场景。拿家里的门锁举例保护的是房间空间持有者是拿着钥匙的人释放条件是钥匙正确转动锁芯。换到数据库行锁保护的是那一条记录持有者是当前事务释放条件是事务提交或回滚。再看Windows锁屏保护的是你的桌面会话持有者是登录用户释放条件是输入正确的密码或PIN。是不是同一套逻辑这三要素看着简单但很多线上故障都是因为其中一个要素没设计清楚。比如Redis分布式锁如果忘了加过期时间那就是“释放条件”缺失线程挂了锁永远不会释放MySQL里事务忘了提交就是“持有者”迟迟不释放后面所有更新排队等。所以学锁分类先把这个心智模型建好比死记概念有用得多。1.2 从机械锁到并发锁锁的两条分类线索分类方式有很多种我觉得最实用的是按领域和按策略两个维度切。按领域分常见的有物理锁门锁、车锁、并发编程锁互斥锁、读写锁、自旋锁、数据库锁行锁、表锁、间隙锁、分布式锁Redis分布式锁、ZooKeeper锁、操作系统会话锁Windows锁屏、Ubuntu锁屏、固件硬件锁手机BL锁、SD卡锁、办公文件锁Excel保护、压缩包密码。按策略分常见的有悲观锁与乐观锁、阻塞锁与非阻塞锁、公平锁与非公平锁、可重入锁与不可重入锁。这些策略并不是某个领域专属而是可以横切到所有领域。比如悲观锁既可以是数据库的SELECT ... FOR UPDATE也可以是并发编程里直接加mutex乐观锁既可以是版本号机制也可以是Redis Lua脚本里的条件判断。后面的章节我就按领域展开在每个领域里再用策略维度细化这样既能系统化理解面试时也能对答如流。2. 并发编程里的锁从互斥锁到事件锁2.1 互斥锁、读写锁、自旋锁三类最基础的锁并发编程里的锁核心目标是防止多个线程同时操作共享资源导致数据错乱。最基本的互斥锁Mutex我就不多废话了同一时刻只允许一个线程进入临界区就像公司里只有一个会议室谁申请到谁用用完释放。读写锁ReadWriteLock是互斥锁的优化版核心规则是“读读共享、写写互斥、读写互斥”。适合读多写少的场景比如配置中心、路由表、商品详情缓存。如果写操作频繁到和读操作差不多读写锁反而可能比普通互斥锁还慢因为要维护读计数和写等待两个状态。选型的时候先用数据说话别只看它听起来高级。自旋锁SpinLock就比较特别了它拿不到锁的时候不进入睡眠而是在原地循环检测锁状态直到获取成功。好处是避免了线程切换开销坏处是白白烧CPU。临界区极短、多核环境下用得很爽比如内核里保护某个寄存器的读写但如果临界区里干了耗时操作那别的线程全在空转CPU直接被拉满。我见过一次线上事故就是有人在自旋锁保护的代码里写了日志刷新结果8核CPU全部打满。2.2 可重入锁为什么同一个线程还能再拿同一把锁可重入锁是容易被忽略但极其重要的概念。简单说同一个线程可以重复获取同一把锁每获取一次计数加一每释放一次计数减一计数归零才算真正释放。之所以要这么设计是因为很多场景下一个线程在执行加锁代码时内部可能通过方法调用再次进入同一个临界区。C里有std::recursive_mutexJava里synchronized和ReentrantLock都是可重入的。不可重入的锁会有什么问题你自己写一个简单的mutex类没有重入计数然后在一个加锁方法里调用另一个加锁方法就会自己把自己锁死。Java面试常问synchronized和ReentrantLock的区别其中一大关键就在可重入性和中断响应上。ReentrantLock还支持公平锁、尝试非阻塞获取锁tryLock、超时获取这些synchronized都没有。实践里如果只是简单临界区synchronized足够需要超时控制或者公平调度的时候再换ReentrantLock。2.3 System.out.print到底有没有锁这问题看起来刁钻其实很有意思。System.out是一个PrintStream对象它的print和println方法内部是synchronized修饰的所以多线程同时调用时单行输出不会出现字符交错——这是有锁的。但要注意这个锁只能保证一次方法调用的原子性如果你写出这样的代码System.out.print(user id: ); System.out.println(user.getId()); System.out.print(user name: ); System.out.println(user.getName());两个线程交叉打印时虽然每行内部不会乱但多行之间完全可能互相穿插日志就变成“user id: 1001 user name: zhangsan”这种错乱结果。所以“有锁”和“输出整体有序”是两码事。生产中不建议靠System.out打日志真要打也要自己加一个独立的互斥锁或者直接用日志框架把整条日志拼好再一次性输出。2.4 游戏开发中的事件锁锁的是队列不是逻辑游戏开发里常说的“事件锁”其实不是某种新锁类型而是事件驱动模型里配合使用的同步机制。典型场景是逻辑线程产生玩家操作事件渲染线程消费事件修复两个线程不能直接访问同一个数据结构的问题。我见过一个比较常见的写法用互斥锁保护一个事件队列生产者push消费者pop事件本身不会因为线程竞争而错乱。但要注意的是锁只保护队列的存取不保护事件处理逻辑。你不能在持锁状态下执行复杂技能逻辑否则渲染线程卡顿玩家立刻能感受到。更进阶的做法是双缓冲队列线程A写入pending队列业务线程通过swap拿到当前批次数据这样锁的粒度就非常小了。游戏引擎里的“帧事件锁”本质上也是这个套路——在一个帧周期内收集事件帧末统一派发尽量避免频繁锁竞争。3. 数据库锁MySQL面试必问的分类体系3.1 乐观锁与悲观锁两种并发控制思想的对比数据库锁是面试重灾区每次聊到MySQL锁分类逃不掉乐观锁和悲观锁。悲观锁的思维方式是“很可能有人改数据先锁住再说”。在MySQL里就是SELECT ... FOR UPDATE事务A查询商品库存时直接锁行事务B的更新只能等A提交。这种方式写冲突频繁时很安全但并发低、容易阻塞。乐观锁的思路刚好相反“不锁数据提交时再检查有没有被别人改过”。实现方式通常是版本号或时间戳更新语句带上条件判断-- 悲观锁示例 BEGIN; SELECT stock FROM product WHERE id 1 FOR UPDATE; UPDATE product SET stock stock - 1 WHERE id 1; COMMIT; -- 乐观锁示例 UPDATE product SET stock stock - 1, version version 1 WHERE id 1 AND version 5; -- 如果影响行数为0说明version已被其他事务修改需要重试乐观锁适合读多写少的场景比如论坛点赞、用户资料更新。代码里如果发现更新行数为0不要闷头继续要返回失败或者重新读版本号再试。另外提醒一句乐观锁不是完全没有锁成本它只是在冲突发生时才付出代价而且这个代价通常是一次重试如果业务写冲突很频繁反而应该用悲观锁。3.2 InnoDB的行锁、表锁、间隙锁与MVCCMySQL InnoDB引擎的锁按粒度可以分为行锁、表锁和页锁但实际面试更关注行锁和表锁。行锁只锁被访问的索引记录并发粒度小表锁锁整张表粒度大但开销小常见于MyISAM或某些DDL操作。InnoDB行锁里还有细分Record Lock锁单条记录Gap Lock锁一个区间但不管记录本身Next-Key Lock是Record Lock和Gap Lock二合一锁住左开右闭区间。InnoDB默认的隔离级别是Repeatable Read会用Next-Key Lock来防止幻读。比如你执行SELECT * FROM orders WHERE amount 100 FOR UPDATE其他事务要想在amount 50到150之间插入一条记录会被间隙锁挡住。MVCC是另一个需要理解的概念。InnoDB通过undo log维护多版本数据链配合ReadView实现不加锁的快照读。普通SELECT不加锁走MVCCSELECT ... FOR UPDATE、UPDATE、DELETE是当前读需要加锁。所以MySQL的隔离性是“MVCC 锁”一起撑起来的。这里一定要提一个排查中老遇到的问题为什么一个看起来只更新一行数据的SQL最后把整张表堵住了最常见的原因是更新条件没走索引。InnoDB是索引组织表更新时如果走全表扫描它会在扫过的每一行上都需要加锁实际锁范围接近整张表。热搜词里的“mysql锁表”十有八九就是这个场景。3.3 线上锁表排查与MySQL锁相关面试题沉淀线上遇到锁表先用这几条SQL看现场-- 查看当前所有事务 SELECT * FROM information_schema.innodb_trx\G; -- 查看锁等待关系 SELECT * FROM information_schema.innodb_lock_waits; -- 查看具体锁信息InnoDB旧版8.0也可以用performance_schema.data_locks SELECT * FROM information_schema.innodb_locks;排查思路很固定先看innodb_trx里有没有事务一直处于LOCK WAIT或长时间RUNNING拿到trx_mysql_thread_id之后去SHOW PROCESSLIST里看它执行的SQL和状态然后顺着innodb_lock_waits的blocking_trx_id找阻塞源头。如果死者是一个长事务但已经不影响任何业务可以KILL对应线程如果还有业务在跑就要评估一下杀掉事务的代价。面试题方面MySQL锁的分类是个送分题但要答得有条理按粒度分表锁、行锁、页锁按思想分乐观锁、悲观锁按操作方式分共享锁S锁、排他锁X锁InnoDB还有Record Lock、Gap Lock、Next-Key Lock。死锁四个必要条件也得背下来互斥、请求与保持、不可剥夺、循环等待。排查死锁用SHOW ENGINE INNODB STATUS找到LATEST DETECTED DEADLOCK段落里面会直接打印两条事务的SQL。4. 分布式锁Redis方案、落地场景与高频面试题4.1 为什么单机锁不够用很多人刚学完synchronized转头遇到分布式环境就懵了明明代码里加了锁为什么库存还是超卖原因很简单synchronized锁的是JVM进程内的对象监视器微服务部署了多个实例每个实例各有各的JVM锁根本不在同一个空间里。分布式锁要解决的问题就是跨进程、跨节点的互斥。典型使用场景包括多实例定时任务抢单同一个任务只允许一个节点执行、库存扣减、分布式事务中的幂等控制、多机缓存刷新。面试官问“分布式锁使用场景”能说出这三四个例子就够有说服力了。4.2 Redis分布式锁的落地步骤与Lua脚本Redis实现分布式锁最基础也最常用的方案是SET key value NX PX 过期时间。NX保证只有当key不存在时才能设置成功PX设置锁的自动过期时间防止持有者宕机后锁永远不释放。但释放锁的时候不能直接DEL因为你可能把别人刚获取的锁给删了。正确姿势是先用GET拿到锁里的value和自己当初写入的唯一标识比较一样才删。为了把这步做成原子操作要用Lua脚本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这个脚本我在生产环境一直用配合每个请求生成的UUID作为value可以避免误删锁。加锁时也一样不要分成两步走先SETNX再EXPIRE要一条命令搞定否则加锁成功下一秒进程崩溃锁就变成永不过期的死锁了。如果是Java项目直接用Redisson会更省心它内部有个“看门狗”机制默认锁租期30秒业务没执行完就自动续期执行完释放最大程度避免“锁过期了业务还在跑”的尴尬。但需要明确一点自研Redis分布式锁最容易踩的坑就是过期时间设置不当。设太短长任务锁提前释放另一台机器冲进来设太长持有者宕机后要等很久才能恢复。所以要么根据业务预估时间设置要么就走Redisson这种自动续期的方案。4.3 分布式锁的经典坑与三种实现方案对比Redis单节点分布式锁有一个理论上的漏洞如果Redis主节点宕机切换新的主节点可能没有刚才的锁数据另一个线程还是能成功加锁。为了解决这个问题Redis官方提出了Redlock算法——向多个独立Redis节点依次加锁超过一半成功才算获取成功。但Redlock本身也有争议很多资深工程师认为它在极端场景下依然无法保证绝对安全还需要考虑时钟跳跃等问题。实际业务中我建议的选型逻辑是这样的实现方案优点缺点适用场景Redis SETNX Lua性能高、实现简单主从切换可能丢锁需要自己处理续期大部分业务场景缓存类、抢购、任务调度数据库唯一键/悲观锁可靠、不需要额外组件性能差事务时间影响吞吐低频、对一致性要求极高的内部系统ZooKeeper临时顺序节点一致性最好无过期续期问题引入ZK组件运维成本高对一致性要求极高的分布式协调场景面试问“分布式锁怎么实现”你把上面三种答出来再说清楚各自取舍基本就是高分了。另外要记住一个思想能用幂等设计和数据库唯一约束解决的事压根别引入分布式锁。锁是最后手段不是第一选择。5. 操作系统与终端锁锁屏的一切实用玩法5.1 Windows锁屏聚焦壁纸、自动锁屏与控制台操作系统的锁屏本质是保护正在登录的桌面会话。按下WinL立刻锁屏配置好的话唤醒后需要重新输入密码。很多普通用户问的锁屏问题其实都是设置层面的小坑。Windows聚焦锁屏壁纸不自动更换常见原因有三个聚焦服务被禁用、聚焦缓存损坏、组策略里被关闭。排查时先去“服务”里看ContentDeliveryManager是否启用接着删除缓存文件位置在C:\Users\用户名\AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\LocalState\Assets重新启动聚焦。如果还是不行检查是否被公司域策略接管个人电脑一般没那么复杂。Win10/Win11“自动锁屏时间设置后被系统覆盖”也是一个经典现象。原因是Windows的锁屏触发有三层电源计划里的“唤醒后需要登录”、屏幕保护里的“在恢复时显示登录屏幕”、以及“动态锁”。三处设置如果互相冲突会出现你明明设置了10分钟自动锁屏结果没生效。建议在三处统一设置优先改屏幕保护选项因为Win11的已知问题比较多。企业电脑还会被组策略的“不显示锁屏界面”覆盖这时本地设置修改了也没用需要管理员处理。热搜里还有一个挺有意思的提问“重启后能不能先进桌面把开机启动软件全部跑完再锁屏”技术上可行用计划任务设置延迟锁屏时间或者在启动脚本里执行完再触发锁屏。但我要提醒一句开机启动软件全部跑完再锁屏这段时间系统处于无保护状态。如果是公共电脑或办公电脑这是一个安全隐患别为了自己方便降低安全底线。5.2 Ubuntu与WindTerm的锁屏设置Ubuntu桌面环境GNOME关闭自动锁屏和锁屏密码图形界面走“设置-隐私-屏幕锁定”把“自动锁定屏幕”和“挂起后锁定屏幕”关掉。命令行可以用gsettingsgsettings set org.gnome.desktop.screensaver lock-enabled false gsettings set org.gnome.desktop.screensaver idle-activation-enabled falseWindTerm是我常用的一款开源终端工具很多同学问“WindTerm锁屏密码”怎么设置。其实在WindTerm的“Settings”里的“Security”下有“Lock Screen”选项可以设置工具启动或手动锁定时需要输入全局密码用来防止别人在你离开时直接看到终端内容这属于终端会话级别的锁。这些设置仅针对个人电脑有意义。办公环境里域策略或安全合规通常强制要求锁屏私自关闭不被允许也别这么做。说到底锁屏是最后一道物理防线睡觉前电脑开在那谁都能翻你的聊天记录那才叫真的社死。6. 移动端与硬件锁从BL锁到门禁锁控板6.1 BL锁刷机路上那道门槛手机圈的BL锁全称是BootLoader锁控制的是设备引导加载程序能不能被第三方替换。小米、华为、一加这些厂商普遍默认锁定BootLoader防止用户刷入非官方系统后破坏安全启动链路。很多热搜词比如“小米10s秒解bl锁”“红米note13pro解bl锁”“小米6强解bl锁”都是围绕这个话题。正规解锁流程其实很固定开发者选项里绑定小米账号并申请解锁资格等待系统审核然后用官方Mi Unlock工具解锁。整个过程不复杂但需要时间小米一般要求账号使用时长和社区等级达标再解锁。“秒解”“强解”这两个词背后通常是用漏洞或非官方手段绕过验证风险很高常见后果包括官方解锁资格被封、设备变砖、指纹支付等安全功能失效。我不推荐任何人用这类方式。如果你确实需要刷机老老实实走官方解锁流程花几天时间换设备稳定比贪快然后翻车划算多了。6.2 账户锁与设备找回安全账户锁在手机上通常指FRPFactory Reset Protection或厂商云账户锁也就是说即使有人把手机恢复出厂设置也会被要求输入原机主的账号密码才能继续激活。这是最有效的防盗机制之一。所以“华为强制解除原主id锁”“刷账户锁华为”这类搜索既不合法也不符合社会公序良俗。如果是自己的手机正常路径是找回账号密码如果账号真找不回来就提供购买凭证、发票、盒子上的IMEI号联系官方客服走人工解绑。我处理过几次帮朋友解锁的情况凭证齐全官方客服一般当天就能处理没必要走灰色渠道。账户锁之所以存在是因为手机已经变成个人信息和移动支付的中心。试想一下如果任何捡到手机的人都能通过恢复出厂设置绕过账户锁那手机丢失等于银行卡丢失。这个锁千万别想着“破解”它是在保护我们自己。6.3 SD卡锁、共享充电宝和门禁锁控板SD卡出现“内部寄存器锁死”其实不常见多数是误读。SD卡卡体侧边有一个写保护开关拨到LOCK位置后只能读不能写这是物理写保护锁。如果开关没拨错还是提示写保护通常问题是劣质读卡器把状态引脚识别错误了换一个读卡器或者换一台电脑一般能解决。真正寄存器锁死的案例往往和卡损坏有关备份数据后尝试格式化不行就只能换卡。共享充电宝卡住不能取原因基本是订单未结束或者卡扣机械故障。网上能搜到各种“解锁教程”但我不建议去撬、砸共享充电宝属于租赁物破坏会触发赔偿而且卡扣里面是电磁锁强行拽会损坏机器。正确操作是联系客服确认订单状态让后台释放锁或者按归还按钮重新触发一次机械复位。门禁锁控板协议是另一个硬核话题主要在弱电工程和智能家居领域。锁控板控制的通常是电磁锁、电插锁或电机锁核心是收到合法开门信号后释放锁舌。工程上做门禁系统要关注通信协议加密、防重放攻击、断电自动开锁还是自动闭锁。很多项目为了省成本用明文协议传输用户ID别人抓包后就能模拟开门指令安全形同虚设这点踩过坑的人应该都懂。7. 办公与文件锁Excel保护、压缩包加密与文件占用7.1 用EasyExcel导出时如何只锁定部分单元格Excel里的“保护工作表”功能本质是一个全表锁。默认情况下所有单元格的Locked属性都为true一旦执行ProtectSheet整个工作表都不可编辑。很多Java后端用EasyExcel导出模板时会遇到一个问题导出后工作表被完全锁死但希望A列能填数据B列只能看。原因就是没提前设置可编辑区域的Locked属性。正确做法是在写导出时给那些允许编辑的列设置独立单元格样式并把setLocked(false)再对Sheet执行保护。示意代码如下WriteCellStyle contentStyle new WriteCellStyle(); contentStyle.setLocked(false); // 注册到你希望可编辑的列 // 最后执行 sheet.protectSheet(密码);注意一个细节如果整表保护了再想“允许用户编辑部分区域”还要考虑sheet级别能不能正常插入行。常规模板导出场景前后列样式都要统一设置否则同一列有10行可以编辑、后面10行又锁住用户会一头雾水。实践里建议先用Excel手动做一份模板验证再用EasyExcel去复现。7.2 压缩包加密与文件被占用的“隐形锁”压缩包“被锁定不能修改”有两种情况。一种是加了密码ZIP或RAR的密码本质是内容加密锁不知道密码几乎无法正常解压修改。网上说的暴力破解对强密码没有意义不如好好回忆密码或者检查浏览器保存的密码记录、笔记软件里的备注。另一种是文件权限问题右键属性-安全给当前用户分配完全控制权限就能解决。还有一种非常常见的“文件被锁”是操作系统层面的文件占用锁。Windows下删除某个Excel或图片时提示“文件已在另一个程序中打开”其实是有进程持有了该文件句柄。打开任务管理器进入“性能-打开资源监视器-CPU-搜索句柄”输入文件名就能找到占用进程。Linux下更简单lsof /path/to/file fuser -k /path/to/file这类文件锁和并发编程里的互斥锁本质同源——都是“当前资源被某持有者占用其他访问者需要等待”。所以排查思路完全可以复用前面说的三要素法。8. 问题速查与面试题简答8.1 高频问题定位速查表现象可能原因排查与应对MySQL锁表业务SQL全部卡住长事务未提交、间隙锁互等查innodb_trx定位阻塞事务评估后kill或优化SQLRedis分布式锁提前释放过期时间设短业务未完成使用Redisson看门狗续期或设置合理过期时间Redis锁误删别人锁释放时直接DEL用唯一value Lua脚本先比对后删除Windows锁屏壁纸不更新聚焦服务禁用、缓存损坏启服务、清缓存、检查组策略Win11自动锁屏设置失效屏保、电源、组策略冲突统一三处设置优先改屏保恢复时锁定Excel保护工作表后部分区域无法编辑可编辑区域没取消Locked导出时给可编辑列设置setLocked(false)文件提示被占用无法删除进程持有文件句柄Windows资源监视器找句柄Linux用lsof手机BL锁无法走第三方解锁官方安全限制走官方申请解锁流程不要强解SD卡写保护无法解除物理开关或读卡器故障拨动开关、更换读卡器再考虑格式化8.2 面试题简答速记MySQL锁分类简答按粒度表锁、行锁、页锁按思想乐观锁、悲观锁按兼容性共享锁、排他锁InnoDB特有Record Lock、Gap Lock、Next-Key Lock乐观锁为什么不需要数据库锁因为它不直接锁资源而是用版本号或时间戳做CAS检测提交时发现冲突再重试或报错。这里要注意优秀的乐观锁方案在并发高峰下也会出现大量重试所以要在业务层设个重试上限。分布式锁三种方案对比是送分题前面表格就是标准答案。再加一句Redlock的争议理论上有时钟跳跃问题工程上单节点Redis配合过期时间、Lua脚本和看门狗其实已经能覆盖绝大多数业务。死锁排查一句话版本用SHOW ENGINE INNODB STATUS看死锁日志分布式场景用Redisson等客户端自带的Redlock看门狗如果是自研锁重点检查获取锁的嵌套顺序是否一致。8.3 实战避坑经验我在一线写代码和救火的经验总结成三条。第一条所有“锁”问题先按三要素拆解再动手别一上来就翻代码。第二条能用数据库唯一键或幂等设计解决的问题别引入分布式锁能用单机读写锁解决的问题别上分布式锁。每加一层锁就多一层不确定性和故障点。第三条锁的释放逻辑一定要写在finally或Lua脚本里避免任何异常路径导致锁残留。我平时排查线上超时类故障时还养成一个习惯先在问题描述里把“锁的资源、持有者、释放条件”写下来很多时候写着写着病因自己就冒出来了。比如“库存扣减超时”这个问题写完三要素就发现不是SQL慢而是同一个用户的多笔请求在分布式锁上串行排队锁的粒度太粗了。把锁从用户维度改成SKU维度后吞吐量直接翻倍——锁的分类和粒度设计才是真正的性能分水岭。最后再分享一个小技巧遇到不熟悉领域的锁名词先别急着搜“是什么”而是搜“在这个场景里锁住了什么、谁持有、怎么释放”。用这个框架去看MySQL的Next-Key Lock、Redisson的看门狗、手机账户锁、门禁锁控板会发现它们只是在不同介质上重复着同一套保护逻辑。理解到这个层面所谓“常见锁分类”就不再是需要背的资料而是一个随时可以调用的工程思维。