DBMS_LOCK.REQUEST总返回0或1却没锁住的根本原因是release_on_commit默认为TRUE，导致事务提交后锁自动释放；必须显式设FALSE才能跨事务持锁，且需先ALLOCATE_UNIQUE再REQUEST，锁名须纯字母数字加下划线、含关键业务维度、长度≤100字节，释放必须在COMMIT前且覆盖异常路径。
DBMS_LOCK.REQUEST为什么总返回0或1却没锁住
根本原因是 release_on_commit 默认为 true，事务一提交锁就自动释放，看起来“没锁住”。这不是函数失效，而是锁生命周期被截断了。
-
DBMS_LOCK.REQUEST返回0表示成功获取锁（哪怕只是瞬间），1是超时，4是当前会话已持有该锁——别只判是否为 0，得结合业务逻辑处理不同返回值 - 必须显式设
release_on_commit => FALSE，否则锁无法跨事务存在 - 没调
DBMS_LOCK.ALLOCATE_UNIQUE就直接REQUEST，可能静默失败或报ORA-00054，句柄必须先分配再使用 - 锁名重复、含空格或特殊字符（如点、斜杠）会导致分配失败或映射错乱，建议用
'myapp_' || p_key这类纯字母数字+下划线的格式
锁名怎么拼才不串货也不漏锁
硬编码锁名（比如固定写 'order_proc_lock'）会让所有请求互斥，实际只需按业务维度隔离。锁名是全局字符串标识，Oracle 用它查内部句柄表，拼错=锁错范围。
- 关键维度必须进锁名：例如订单处理要带
org_id和order_id，写成'order_' || p_org_id || '_' || p_order_id - 长度不能超 100 字节（部分文档说 128，但实测 ≥101 会被截断，导致不同参数生成相同锁名）
- 避免动态拼接出非法标识符：比如
p_order_id含连字符或中文，先做REPLACE(p_order_id, '-', '_')或TRANSLATE清洗 - 不要用包名或过程名当锁名主体——多个租户共用同一套代码时，必须靠业务键区分
锁必须在COMMIT前释放，且异常路径也要覆盖
忘了 DBMS_LOCK.RELEASE 是最危险的疏忽：锁不会自动清理，会话断开前一直挂着，后续所有同名请求全卡死。自治事务里调用更糟，锁作用域完全不可控。
- 释放动作必须出现在两个位置：主流程末尾 +
EXCEPTION块内，缺一不可 - 别把锁逻辑放在
COMMIT后面——那时锁早被release_on_commit => TRUE自动清掉了 - 禁止在触发器（尤其是行级）里用
DBMS_LOCK，高并发下极易死锁，且 Oracle 不保证触发器中锁状态的一致性 - 如果业务允许重试，
REQUEST返回1（超时）时别直接报错，可加DBMS_LOCK.SLEEP(0.1)后重试几次
DBMS_LOCK的锁不参与Oracle死锁检测
两个会话互相等对方的自定义锁，Oracle 不会像 DML 锁那样主动报 ORA-00060，只会一直挂起直到超时。这意味着你得自己监控和兜底。
- 设置合理
timeout（比如 3–30 秒），避免无限等待 - 在应用层记录锁申请日志，包含会话 ID、锁名、开始时间、返回值，便于排查长等待
- 定期查
DBA_LOCKS或V$LOCK（注意：自定义锁不显示在这里），真正要查残留锁得靠DBMS_LOCK.ALLOCATE_UNIQUE的元数据表或手动 kill session - 生产环境建议搭配应用层熔断：连续 N 次锁超时就告警并降级，而不是死等
