在我们的生产环境中，我正在经历tomcat的定期无响应。 我不能在testing环境中重现这一点，并且在事件发生之前或事件发生期间没有任何内容出现在日志中。 Tomcat继续运行，但停止服务请求。 我读过这个线程，并在JAVA_OPTS中放置了垃圾收集输出选项，但是我还没有重新启动tomcat来使它们生效。 我的情况不同在于，tomcat / jvm显然不会恢复或“醒来”。 我已经确认，我们的应用在多个场合中至less有15分钟没有响应。 解决scheme总是重新启动tomcat（使用daemontools）。 频率变化，有时在高峰负荷，有时在半夜（非常轻的负荷）。
我已经允许jvm（-Xms2g -Xmx4g）的内存高达4g。 服务器有16克内存，正在运行64位jvm。 Sun关于Java调优的白皮书声称：“承诺过多的系统物理内存很可能导致虚拟内存分页到磁盘，很可能在垃圾收集操作期间，导致显着的性能问题。 我是否将堆大小设置得太大？ 将最小尺寸设置为与最大尺寸相同，我会受益吗？
我不相信系统正在将内存交换到磁盘。 free -m的输出不显示交换使用情况，我在系统上将swappiness设置为0。
当今天凌晨2:30发生无反应时，我在重新启动tomcat之前运行了一个快速的jstat和ps：
除了一些例外情况，jstat显示了类似的值：YGC是431比44现在，YGCT 10/1，FGC 59/7，FGCT 39/2，GCT 49/3
ps的输出显示了1422832个常驻和5723580个虚拟内存使用情况。 这与昨天正常运营期间的1390036和5642668相比。
我不是这方面的专家，所以任何帮助，将不胜感激。
更新：好的，我已经添加到JAVA_OPTS以下将暂时重新启动tomcat：
-XX：+ UseConcMarkSweepGC -Xms2g -Xmx2g -verbose：gc -XX：+ PrintGCTimeStamps -XX：+ PrintGCDetails
变化是：1）swich gcalgorithm。 2）降低最大堆大小，因为它似乎我不需要4克，显然过度使用可以导致周期性的大规模gc。 3）打开vebose gc日志logging。 谢谢大家。
首先，在“使用5.0 Java TM虚拟机调整垃圾收集”
这听起来像GC暂停使tomcat无响应。 首先要做的就是一个“低暂停”的垃圾收集器，它的选项是-XX:+UseConcMarkSweepGC 。
我们在生产环境中看到了这一点，最终确实是java的垃圾收集停止了进一步的请求。 对于我们来说，最大的障碍是在无响应期间的至less一个内核上100％的处理器使用率。
我们的答案是追踪应用程序中的内存泄漏。 我不确定这是否是您的答案，但至less是另一个数据点。