Java中垃圾收集的频率是多少？ [英] What the frequency of the Garbage Collection in Java?
问题描述
$ b
年轻一代的收藏发生得相对频繁，并且是
高效和快速，因为年轻一代的空间通常很小
，并且可能包含大量不再被引用的对象。
在某些数量年轻一代的收藏品最终被提升或终身服务于
老一代。参见图1.这一代人的年龄通常比年轻一代还要大，而其入住率b b增长速度更慢。因此，老一代的收藏品并不多见，但要花费更长的时间才能完成
$ b $ p
$ b $ p有人可以定义什么 em>频繁和频繁在上面的语句中是指？我们正在谈论微秒，毫秒，分钟，天？
解决方案对此的确切答案。它确实取决于很多因素，包括平台（JVM版本，设置等），应用程序和工作负载。
在一个极端情况下，对于应用程序永远不会触发垃圾回收器。它可能简单地坐在那里什么也不做，或者它可能执行一个非常长的计算，在JVM初始化和应用程序启动后没有创建任何对象。
另一方面，理论上可以用于一个垃圾收集结束，另一个在几纳秒内开始 。例如，如果您的应用程序处于从完整堆中死亡的最后阶段，或者它正在分配病态的大型数组，则可能发生这种情况。
所以：
我们说的是微秒，毫秒，分钟，天吗？
可能所有上述情况，尽管如果您在实践中观察到前两者肯定会令人困扰。
表现良好的应用程式不应该经常运行GC。如果您的应用程序每秒触发一次或两次以上的年轻空间收集，则可能会导致性能问题。过于频繁的全面收藏更糟，因为它们的影响力更大。然而，对于设计不当的/实现的应用程序来说，这样做肯定是有道理的。
还有一个问题： GC运行间隔并不总是有意义的。例如，一些HotSpot GC实际上具有与普通应用程序线程并行运行的GC线程。如果您拥有足够的内核，足够的内存和足够的内存总线带宽，那么一个持续运行的并行GC可能不会明显影响应用程序的性能（达到某一点）。
Page 6 of the the document Memory Management in the Java HotSpot™ Virtual Machine contains the following paragraphs:
Young generation collections occur relatively frequently and are efficient and fast because the young generation space is usually small and likely to contain a lot of objects that are no longer referenced.
Objects that survive some number of young generation collections are eventually promoted, or tenured, to the old generation. See Figure 1. This generation is typically larger than the young generation and its occupancy grows more slowly. As a result, old generation collections are infrequent, but take significantly longer to complete
Could someone please define what "frequent" and "infrequent" mean in the statements above? Are we talking microseconds, milliseconds, minutes, days?
解决方案It is not possible to give a definite answer to this. It really depends on a lot of factors, including the platform (JVM version, settings, etc), the application, and the workload.
At one extreme, it is possible for an application to never trigger a garbage collector. It might simply sit there doing nothing, or it might perform an extremely long computation in which no objects are created after the JVM initialization and application startup.
At the other extreme it is theoretically possible for one garbage collection end and another one to start within few nanoseconds. For example, this could happen if your application is in the last stages of dying from a full heap, or if it is allocating pathologically large arrays.
So:
Are we talking microseconds, milliseconds, minutes, days?
Possibly all of the above, though the first two would definitely be troubling if you observed them in practice.
A well behaved application should not run the GC too often. If your application is triggering a young space collection more than once or twice a second, then this could lead to performance problems. And too frequent "full" collections is worse because their impact is greater. However, it is certainly plausible for a poorly designed / implemented application to behave like this.
There is also the issue that the interval between GC runs is not always meaningful. For instance some of the HotSpot GCs actually have GC threads running in parallel with normal application threads. If you have enough cores, enough RAM and enough memory bus bandwidth, then a constantly running parallel GC may not appreciably affect application performance (up to a point).
这篇关于Java中垃圾收集的频率是多少？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
