我在JBoss中有一种非常奇怪的行为，我想利用SO群众的集体智慧。
我们正在使用JBoss（我认为是4.0.4）来提供SOAP调用。事实上，它已被用作美化的RPC服务器，不再需要。当我们有20多个客户同时发送请求时，我们的内存不足。请求包括传入的相当小的请求（适当的SOAP）和返回的结果包，它实质上是一个长SOAP字符串（并且字符串的内容是XML）。是的，我意识到这不是最理想的。不要问。
我已经将泄漏跟踪到了一个包含400万个对象（字符串和整数）的org.jboss.axis.message.SAX2EventRecorder实例。现在，即使是最长的响应也不会携带4MB的数据。请求都小于40K。那里有些东西可疑，但我在网上找不到任何文件。
有人能告诉我录音机的用途吗？我怎么摆脱它呢？或者可能将其配置为内存不足？任何帮助表示赞赏。
更新：澄清 - 我确实做了内存转储，转储显示了一个数组或4,000,000多个对象，字符串和整数。该数组由org.jboss.axis.message.SAX2EventRecorder拥有，而后者由这些人持有：
org.jboss.axis.message.SOAPEnvelopeAxisImpl@0x19c31fd8(141 bytes）：现场记录仪 org.jboss.axis.message.RPCParamElementImpl@0x19c32260(123 bytes）：现场记录仪 org.jboss.axis.message.SOAPBodyAxisImpl@0x19c32160(121 bytes）：现场记录仪 org.jboss.axis.message.RPCElement@0x19c321e0(124 bytes）：现场记录仪 org.jboss.axis.encoding.DeserializationContextImpl@0x19c332f0(67 bytes）：现场记录器 org.jboss.axis.message.SAX2EventRecorder$objArrayVector@0x19c33398（24字节）：字段为$ 0
我们自己的应用程序的数据结构是膨胀的，但不是这种程度。
另一个更新：已经找到“权力即解决方案”的权力：我们正在切换到64位内存。欢呼。
答案 0 :(得分：11)
使用JVM运行arg -XX：-HeapDumpOnOutOfMemoryError。当内存不足时，这将为您提供堆转储。然后，您可以使用 jhat 工具（它随JDK一起提供）分析堆转储。或者，您可以使用 jconsole 工具（也随JDK一起提供）使用内存管理MBean随时请求堆转储。
它会告诉你实际包含的400万个对象是什么，这可能会让你深入了解软件没有释放内存的原因。
编辑：
看来你不是唯一有这个问题的人。向Axis提交了2个错误报告
另见AXIS-1771，它有一些有关反序列化的有趣信息以及调解其影响的方法。您使用的是哪个版本的Axis？
答案 1 :(得分：0)
如果可以，请在Java 6下运行该应用程序。最新版本包括VisualVM用于分析。它应该能够显示记忆的增长。您可以附加到Java 5 VM，但它没有显示那么多。