DB2排他锁未释放问题求助：分布式Java应用JDBC访问场景异常

这个DB2锁阻塞的场景我在不少分布式桌面应用里碰到过，咱们先把问题掰碎了看，再给你落地的解决办法：

首先得搞清楚DB2锁的兼容规则：表级的IX（意向排他锁）和IS（意向共享锁）其实是兼容的，所以其他客户端拿到IS锁本身不会卡——真正的问题出在行级锁上：

• 客户端A未提交的INSERT/UPDATE会持有行级X锁，而其他客户端的SELECT在访问这些被锁定的行时，需要获取行级S锁（具体取决于隔离级别），X锁和S锁完全互斥，所以SELECT会直接进入等待队列，看起来就像“停滞”了。
• 客户端A持续操作还不提交，会不断累积更多行级X锁，到最后甚至可能触发DB2的锁升级——把一堆行锁升级成表级X锁，那整个表的查询都会彻底卡死。

1. 先把客户端A的事务闭环给修好 #

这是最根本的解决办法，没什么比“及时释放锁”更有效：

• 去查客户端A的业务逻辑，确保每批INSERT/UPDATE操作完成后立即执行COMMIT，别让事务挂着。如果是批量处理大量数据，拆成小批次提交（比如每1000条提交一次），既能减少锁持有时间，也能降低锁升级的概率。
• 排查代码bug：是不是捕获异常后没做回滚/提交？比如try块里操作数据库，catch块只打了日志没处理事务，导致事务一直处于活跃状态？这种低级坑一定要填上。

2. 给SELECT调整合适的隔离级别 #

根据业务场景降低隔离级别，能避免不少不必要的锁等待：

• 如果业务允许读取未提交的数据（比如后台统计、近似查询），直接用UR（Uncommitted Read，对应JDBC的TRANSACTION_READ_UNCOMMITTED）。这个级别下SELECT根本不会请求行级S锁，直接读数据，完全绕开锁阻塞。
• 如果必须读已提交的数据，用CS（Cursor Stability，对应TRANSACTION_READ_COMMITTED）。这个级别下SELECT只会在游标打开时持有行级S锁，游标一关就释放，比RR（可重复读）锁持有时间短得多，能大幅减少阻塞概率。

设置方式很简单：

• JDBC层面：connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
• SQL层面：在SELECT前加SET CURRENT ISOLATION UR;

3. 加个锁监控，提前发现问题 #

别等全卡死了才发现，用DB2的系统视图做监控：

• 查当前等待中的锁：

  SELECT 
    LOCK_NAME, 
    LOCK_MODE, 
    LOCK_STATUS, 
    APPLICATION_HANDLE, 
    APPLICATION_NAME 
  FROM SYSIBMADM.LOCKS 
  WHERE LOCK_STATUS = 'W'; -- W代表等待状态的锁
  

• 写个定时脚本跑这个查询，一旦发现大量锁等待就发预警，及时介入（比如手动终止长时间未提交的事务）。

4. 避免锁升级坑 #

如果客户端A一次操作大量行，DB2默认会触发锁升级（把行锁升级成表锁），这时候整个表都废了。可以调整参数规避：

• 修改表的锁策略：ALTER TABLE YOUR_TABLE_NAME LOCKSIZE ROW LOCKMAX 1000;（LOCKMAX 0表示禁用锁升级，根据你的业务量调整数值）
• 或者在连接级别强制行级锁：SET CURRENT LOCK MODE ROW;

5. 允许SELECT跳过锁定行 #

如果业务能接受跳过被锁的行（比如消息队列消费、非实时查询），直接用SKIP LOCKED DATA子句：

SELECT * FROM YOUR_TABLE_NAME WHERE ... SKIP LOCKED DATA;

这个语句会让SELECT直接跳过被X锁占着的行，不会傻等，完美解决停滞问题。

内容的提问来源于stack exchange，提问作者Gonçalo Ferrão