我读了一本书（Java性能：The Definitive Guide“，作者Scott Oaks＆＃34;），无论使用哪种GC算法，年轻的收集器总是停止世界和单线程。 如果这是真的，为什么与老式收藏品相比，年轻的收藏品总是花费的时间可以忽略不计？ 是因为年轻的发源空间比oldgen小吗？ （如果是，GC的时间与堆量相关的时间如何 - 指数？）
如果初始堆大小（-Xms）的值较小且上限（-Xmx）较大，则达到初始限制时会发生什么？ 是否JVM会执行完整的GC，还是会增加堆大小，直到达到-Xmx限制为止？
答案 0 :(得分：3)
我在一本书中读到，无论使用哪种GC算法，年轻的收藏家总是停止世界。
或多或少，是的。但是除了SerialGC之外，它们是多线程的，因此在问题上投入更多核心会使年轻的集合在相同数量的内存中更快。
如果这是真的，那么为什么这个年轻人的收藏总是比旧收藏品花费的时间可以忽略不计？
并不总是可以忽略不计，年轻一代的大小因素有很多因素可以考虑
是不是因为年轻的宇宙空间比oldgen小？
在某种程度上是的，但它不仅仅是大小，活动对象的比例也很重要。如果对象快速死亡，则无需访问/复制。
如果是，GC的时间与堆量相关的时间如何 - 指数？
这取决于。如果我们谈论暂停时间，那就相当复杂了。如果我们谈论完整GC烧毁（包括并发）的CPU周期，它与活动对象的数量大致呈线性关系。如果我们谈论的是整个CPU周期（而不是每个GC），它会再次变得更加复杂。
但无论如何，它不是指数级的。在垃圾收集上花费的CPU周期数通常应该是相对于在应用程序代码上花费的CPU周期的一小部分。但如上所述，CPU周期！=暂停时间。
当初始堆大小（-Xms）和较大上限（-Xmx）的值较小时，达到初始限制时会发生什么？是否JVM会执行完整的GC，还是会增加堆大小，直到达到-Xmx限制为止？
取决于所选的GC和各种其他设置。我建议您只使用GCViewer
观察GC进一步阅读：
这主要是针对oracle / openjdk的热点。存在其他JVM和其他收集器。最有趣的选择是azul的zing，它有效pauseless collector