在Spring Azure qPID JMS代码中跟踪内存泄漏

Question

我试图在我们非常小且简单的Spring Boot应用程序中跟踪并确定内存泄漏的根本原因。

它使用以下内容：-Spring Boot 2.2.4-azure servicebus jms Spring Boot starter 2.2.1-MSSQL

功能：该应用程序只发送Azure ServiceBus队列，存储数据并将数据发送到其他目的地。这是一个小应用程序，所以它很容易启动64兆的内存，尽管我通过Xmx选项给它最多256兆的内存。重要注意事项是，使用Spring默认事务处理模式和专用JmsTransactionManager调度队列，JmsTransactionManager实际上是ChainedTransactionManager的内部TM，以及dbTM和其他出站JMS TM。这两个JMS ConnectionFactory对象都创建为CachingConnectionFactory。

行为：

一旦应用程序启动，它似乎就可以了。没有流量，所以我可以在日志中看到，在检查队列（jms：消息驱动通道适配器）时，它正在打开事务并关闭。

然而，在一段时间后，当仍然没有流量时，没有一条消息被消耗，内存开始上升，通过JVVM进行监控。

引发了一个错误：

--2020-04-24 11:17:01.443 - WARN 39892 ---   [er.container-10] o.s.j.l.DefaultMessageListenerContainer  : Setup of JMS message listener invoker failed for destination 'MY QUEUE NAME HERE' - trying to recover. Cause: Heuristic completion: outcome state is rolled back; nested exception is org.springframework.transaction.TransactionSystemException: Could not commit JMS transaction; nested exception is javax.jms.IllegalStateException: The Session was closed due to an unrecoverable error.

...几分钟后，它到达堆的MAX，从那时起，它在打开JMS连接的线程中因OutOfMemory错误而失败。

--2020-04-24 11:20:04.564 - WARN 39892 ---   [windows.net:-1]] i.n.u.concurrent.AbstractEventExecutor   : A task raised an exception. Task: org.apache.qpid.jms.provider.amqp.AmqpProvider$$Lambda$871/0x000000080199f840@1ed8f2b9
-
java.lang.OutOfMemoryError: Java heap space
        at java.base/java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:61)
        at java.base/java.nio.ByteBuffer.allocate(ByteBuffer.java:348)
        at org.apache.qpid.proton.engine.impl.ByteBufferUtils.newWriteableBuffer(ByteBufferUtils.java:99)
        at org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.init_buffers(TransportOutputAdaptor.java:108)
        at org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:56)
        at org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.pending(SaslImpl.java:842)
        at org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.pending(HandshakeSniffingTransportWrapper.java:138)
        at org.apache.qpid.proton.engine.impl.TransportImpl.pending(TransportImpl.java:1577)
        at org.apache.qpid.proton.engine.impl.TransportImpl.getOutputBuffer(TransportImpl.java:1526)
        at org.apache.qpid.jms.provider.amqp.AmqpProvider.pumpToProtonTransport(AmqpProvider.java:994)
        at org.apache.qpid.jms.provider.amqp.AmqpProvider.pumpToProtonTransport(AmqpProvider.java:985)
        at org.apache.qpid.jms.provider.amqp.AmqpProvider.lambda$close$3(AmqpProvider.java:351)
        at org.apache.qpid.jms.provider.amqp.AmqpProvider$$Lambda$871/0x000000080199f840.run(Unknown Source)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:510)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:518)
        at io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at java.base/java.lang.Thread.run(Thread.java:835)

堆堆：

在整个过程中，我拍摄了几个堆快照，并查看了增加的内容。我可以看到可疑数量的ConTrentHashMap/String/Byte[]对象。

有人知道/提示此设置和库中可能出现的错误吗：Spring Boot、Azure JMS依赖项下使用的Apache qPid等？非常感谢。

更新#1我有明确的证据表明，问题出现在Spring或azure service bus starter库中，而不是自动使用qPid客户端。我猜，图书馆有bug，而不是Spring。这是失败的设置的样子：

1. 有两个JMS目的地和一个DB，每个都有它的事务管理器
2. 三个TM上面有ChainedTransactionManager包装。
3. Spring集成应用程序，通过jms连接到Azure ServiceBus队列：消息驱动通道适配器并在此组件上设置事务管理器（如第2点所创建）
4. 启动应用程序。，不需要队列上的流量，10分钟后应用程序将因OutOfMemoryError而崩溃...在这10分钟内，我观看了调试级别的日志，唯一发生的事情是使用ChainedTransactionManager打开和关闭事务...另一个重要条件是第三个JMS TransactionManager...有2个TM它工作并且稳定，有3个它会崩溃...

Answer 1

额外的研究和采取的步骤确定了最可能的根本原因Spring CachingConnectionFactory类。一旦我删除它并仅使用本机类型，问题就消失了，内存消耗配置文件非常不同且健康。

我不得不说，我使用标准构造函数创建了CachingConnectionFactory，但没有进一步配置行为。然而，根据我的经验，这些Spring默认值显然会导致内存泄漏。

过去，我在ActiveMq上有内存泄漏，这必须通过使用CachingConnectionFactory来解决，现在我在使用CachingConnectionFactory时在Azure ServiceBus上有内存泄漏。。奇怪：）在这两种情况下，我都认为这是错误，因为无论是否涉及缓存，内存管理都应该是正确的。

把这当作我的答案。

测试案例：使用自己的TM和两个JMS连接工厂都是CachedConnectionFactory类型接收和发送消息时出现问题。最后我测试了应用程序。CachedConnectionFactory类型的入站连接工厂和出站只是本机类型...也没有内存泄漏。