GcTimeLimit 可能不会出错的原因是什么？
我有一个 Java 网络服务，包含在 Jetty 中。我使用 Sun 的 Java 6 和默认的 ParallelGC，并且打开了以下命令行选项：“-verbose:gc -XX:+PrintGCTimeStamps --XX:+PrintGCDetails”。
当我的进程内存不足时，我会连续看到这样的日志行：
66872.846: [Full GC [PSYoungGen: 932534K->930686K(1865088K)] [PSOldGen: 5595037K->5595024K(5595136K)] 6527571K->6525710K(7460224K) [PSPermGen: 16488K->16487K(21504K)], 12.2488150 secs] [Times: user=12.25 sys=0.00, real=12.24 secs] 66885.098: [Full GC [PSYoungGen: 932608K->932608K(1865088K)] [PSOldGen: 5595024K->5595024K(5595136K)] 6527632K->6527632K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 9.6745600 secs] [Times: user=9.66 sys=0.01, real=9.67 secs] 66894.773: [Full GC [PSYoungGen: 932608K->932488K(1865088K)] [PSOldGen: 5595024K->5595023K(5595136K)] 6527632K->6527512K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 11.8445420 secs] [Times: user=11.85 sys=0.00, real=11.85 secs] 66906.623: [Full GC [PSYoungGen: 932608K->932608K(1865088K)] [PSOldGen: 5595023K->5595023K(5595136K)] 6527631K->6527631K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 9.6006950 secs] [Times: user=9.60 sys=0.00, real=9.60 secs] 66916.224: [Full GC [PSYoungGen: 932608K->932488K(1865088K)] [PSOldGen: 5595023K->5595023K(5595136K)] 6527631K->6527512K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 9.6498320 secs] [Times: user=9.65 sys=0.00, real=9.65 secs] 66925.881: [Full GC [PSYoungGen: 932608K->0K(1865088K)] [PSOldGen: 5595023K->4133351K(5595136K)] 6527631K->4133351K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 6.8990990 secs] [Times: user=6.90 sys=0.00, real=6.90 secs]
前五行似乎显示垃圾收集器完全无法取得任何进展。根据我对 JVM 的理解，这应该会导致 OutOfMemoryError，但我在日志中没有看到类似的内容。是否有可能有什么东西（在 JVM 级别）阻止它们被抛出？或者也许 Jetty 或我的应用程序正在抑制它们？
感谢您的建议！
I have a web service in Java, contained in Jetty. I'm using Sun's Java 6 with the default ParallelGC, and I have the following command-line options turned on: "-verbose:gc -XX:+PrintGCTimeStamps --XX:+PrintGCDetails".
When my process is out of memory, I see loglines like this, back-to-back:
66872.846: [Full GC [PSYoungGen: 932534K->930686K(1865088K)] [PSOldGen: 5595037K->5595024K(5595136K)] 6527571K->6525710K(7460224K) [PSPermGen: 16488K->16487K(21504K)], 12.2488150 secs] [Times: user=12.25 sys=0.00, real=12.24 secs] 66885.098: [Full GC [PSYoungGen: 932608K->932608K(1865088K)] [PSOldGen: 5595024K->5595024K(5595136K)] 6527632K->6527632K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 9.6745600 secs] [Times: user=9.66 sys=0.01, real=9.67 secs] 66894.773: [Full GC [PSYoungGen: 932608K->932488K(1865088K)] [PSOldGen: 5595024K->5595023K(5595136K)] 6527632K->6527512K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 11.8445420 secs] [Times: user=11.85 sys=0.00, real=11.85 secs] 66906.623: [Full GC [PSYoungGen: 932608K->932608K(1865088K)] [PSOldGen: 5595023K->5595023K(5595136K)] 6527631K->6527631K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 9.6006950 secs] [Times: user=9.60 sys=0.00, real=9.60 secs] 66916.224: [Full GC [PSYoungGen: 932608K->932488K(1865088K)] [PSOldGen: 5595023K->5595023K(5595136K)] 6527631K->6527512K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 9.6498320 secs] [Times: user=9.65 sys=0.00, real=9.65 secs] 66925.881: [Full GC [PSYoungGen: 932608K->0K(1865088K)] [PSOldGen: 5595023K->4133351K(5595136K)] 6527631K->4133351K(7460224K) [PSPermGen: 16487K->16487K(21504K)], 6.8990990 secs] [Times: user=6.90 sys=0.00, real=6.90 secs]
The first five lines appear to show the garbage collector completely failing to make any progress. According to my understanding of the JVM, this should result in an OutOfMemoryError, but I don't see anything like that in the logs. Is it possible that something (at the JVM level) is preventing them from being thrown? Or maybe either Jetty or my application is suppressing them?
Thanks for your advice!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
尝试显式设置该选项，或设置 -XX:GCHeapFreeLimit。这些选项的文档非常薄弱，并且可能无法准确反映您正在运行的 JVM 的行为。 （或者相关选项的默认值可能已更改。）
Try explicitly setting the option, or setting -XX:GCHeapFreeLimit instead. The documentation for these options is pretty thin, and may not exactly reflect the behavior of the JVM you are running. (Or maybe the defaults for relevant options have changed.)