Java垃圾收集“真实的”时间比“用户”要大得多。 “系统”
这就是启用了 verbose gc 的 full gc 的样子 -
13463.547: [Full GC [PSYoungGen: 323053K->0K(325952K)]
[PSOldGen: 653170K->331738K(655360K)] 976224K->331738K(981312K)
[PSPermGen: 238715K->238715K(264448K)], 385.4631490 secs]
[Times: user=2.19 sys=1.35, real=385.50 secs]
实时时间怎么可能比 user + sys 大这么多？
我的第一个想法是垃圾收集器正在等待资源，但这个资源似乎不是 IO 或 CPU，因为当 gc 发生时，“top”输出没有显示任何 cpu 或内存问题。
That's how full gc with verbose gc enabled looks like -
13463.547: [Full GC [PSYoungGen: 323053K->0K(325952K)]
[PSOldGen: 653170K->331738K(655360K)] 976224K->331738K(981312K)
[PSPermGen: 238715K->238715K(264448K)], 385.4631490 secs]
[Times: user=2.19 sys=1.35, real=385.50 secs]
How can the real time be so much bigger than user + sys?
My first thought was that garbage collector is waiting for a resource, but this resource does not seem to be IO or CPU, as "top" output doesn't show any cpu or memory problems when the gc occurs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
要进行完整收集，您需要停止所有线程。 （它调用停止世界集合的原因之一）
停止所有线程可能需要很长时间，特别是如果您有数千个线程。每个线程都必须到达“安全点”才能停止它。
这种行为通常意味着您有太多线程。您还可以考虑 ConcurrenntMarkSweep 收集器或新的 G1 收集器，它们不需要经常停止应用程序。
For a full collection to occur, you need to stop all the threads. (One of the reasons it call a stop the world collection)
Stopping all your threads can take a long time, esp if you have thousands of them. Each thread has to reach a "safepoint" to stop it.
This sort of behaviour usually means you have too many threads. You might also consider ConcurrenntMarkSweep collector or the new G1 collector which doesn't need to stop the application as often.
尝试阅读此内容（白皮书中包含更多链接）：Java 1.5 GC 内部结构 .
我想大多数事情对于 Java 1.6 VM 仍然有效，并且它提供了关于 GC 如何工作的深刻见解。
另请阅读：调整 JVM 1.6 堆空间
基准的白皮书链接，但我找不到它:( :/
我会尝试看看它是否会在某个地方弹出，但我猜它位于 Oracle 网站的某个位置）
（还有另一个带有说明性 ，不要因为某些原因而尝试不同的选项，看看它是如何工作的，除非您的性能提升超过 10%，并且您的应用程序至关重要，否则请不要混淆太多细节。 >原因很简单：只需几个 LOC 进行简单的代码重写就可以显着改变 GC 的行为。
慢慢来，玩得开心:)
Try reading this (more links included to whitepaper): Java 1.5 GC Internals.
I guess most things are still valid for Java's 1.6 VM and it gives a great insight as how the GC works.
Also, read this: Tuning JVM's 1.6 Heap space
( there is also another white paper link with an illustrative benchmark but I just can't find it :( :/
I'll try and see if it pops up somewhere but I guess it's located somewhere in Oracle's website )
In general, don't get freaky. Try and experiment with different options based by some rationale and see how it works. Unless you have a > 10% performance gain and your application is critical try not to mingle with a lot of details.
The reason is simple: A simple code rewrite in just a few LOCs may change dramatically your GC's behaviour.
Take your time and have fun! :)