如何排查Spring CachingConnectionFactory会话缓存耗尽问题

• 开启框架内置调试日志
  将org.springframework.jms.connection.CachingConnectionFactory的日志级别调整为DEBUG，该类会输出会话池全生命周期的关键日志：包括申请空闲会话、会话池已满触发等待、会话释放回池等事件。故障发生时可直接通过日志确认是否存在会话池耗尽后等待空闲资源的场景，也可以统计峰值时段的会话并发占用量。
• 埋点采集会话池运行指标
  通过AOP切面或继承扩展CachingConnectionFactory的方式，采集3个核心指标上报到监控系统：当前缓存的会话总数量、当前已借出（正在使用）的会话数量、等待会话的排队线程数。配置阈值告警，当已借出会话数持续等于配置的50上限、同时存在排队等待线程时，即可直接确认是会话池不足导致的发布耗时上涨。如果是Spring Boot项目可直接对接Micrometer将指标暴露为时序指标，支持回溯故障时段的指标走势，不需要等消费侧滞后感知后再排查。
• 线程转储排查方案
  就算是事后采集的线程转储也有排查价值：故障发生时等待会话的线程调用栈会卡在CachingConnectionFactory的getSession方法的同步块位置，线程状态为BLOCKED或WAITING，同时统计持有MQ会话的线程数如果刚好为50，也可以作为会话池耗尽的佐证。如果担心事后采集滞后，可以配置定时采样任务，比如每30秒执行一次jstack输出线程转储文件，保留最近24小时的文件，故障发生后直接回溯对应时间点的转储即可。
• 反向验证方案
  可以先将sessionCacheSize临时调整到100做灰度验证，如果调整后消息发布超时的异常完全消失，也可以反向印证原故障是会话池上限不足导致。

注意：如果确认是会话池耗尽，还需要排查是否存在会话泄漏问题：即部分场景下会话使用完成后未正确归还到池子里，导致资源被长期占用无法复用，这种情况单纯调大sessionCacheSize只能临时缓解问题，后续还是会再次出现故障，可以结合DEBUG日志中的会话释放事件逐一核对。

内容的提问来源于stack exchange，提问作者Neer1009