java JBoss 内存泄漏

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/483379/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-10-29 12:35:55  来源:igfitidea点击:

Memory leak in JBoss

javasoapjboss

提问by Kevin

I am having a very strange behavior in JBoss, and I'd like avail myself of the Collective Wisdom of the SO Crowd.

我在 JBoss 中有一个非常奇怪的行为,我想利用 SO Crowd 的集体智慧。

We're using JBoss (4.0.4 I think) to serve SOAP calls. In fact, it's used as glorified RPC server, no more. We're running out of memory when we have 20+ clients sending their requests at the same time. The requests consist of the incoming rather small request (proper SOAP) and the returning result packet that is essentially one long SOAP string (and the contents of the string are XML). Yes I realize this is suboptimal. Don't ask.

我们使用 JBoss(我认为是 4.0.4)来处理 SOAP 调用。事实上,它被用作美化的 RPC 服务器,仅此而已。当我们有 20 多个客户端同时发送请求时,内存不足。请求由传入的相当小的请求(适当的 SOAP)和返回的结果包组成,该包本质上是一个长 SOAP 字符串(并且字符串的内容是 XML)。是的,我意识到这是次优的。不要问。

I've traced the leak to an instance of org.jboss.axis.message.SAX2EventRecorder that hold 4 million objects (strings and Integers). Now, even the longest response does not carry 4MB of data. The requests are all smaller than 40K. Something is fishy there, but I can't find any documentation on the Web.

我已经将泄漏追溯到 org.jboss.axis.message.SAX2EventRecorder 的一个实例,该实例包含 400 万个对象(字符串和整数)。现在,即使是最长的响应也不携带 4MB 的数据。请求都小于40K。那里有些可疑,但我在网上找不到任何文档。

Can someone tell me what the recorder is used for? And how do I get rid of it? Or may be configure it to be less memory-hungry? Any help is appreciated.

谁能告诉我录音笔是干什么用的?我该如何摆脱它?或者可以将其配置为不那么占用内存?任何帮助表示赞赏。



Update: To clarify - I did do memory dump, and the dump shows an array or 4,000,000+ objects, Strings and Integers. The array is owned by a org.jboss.axis.message.SAX2EventRecorder which is in turn held by these guys:

更新:澄清一下 - 我确实做了内存转储,转储显示了一个数组或 4,000,000+ 个对象、字符串和整数。该数组由 org.jboss.axis.message.SAX2EventRecorder 所有,而后者又由这些人持有:

org.jboss.axis.message.SOAPEnvelopeAxisImpl@0x19c31fd8 (141 bytes) : field recorder org.jboss.axis.message.RPCParamElementImpl@0x19c32260 (123 bytes) : field recorder org.jboss.axis.message.SOAPBodyAxisImpl@0x19c32160 (121 bytes) : field recorder org.jboss.axis.message.RPCElement@0x19c321e0 (124 bytes) : field recorder org.jboss.axis.encoding.DeserializationContextImpl@0x19c332f0 (67 bytes) : field recorder org.jboss.axis.message.SAX2EventRecorder$objArrayVector@0x19c33398 (24 bytes) : field this$0

org.jboss.axis.message.SOAPEnvelopeAxisImpl@0x19c31fd8(141 字节):现场记录器 org.jboss.axis.message.RPCParamElementImpl@0x19c32260(123 字节):现场记录器 org.jboss.axis.message.SOAPBodyc190C10 ) : 现场记录器 org.jboss.axis.message.RPCElement@0x19c321e0 (124 字节) : 现场记录器 org.jboss.axis.encoding.DeserializationContextImpl@0x19c332f0 (67 字节) : 现场记录器 org.jboss.axis.Recorder.message.S objArrayVector@0x19c33398(24 字节):字段 this$0

The data structures of our own app are quete bloated, but not to this degree.

我们自己的应用程序的数据结构非常臃肿,但还没有到这个程度。

Another update: powers that be have found a "powers-that-be-solution": we're switching to 64-bit memory. Hurray.

另一个更新:权力已经找到了“权力的解决方案”:我们正在切换到 64 位内存。欢呼。

回答by Kevin

Run with the JVM arg -XX:-HeapDumpOnOutOfMemoryError. This will give you heap dumps when you run out of memory. You can then analyze the heap dump with the jhattool (it comes with your JDK). Alternatively, you can use the jconsoletool (which also comes with your JDK) to request a heap dump at any time using the memory management MBeans.

使用 JVM arg -XX:-HeapDumpOnOutOfMemoryError 运行。当内存不足时,这将为您提供堆转储。然后您可以使用jhat工具(它与您的 JDK 一起提供)分析堆转储。或者,您可以使用jconsole工具(它也随 JDK 一起提供)随时使用内存管理 MBean 请求堆转储。

It will tell you what those 4 million objects actually contain which might give you insight into why the software isn't releasing that memory.

它会告诉您这 400 万个对象实际包含的内容,这可能会让您深入了解软件不释放该内存的原因。

EDIT:

编辑:

It seems you're not the only one with this issue. There are 2 bug reports filed with Axis

看来您不是唯一遇到此问题的人。向 Axis 提交了 2 个错误报告

AXIS-2698

AXIS-2698

AXIS-2749

AXIS-2749

See also AXIS-1771, it has some interesting information regarding deserialization and ways to mediate its impact. Which version of Axis are you using?

另请参见AXIS-1771,它有一些关于反序列化和调节其影响的方法的有趣信息。您使用的是哪个版本的 Axis?

回答by Joshua

If you can, run the application under Java 6. The latest version includes VisualVMfor profiling. It should be able to show the growth of memory. You can attach to a Java 5 VM, but it doesn't show as much.

如果可以,请在 Java 6 下运行该应用程序。最新版本包括用于分析的VisualVM。它应该能够显示内存的增长。您可以附加到 Java 5 VM,但它不会显示那么多。