我们已经调试了这个JBoss服务器问题很长一段时间了。经过大约10个小时的工作，服务器进入100％CPU恐慌攻击并停止。在此期间，您无法运行任何新程序，因此您甚至无法kill -quit获得堆栈跟踪。这些高100％SYS CPU负载持续10-20秒，每隔几分钟重复一次。
我们已经工作了很长一段时间。我们怀疑它与GC有关，但无法通过较小的程序确认。我们使用-client和ParNew GC在i386 32位，RHEL5和Java 1.5.0_10上运行。
这是我们到目前为止所尝试的内容：
我们限制了CPU亲和力，因此我们可以在高负载点击时实际使用服务器。使用strace，我们会看到SIGSEGV的无限循环，然后返回sig。
我们尝试使用Java程序重现这一点。确实，SYS CPU％在WeakHashMap或访问空指针时爬升得很高。问题是fillStackTrace占用了大量用户CPU％，这就是我们从未达到过100％SYS CPU的原因。
我们知道经过10个小时的压力后，GC会变得疯狂，完整的GC有时需要5秒钟。所以我们假设它与记忆有关。
jstack显示所有线程都被阻止。 pstack在此期间，偶尔显示MarkSweep堆栈跟踪，因此我们也无法确定这一点。发送SIGQUIT没有产生任何结果：Java在SYS％加载期结束后转储了堆栈跟踪。
我们现在尝试使用一小段代码重现此问题，以便我们可以询问Sun.
如果您知道原因是什么，请告诉我们。我们对创意持开放态度，我们无能为力，欢迎任何想法：）
感谢您的时间。
答案 0 :(得分：1)
如果您确定GC是问题（根据您的描述它确实声音），那么在您的JBoss设置中添加-XX：+ HeapDumpOnOutOfMemoryError标志可能会有所帮助（在JBOSS_HOME / bin中/ run.conf）。
您可以阅读有关此标志here的更多信息。它最初是在Java 6中添加的，但后来back-ported添加到Java 1.5.0_07。
基本上，如果发生OutOfMemoryError，您将获得“转储文件”，然后可以在各种分析工具中打开它。我们对Eclipse Memory Analyzer祝你好运。
这不会给你任何“免费”答案，但如果你确实有内存泄漏，那么这将帮助你找到它。
答案 1 :(得分：1)
感谢大家帮忙。
最终我们升级了（只有一半的java服务器）到JDK 1.6，问题就消失了。只是不要使用1.5.0.10：）
我们设法通过访问空指针来重现这些问题（提升SYS而不是US，并杀死整个linux。）
再次感谢大家。
答案 2 :(得分：0)
您是否尝试过分析应用程序。有一些很好的分析应用程序可以在生产服务器上运行。如果GC遇到麻烦以及哪些对象
，那些应该会给你答案 3 :(得分：0)
去年我遇到了与JBoss（JBoss 4，Linux 2.6）类似的问题。我认为最终它确实与应用程序错误有关，但它绝对很难弄明白。我会继续尝试向进程发送'kill -3'，以获得某种堆栈跟踪并找出阻塞的内容。也许添加日志记录语句，看看你是否可以弄清楚是什么设置它。您可以使用'lsof'来确定它打开的文件;这将告诉你是否有一些资源泄漏而不是内存。
另外，为什么用-client而不是-server运行JBoss？ （不是我认为在这种情况下它会有所帮助，只是一个普遍的问题）。
答案 4 :(得分：0)
您可以尝试添加命令行选项-verbose：gc，它应该将GC和堆大小输出到stdout。将stdout传递给一个文件，看看高cpu次数是否与一个主要的gc排列。
我记得在Windows上遇到与JBoss类似的问题。定期cpu将达到100％，并且Windows报告的内存使用量会突然下降到2.5 MB，比运行JBoss要小得多，并且在几秒钟后自行备份。好像整个服务器都关闭并重新启动。我最终将我的问题跟踪到一个准备好的语句缓存，永远不会在Apache Commons中过期。
如果它确实是一个内存问题，那么你可以开始定期堆转储并比较两者，或使用类似JProbe Memory profiler的东西来跟踪所有内容。