DBMS_LOCK.REQUEST不能替代SELECT FOR UPDATE，因为它锁定的是抽象锁标识符而非数据行，不参与事务一致性控制，也不阻塞其他会话对同一行的DML操作。
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，否则锁会一直存在，甚至跨会话残留——这是最常被忽略的坑。
DBMS_LOCK 使用的三个硬性前提
这个包不是开箱即用的，必须满足以下条件才能调用成功：
-
GRANT EXECUTE ON DBMS_LOCK TO your_user;—— 默认不授予普通用户 - 会话需启用
ALTER SESSION SET CURRENT_SCHEMA = your_schema;或使用全限定名sys.DBMS_LOCK.REQUEST - 锁标识符（
lockhandle）必须全局唯一且长度 ≤128 字符；建议用业务含义命名，如'INVENTORY_DAILY_CALC'，别用随机数或时间戳（易冲突）
示例片段（非完整过程）：
DECLARE
l_lock_handle VARCHAR2(128);
l_ret INTEGER;
BEGIN
DBMS_LOCK.ALLOCATE_UNIQUE('INVENTORY_DAILY_CALC', l_lock_handle);
l_ret := DBMS_LOCK.REQUEST(l_lock_handle, timeout => 0); -- timeout=0 表示不等待，立即返回
IF l_ret != 0 THEN
RAISE_APPLICATION_ERROR(-20001, '另一实例正在执行，请稍后重试');
END IF;
<p>-- 执行你的业务逻辑（如 truncate+insert）</p><p>DBMS_LOCK.RELEASE(l_lock_handle); -- 必须释放！否则锁永久滞留
END;SELECT FOR UPDATE 仍是行级并发的首选方案
回到库存扣减这类典型场景：A 和 B 同时读取同一行 amount=10，B 先扣 5，A 后加 10，最终应为 15 而非 20。这种问题本质是“读-改-写中间态丢失”，只有基于行的悲观锁能闭环解决。
SELECT ... FOR UPDATE 的关键优势在于：
- 自动绑定当前事务：事务提交/回滚时锁自动释放，无需手动管理
- 阻塞真实的数据修改路径：其他会话对同一行的 UPDATE/DELETE 会被挂起，直到锁释放
- 与 Oracle 的多版本并发控制（MVCC）天然兼容，不会造成脏读或不可重复读
而 DBMS_LOCK 在这里不仅多余，还会引入额外失败点（如锁分配失败、忘记释放、超时策略混乱）。真正需要它的地方，往往和“数据行”本身无关。
