本文详解 websphere 7 中因未正确结束事务引发的 ibm mq 连接泄漏问题，重点分析 `state_active_inuse` 状态连接长期占用、线程阻塞及 `classnotfoundexception` 的深层关联，并提供可落地的代码规范、配置优化与诊断策略。
在 WebSphere Application Server（WAS）7.0.0.45 环境中集成 IBM MQ 7.0.1.14 资源适配器时，若出现连接句柄长时间处于 STATE_ACTIVE_INUSE 状态（如日志中显示 Time inuse 3629 (seconds)），且线程（如 WebContainer : 2）持续阻塞，根本原因通常并非连接未显式关闭，而是底层事务未正常提交或回滚，导致 WAS 连接管理器（ConnectionManager）无法回收物理连接。
从您提供的堆栈和关键线索可明确两点：
- open connection handles = [com.ibm.ejs.jms.JMSQueueConnectionHandle@...] 表明应用层已成功获取句柄；
- Connection marked to be destroyed. Waiting for transaction end and connection close 是核心提示：WAS 正在等待事务生命周期终结，才允许连接释放；
- 后续发现的 ClassNotFoundException 并非孤立异常——它发生在事务上下文中，当类加载失败导致业务逻辑异常中断，而事务未被显式回滚（或容器未感知到需回滚）时，事务将无限期挂起（尤其是使用 RequiresNew 或 Mandatory 传播级别时），进而锁住连接与线程。
✅ 正确的 JMS 资源释放模式（必须结合事务语义）
即使使用 finally 块关闭 Connection/Session，若事务未结束，WAS 仍不会释放底层 MQ 物理连接。务必遵循以下原则：
// ✅ 推荐：使用 Spring JmsTemplate（自动管理资源与事务）
jmsTemplate.send("QUEUE.NAME", session -> {
TextMessage msg = session.createTextMessage("Hello");
return msg;
});
// 自动 commit / rollback，连接由池安全回收
// ❌ 风险：手动管理 + 未处理事务边界
Connection conn = null;
Session sess = null;
try {
conn = cf.createQueueConnection(); // 可能加入当前事务
sess = conn.createSession(true, Session.SESSION_TRANSACTED); // XA 事务
// ... send/receive ...
} catch (Exception e) {
// 若此处抛出异常但未 rollback，事务悬停！
throw e;
} finally {
// 即使调用 close()，WAS 仍等待事务结束
if (sess != null) sess.close();
if (conn != null) conn.close();
}⚙️ 关键配置与诊断建议
| 项目 | 推荐配置 | 说明 |
|---|---|---|
| JMS 连接池超时 | Connection Timeout = 5s（已配置） | 仅控制“获取新连接”的等待时间，不强制终止已分配但未释放的连接 |
| 事务超时（全局） | 在 WAS 控制台 → 服务器 → 应用程序服务器 → 事务 → 设置 Total Transaction Lifetime Timeout（建议 ≤ 120s） | 强制终止卡住的事务，触发连接回收；避免 Time inuse 达数千秒 |
| 类加载隔离 | 将 MQ 客户端 JAR（如 com.ibm.mq.allclient.jar）放入 WAS 共享库（Shared Library）并绑定到应用，而非打包进 EAR 的 lib/ | 规避 ExtClassLoader 与 CompoundClassLoader 冲突导致的 ClassNotFoundException，从根源防止事务异常中断 |
| 连接泄漏追踪 | 启用精准跟踪： com.ibm.ejs.j2c.ConnectionLeakLogic=all: com.ibm.ejs.j2c.ConnectionManager=all |
比泛用 *=info 更高效，聚焦连接生命周期事件 |
? 注意事项与总结
- ClassNotFoundException 是症状，不是病因：它暴露了类加载策略缺陷，而该缺陷在事务上下文中会演变为连接泄漏。请优先检查类加载委托模型（PARENT_FIRST vs PARENT_LAST）及共享库绑定状态。
- 勿依赖 close() 清理事务资源：在容器管理的 JTA 事务中，Connection.close() 仅归还句柄至池，事务提交/回滚必须由容器（通过 UserTransaction）或声明式注解（@Transactional）驱动。
- 监控黄金指标：定期检查 WAS 管理控制台的 “连接池使用率” 和 “活动事务数”，若二者长期高位同步增长，即为典型事务泄漏信号。
- 升级建议：WAS 7.0.0.45 与 MQ 7.0.1.14 均属 EOL 版本。升级至 WAS Liberty + MQ 9.x 可获得更健壮的连接泄漏自动检测（如 leakDetectionThreshold）与类加载诊断能力。
通过强化事务边界控制、修正类加载策略、启用事务超时机制，可系统性根治此类“连接标记销毁却无限等待”的顽疾，确保 MQ 连接池健康运转。
