lmon进程在oracle 11g rac中不会发生传统死锁，但可能因已知bug（如24732075内存泄露、21520447无限循环等）导致挂起、高cpu或节点驱逐；其异常表现为全局锁管理失常、ora-60延迟触发等，本质是功能失常而非死锁。
lmon 进程在 oracle 11g rac 中不会“死锁”，但可能因已知 bug 卡住、挂起或持续高 cpu 占用，表现为全局锁管理异常、节点驱逐、或 ora-60 死锁报错延迟超长（如 60 秒才触发）——这本质是 lmon 功能失常，不是传统意义的死锁。
为什么 LMON 看起来像“死锁”但实际不是
LMON（Lock Monitor）是 RAC 全局队列服务（GES/GCS）的核心后台进程，负责检测跨实例死锁、维护全局锁状态、协调缓存融合。它本身不持有用户级数据锁，也不参与事务等待链。所谓“LMON 死锁”，常见于以下真实现象：
- 告警日志反复出现
Global Enqueue Services Deadlock detected，但v$ges_deadlock或 trace 文件中无有效死锁图 —— 实际是 LMON 未能及时完成死锁分析循环 - 执行
SELECT * FROM GV$LOCK WHERE TYPE='UL'发现大量BL（Buffer Cache Lock）或CF（Control File）锁长期不释放，且REQUEST和BLOCK列值异常 -
ps -ef | grep lmon显示进程存在，但top中 CPU 持续 90%+，oradebug dump lkdebug 3无响应或 hang 住 - RAC 节点间频繁发生
Node Eviction，crsctl check cluster -all显示节点反复 offline/onlne，而网络、心跳、OCR 均正常
Oracle 11.2.0.4 上 LMON 异常的已知 Bug 及补丁对应关系
Oracle 官方明确记录了多个导致 LMON 行为异常的 Bug，集中在 11.2.0.4 的早期 PSU 和个别 BP 中。关键补丁包括：
-
21520447：修复 LMON 在特定 GES 队列争用下进入无限循环（常见于高并发 UPDATE + SELECT FOR UPDATE 场景） -
22191574：解决 LMON 处理ORA-4031内存分配失败后未正确重置状态，引发后续锁管理逻辑 hang -
23054246：修正 LMON 在节点重启后未清理残留全局队列引用，造成后续实例无法获取CF锁 -
24732075：修补 LMON 对_lm_dd_interval参数变更后的内存泄露（正是你提到的“内存泄露”直接诱因）
这些补丁均包含在 PSU 11.2.0.4.180417 或更高版本 中。低于该版本的 PSU（如 11.2.0.4.160419）即使打全，仍可能触发 24732075 描述的内存缓慢增长问题，最终导致 LMON RSS 内存超 2GB 后响应迟钝。
验证 LMON 是否受内存泄露影响的实操步骤
不要依赖 top 粗略看 RSS，需结合 Oracle 内部视图与 OS 层交叉确认：
- 查 LMON 当前内存使用：
SELECT pid, spid, program, pga_used_mem/1024/1024 AS pga_mb, pga_max_mem/1024/1024 AS pga_max_mb FROM v$process WHERE program LIKE '%LMON%';
- 对比历史基线：若
pga_max_mb> 1800 且持续上涨，基本可判定受24732075影响 - 查 OS 层实际内存占用：
cat /proc/<spid>/status | grep VmRSS</spid>（单位 KB），若 > 2.2e6（即 2.2GB），说明已严重超标 - 检查是否启用隐含参数：
SELECT ksppinm, ksppstvl FROM x$ksppi a, x$ksppcv b WHERE a.indx = b.indx AND ksppinm LIKE '_lm%';—— 若_lm_dd_interval被手动调小（如设为 30），会显著加剧该泄露
补丁升级不是“一键操作”，必须注意三点
在生产 RAC 上升级 PSU 涉及停机窗口、回滚风险和实例同步要求：
- 必须使用
opatch auto（非opatch apply），否则 GI 和 RDBMS 补丁无法协同生效，可能导致 LMON 启动失败 - 升级顺序严格：先升级 Grid Infrastructure（GI），再升级 RDBMS；且两个节点必须分别单独升级，不能并行
- 升级后必须重启所有实例（
srvctl stop database -d <db> && srvctl start database -d <db></db></db>），仅ALTER SYSTEM CHECKPOINT无效 —— LMON 状态驻留在 SGA 中，不重启无法加载新逻辑
最易被忽略的一点：升级前未收集 LMON trace（oradebug setmypid; oradebug dump lmon_state 3）作为基线，升级后无法对比验证是否真正修复。
