dbms_lock.request总返回0或1却未锁住，根本原因是release_on_commit默认为true导致提交即释放；必须设为false、配合allocate_unique分配锁句柄，并在提交前显式release。
dbms_lock.request 为什么总返回 0 或 1，却没锁住？
根本原因不是函数没生效，而是 dbms_lock.request 默认使用 lock_mode => 6（排他锁），但必须配合 release_on_commit => false 才能跨事务持锁——而 oracle 默认是 true，一提交就自动释放，看起来“锁不住”。
-
DBMS_LOCK.REQUEST返回 0 表示成功获取锁，1 表示超时，4 表示参数错误；别只看返回值，要查DBMS_LOCK.ALLOCATE_UNIQUE是否已调用、锁名是否重复 - 锁名必须是合法标识符（不能含空格、特殊字符），且长度 ≤ 128 字节；建议用
'myapp_order_' || order_id这类可预测但不冲突的格式 - 若在 PL/SQL 匿名块里调用，记得显式
COMMIT或ROLLBACK后再检查锁状态，否则事务未结束，锁自然还挂着
怎么安全地分配和释放自定义锁？
不能跳过 DBMS_LOCK.ALLOCATE_UNIQUE 直接 REQUEST，否则会报 ORA-00054: resource busy 或静默失败。分配和释放是一对动作，必须成对出现，且锁名相同。
- 分配锁：先调
DBMS_LOCK.ALLOCATE_UNIQUE(lockname => 'my_lock', lockhandle => l_handle)，拿到l_handle后再传给REQUEST - 申请锁：用
DBMS_LOCK.REQUEST(lockhandle => l_handle, timeout => 3, release_on_commit => FALSE)；timeout设为 0 可实现“立即尝试，不等” - 释放锁：必须调
DBMS_LOCK.RELEASE(lockhandle => l_handle)；如果忘了，锁会持续到 session 断开，可能卡住后续请求
在存储过程中用 DBMS_LOCK 控制并发，要注意哪些陷阱？
最常踩的坑是把锁逻辑写在异常处理之后，或者放在 COMMIT 后面——这时候锁早被自动释放了。另外，自治事务（AUTONOMOUS_TRANSACTION）里调用 DBMS_LOCK 会导致锁作用域错乱，绝对避免。
- 锁必须在业务逻辑开始前申请，在
COMMIT或ROLLBACK之前释放；推荐结构：申请 → 处理 → 异常时释放 → 正常时释放 → 提交 - 不要在触发器里用
DBMS_LOCK，尤其是行级触发器；高并发下极易死锁，且 Oracle 不保证触发器中锁的可见性一致性 -
DBMS_LOCK的锁不参与 Oracle 的死锁检测机制，两个会话互相等对方的自定义锁，会一直挂起直到超时，得靠应用层加监控或主动 kill
替代方案比 DBMS_LOCK 更可靠吗？
是的。DBMS_LOCK 是 Oracle 早期提供的低层工具，无事务集成、无自动清理、不支持命名空间隔离。现在更推荐用 SELECT ... FOR UPDATE SKIP LOCKED 或基于唯一约束的插入校验，尤其对“抢资源”类场景。
- 比如扣库存：用
UPDATE stock SET qty = qty - 1 WHERE sku = 'A' AND qty >= 1+ 检查SQL%ROWCOUNT，比锁更轻量、更符合 ACID - 需要强顺序控制时，考虑用
DBMS_SCHEDULER创建独占 job，或借助外部协调服务（如 Redis 分布式锁），避免把锁逻辑全压在数据库层 -
DBMS_LOCK在 Oracle 12c+ 中仍是可用的，但官方文档已标注为“legacy”，未来版本可能受限；新项目尽量绕开
真正难的不是调通 DBMS_LOCK.REQUEST，而是想清楚：这个锁到底保护什么？粒度够不够？释放时机有没有竞态？很多问题其实换个 SQL 写法就消失了。
