如何利用DBMS_LOCK在Oracle存储过程中巧妙设置锁机制以避免并发冲突？

本文共计1013个文字，预计阅读时间需要5分钟。

相关专题

DBMS_LOCK.REQUEST 为什么不能直接替代 SELECT FOR UPDATE

很多人看到 dbms_lock.request 就想用它“锁住某条记录”，但这是错的：它锁的是一个抽象的锁标识符（lock handle），不是数据库行。它不参与事务一致性控制，也不阻塞其他会话对同一行的 dml 操作。也就是说，即使你用 dbms_lock.request 成功加锁，另一个会话照样能执行 update dept_inventory set amount = ... 并提交，你的业务逻辑仍可能覆盖对方修改。

它的适用场景其实是“跨事务协调”或“非数据行级互斥”，比如：防止两个调度任务同时启动报表生成、避免多个进程重复初始化缓存表。这类操作不依赖行状态，只关心“此刻有没有别人在干同一件事”。

什么时候该用 DBMS_LOCK 而不是 SELECT FOR UPDATE

当你需要串行化的是「操作动作」本身，而不是「对某行数据的读-改-写流程」时，DBMS_LOCK 才有意义。典型例子包括：

• 定时作业中，多个实例可能同时触发同一个存储过程（如每日库存重算），需确保仅一个实例执行
• 接口服务中，前端多次点击“生成凭证”，后端要拒绝后续请求直到首请求完成
• 批量导入任务开启前，检查是否有其他导入正在运行（此时还没查具体哪条数据要改）

注意：DBMS_LOCK 的锁默认不绑定事务，必须显式调用 DBMS_LOCK.RELEASE，否则锁会一直存在，甚至跨会话残留——这是最常被忽略的坑。