试图导致java.lang.OutOfMemoryException

我试图在Jboss4中重现java.lang.OutOfMemoryException，我们的一个客户机可能是通过在几天/几周内运行J2EE应用程序得到了它

我正试图找到一种方法，让webapp在几分钟（而不是几天/几周）内抛出java.lang.OutOfMemoryException

想到的一件事是编写一个selenium脚本，并让该脚本轰击Web应用程序。 我们可以做的另一件事是减少JVM堆大小，但我们不希望这样做，因为我们希望看到系统的限制

有什么建议吗

---

ps：我没有访问源代码的权限，因为我们只提供了一个托管服务（当然我可以反编译类文件…）

两者都做，但以可控的方式：

将可用内存减少到绝对最小（例如使用

-Xms1M-Xmx2M

，但我担心您的应用程序甚至无法加载这些限制）

控制“核辐射”：在攻击假定有罪的URL之前，执行Selenium脚本或每个已知的工作URL

最后，释放不应被激发的力量：启动VisualVM和任何你能想到的其他监控软件（DB执行是一个常见的嫌疑）

---

如果您无法访问所讨论的J2EE应用程序的源代码，您会想到以下选项：

减少JVM可用的RAM数量。你已经确认了这一点，并说你不想这么做

创建一个J2EE应用程序（它可能只是一个JSP），并将其配置为在与目标应用程序相同的JVM中运行，并让该应用程序分配大量内存。这将减少目标应用程序可用的内存量，希望它能以您试图强制的方式失败

---

问题的根源很可能是客户端正在运行的webapp内存泄漏。为了追踪它，您需要在具有代表性的工作负载下运行应用程序，并启用内存分析。拍摄一些快照，然后使用探查器比较快照以查看对象泄漏的位置。虽然源代码是理想的，但您至少应该能够找出泄漏对象的分配位置。然后你需要找出原因

但是，如果您的客户不发布二进制文件以便您可以运行与他运行的系统相同的系统，那么您就有点卡住了，您需要让客户自己进行分析和泄漏检测

顺便说一句，导致webapp抛出outofmemory错误没有多大意义。它不会告诉你它为什么会发生，如果不理解“为什么”，你就不能对此做很多事情

编辑

---

如果内存泄漏的根本原因是客户端代码，那么“测量限制”就没有意义。假设您正在提供一个servlet托管服务，最好的做法是向客户机提供有关如何调试内存泄漏的说明。。。让开。如果他们有一个支持合同，要求你（实际上）调试他们的代码，他们应该提供你的源代码来完成你的工作。< /P> < P>如果你使用Sun java 6，你可能想考虑在JDK中用JVisualVM附加到应用程序。这将允许您在不需要更改场景中的任何内容的情况下进行就地分析，并且可能会立即发现罪魁祸首。

尝试使用一些分析工具来调查内存泄漏。也可以用来研究OOM发生和记录之后的内存衰减。IMHO：减少内存不是调查问题的最正确方法，因为你可能会发现与实际生产无关的问题

如果您没有源代码，请使用反编译，至少如果您认为使用条款允许，并且您生活在一个自由的国家。您可以使用：

---

或者。

除了所有其他错误之外，我必须说，即使你可以重现OutOfMemory错误，并找出它发生的地方，你可能还没有发现任何值得知道的东西

问题在于，当分配无法进行时，OOM就会发生。然而，真正的问题不是分配，而是代码其他部分中的其他分配没有被取消分配（取消引用和垃圾收集）。这里失败的分配可能与问题的来源无关（没有双关语）

在您的情况下，这个问题更大，因为可能需要数周时间才能出现问题，这意味着要么是使用较少的应用程序，要么是异常的代码路径，要么是与代码正常时所需的内存相对较大

问问大家为什么要为JBoss配置这么多内存，而不是其他什么东西，这可能是个好主意。如果是供应商建议的，那么他们可能已经知道泄漏情况，并要求这样做以减轻缺陷的影响

对于这些类型的错误，了解问题发生的代码路径是值得的，这样您就可以进行有针对性的测试。并使用探查器进行测试，这样您就可以在运行时看到哪些对象（列表、贴图等）在增长而不收缩

这将使您有机会反编译正确的类，并查看它们的错误。（在try块而不是finally块中关闭或清理）

---

无论如何，祝你好运。我想我宁愿大海捞针。当你找到针时，你至少知道你已经找到了：）

“ps:我没有访问源代码的权限。”-关于你自己的产品？关于JBoss？@Stephen C：他没有说web应用是他的产品，他只是说使用它的人是他的客户。例如，他可能是一个主机提供商。“Re：我们可以做的是减少JVM堆大小，但我们不希望这样做，因为我们希望看到系统的限制。”如果您有一个与客户机完全相同的参考测试系统，那么不这样做是很有用的