问题标签 [g1gc]

在 Java 6 中，我们曾经使用以下 GC 配置来防止OutOfMemoryException在多次重新部署我们的应用后使用 Perm Gen：

-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled

我们正在迁移到 Java 7 并希望使用新的 G1 GC，根据我的阅读，它将类从 Java 内存中的 PermGen 移动到本机内存。

是否有一些标志可以卸载未使用的类？

据我了解，在使用 G1 GC 时，堆被划分为一组大小相等的堆区域。
JVM 如何在区域中分配新对象？选择哪个区域进行分配？

我有一个在独立 JVM 中运行的 Java 应用程序。该应用程序在一个或多个套接字上侦听数据，对数据进行排队，并安排线程将数据从队列中拉出并持久化。数据很宽，每条记录有超过 700 个数据元素，尽管所有数据元素都是小字符串、整数或长整数。

该应用程序可以平稳运行一段时间，有时是 30 分钟到一个小时，但随后我们会遇到一个或多个长时间的垃圾收集暂停。大部分暂停时间都花在对象复制时间上。相对于其他集合，系统时间也很高。

这是JVM详细信息：

以下是 JVM 选项：

该过程是 4 个核心的任务集（全部在同一个插槽上），但几乎不使用其中的 2 个。这个盒子上的所有进程都固定在它们自己的核心上（0 和 1 未使用）。机器有大量可用内存（20+G），上图显示使用2.5G RES内存的进程。

这是一些 gc 日志输出...

关于为什么对象复制时间和系统时间如此之高以及如何纠正它的任何想法？日志中有许多垃圾收集，它们的 Eden/Survivors/Heap 大小几乎相同，只需要 10 或 20 毫秒。

我们有一个相当大的应用程序在 JBoss 7 应用服务器上运行。过去，我们使用 ParallelGC，但它在一些堆很大（5 GB 或更多）且通常几乎被填满的服务器上给我们带来了麻烦，我们会经常遇到很长的 GC 暂停。

最近，我们改进了应用程序的内存使用，并在少数情况下为运行应用程序的一些服务器添加了更多 RAM，但我们也开始切换到 G1，希望减少这些暂停的频率和/或更短。事情似乎有所改善，但我们看到了一个以前没有发生过的奇怪行为（使用 ParallelGC）：Perm Gen 似乎很快就被填满了，一旦达到最大值，就会触发 Full GC，这通常会导致长时间的停顿在应用程序线程中（在某些情况下，超过 1 分钟）。

几个月来，我们一直在使用 512 MB 的最大 perm 大小，在我们的分析过程中，使用 ParallelGC 时，perm 大小通常会停止增长到 390 MB 左右。然而，在我们切换到 G1 之后，上述行为开始发生。我尝试将最大 perm 大小增加到 1 GB 甚至 1.5 GB，但仍然会发生 Full GC（它们只是不太频繁）。

在此链接中，您可以看到我们正在使用的分析工具（YourKit Java Profiler）的一些屏幕截图。请注意，当触发 Full GC 时，Eden 和 Old Gen 有很多可用空间，但 Perm 大小是最大的。在 Full GC 之后，Perm 的大小和加载的类的数量急剧减少，但它们又开始上升并重复循环。代码缓存很好，永远不会超过 38 MB（在这种情况下是 35 MB）。

这是 GC 日志的一部分：

2013-11-28T11：15：57.774-0300：64445.415：[完整 GC 2126M->670M(5120M)，23.6325510 秒] [伊甸园：4096.0K(234.0M)->0.0B(256.0M) 幸存者：22.0M- >0.0B 堆：2126.1M(5120.0M)->670.6M(5120.0M)] [时间：用户=10.16 系统=0.59，实际=23.64 秒]

您可以在此处查看完整的日志（从我们启动服务器的那一刻起，直到完整 GC 后的几分钟）。

以下是一些环境信息：

java版本“1.7.0_45”

Java(TM) SE 运行时环境 (build 1.7.0_45-b18)

Java HotSpot(TM) 64 位服务器 VM（内部版本 24.45-b08，混合模式）

启动选项：-Xms5g -Xmx5g -Xss256k -XX:PermSize=1500M -XX:MaxPermSize=1500M -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicy -Xloggc:gc.log

所以这是我的问题：

• 这是 G1 的预期行为吗？我在网上找到另一个帖子，有人质疑非常相似的事情，并说 G1 应该在 Perm Gen 上执行增量收集，但没有答案......

• 我们的启动参数有什么可以改进/纠正的吗？服务器有 8 GB 的 RAM，但我们似乎并不缺乏硬件，应用程序的性能很好，直到触发完整的 GC，这就是用户体验大滞后并开始抱怨的时候。

Java7 的 G1 垃圾收集器和 Mono 的 SGen 垃圾收集器的主要区别是什么？我知道它们都是分代 GC，但它们在性能方面和架构方面有何不同？

我的应用程序部署在 Solaris 上运行的 weblogic 上，采用双 SPARC T4 8 核 3.0 GHz。这个 weblogic 实例正在使用 g1 gc，我认为可以改进当前配置：

让我感到震惊的是，ConcGCThreads 已设置，但也没有为 ParallelGCThreads 建立值。我认为让这两个值显示一个合理的比例是一个好的开始。甲骨文的文档说：

-XX:ParallelGCThreads=n

设置 STW 工作线程的值。将 n 的值设置为逻辑处理器的数量。n 的值与最大为 8 的逻辑处理器的数量相同。

如果有超过 8 个逻辑处理器，则将 n 的值设置为逻辑处理器的大约 5/8。这在大多数情况下都有效，但较大的 SPARC 系统除外，其中 n 的值可能约为逻辑处理器的 5/16。

没有关于什么是“逻辑处理器”的明确声明。我在网上搜索了一下，貌似可以理解为运行在物理处理器或内核中的线程。根据http://www.oracle.com/technetwork的说法，该 wl 运行的机架中的“逻辑处理器”数量因此将达到 128 个（2 个 8 核处理器“能够在 8 个线程之间切换” /server-storage/sun-sparc-enterprise/documentation/o11-090-sparc-t4-arch-496245.pdf）。

但有人告诉我，这 128 个“逻辑处理器”中有 64 个是为数据库保留的，其余的被共享用于运行 Tuxedo 和 weblogic 服务器。假设有两个 weblogic 实例，并且认为 tuxedo 和 wl 实例消耗相同数量的线程是安全的，可以认为 (64/3)*(5/16) ~= 6 或 7 ParallelGCThreads 和因此 1 个或最多 2 个 ConcGCThreads 是可以接受的。

您认为这些是开始调整的合理值吗？欢迎任何建议。

编辑：截至今天，我已经生成了一些启用 GCDetails 的日志。这是它在 gc 查看器中的外观

我的解释：

• 随着用户执行任务，堆使用量缓慢增长
• 终身堆使用（蓝色锯齿形下方的洋红色线代表整体已用堆）也可以，尽管在终身代中仍有相当多的可用空间
• 恰恰相反，年轻代堆的边缘非常稀缺，需要稳定地进行垃圾收集
• 尽管这张照片没有立即令人不安的地方，但趋势是向上的。此外：gc 暂停时间（如果不涉及初始标记，则略多于 1s，否则几乎为 2s）远长于 300ms 的目标目标

只是垃圾收集日志的显示：

到目前为止，还没有出现疏散失败、巨大的对象分配或完全垃圾收集的情况。如果要阻止服务器，除了引发完整的 gc 之外别无选择。

有8个并行worker；由于 ConcGCThreads 设置为 4，我想我可以设置 ParallelGCThreads=16 或将 ConcGCThreads 减少到 2。不确定哪个选项更好，可能是前者。但它可能毕竟不是那么重要。

参考处理时间一直很长。著名的 Beckwith 文章提到：

如果您在参考处理期间看到高时间，请通过启用命令行上的以下选项 -XX:+ParallelRefProcEnabled 来打开并行参考处理。

这是我绝对认为我应该做而且肯定会做的事情。

然而，主要问题是如何减少 gc 暂停的长度。更高的 ParallelGCThreads 可能会有所帮助，但也许这个问题与过于雄心勃勃的暂停时间有关；正如 Oracle 教程所说：

不要使用平均响应时间 (ART) 作为设置 XX:MaxGCPauseMillis= 的指标，而是考虑设置将在 90% 或更多时间满足目标的值。这意味着 90% 的发出请求的用户不会遇到高于目标的响应时间。请记住，暂停时间是一个目标，不能保证总是能达到。

所以我认为它也可以帮助设置一个更现实的 MaxGCPauseMillis，比如 600 毫秒。如果实现了这样的目标，大多数用户都会非常高兴。如果暂停时间超过 2 秒，他们可能不会。您认为该参数是否适合进一步调整或有其他建议？

问候

我有一个在 Hotspot JVM 上的 Java 7 update 45 上运行的应用程序。我正在尝试调整参数以适用于低延迟应用程序，以下是我为此运行设置的 JVM 参数。GC 日志中各个步骤的时间（大约 25 毫秒）不等于暂停时间（>600 毫秒）。我怎么知道是什么导致这个暂停时间如此之长？在大多数集合中，它们加起来很好，并且符合暂停时间目标。我偶尔会看到如此大的停顿，大约在 15-20 分钟内停顿一次（虽然不那么规律）。

-server -Xmx2g -Xms2g -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseG1GC -XX:MaxGCPauseMillis=30 -XX:ParallelGCThreads=9 -XX:ConcGCThreads=4 -XX:G1HeapRegionSize=4M -XX: InitiatingHeapOccupancyPercent=45 -XX:+PrintTLAB -XX:+AggressiveOpts -Xloggc:/integral/logs/gc.log -verbose:gc -XX:+PrintTenuringDistribution -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy -XX:+PrintGCDetails -XX :+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=3026 -Dcom.sun.management.jmxremote.local。只有=假-Dcom.sun.management.jmxremote.authenticate=假-Dcom.sun.management.jmxremote.ssl=假"

G1GC 日志将堆占用值打印为四舍五入到 MB 或 GB，有没有办法以KB 或 MB 打印所有值？

我想分析分配率和提升率，而这种四舍五入的值引入了不精确性。

例如，下面的 GC 事件显示总堆占用减少，其中仅显示收集前总堆大小 11.7G->1826.2M的四舍五入值。11.7G

使用的 VM 标志：

-Xms16g -Xmx16g -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

使用热点 JVM 1.8.0-b132。

我的服务器应用程序在负载下有时会无响应，我发现这个问题与很长的“GC 备注”有关。没有实施垃圾收集调整。我的测试服务器是 4 核/8 GB/8 GB 交换。

这是 gc 日志的日志输出。

在这种状态下，我尝试关闭交换，但这似乎无助于减少备注时间。还有另一台运行 4 GB 内存的测试服务器，而且情况更好更稳定。

关于如何改善这种情况的任何想法。

====== 编辑 - 从 -XX:+PrintGCDetails 添加日志 =========

==== 添加 -XX:+PrintReferenceGC 和 -XX:+ParallelRefProcEnabled 后编辑 ======

现在软引用占用了大部分时间。我找到了一个每秒创建大量软引用的代码部分。我将禁用它，看看它是否有帮助。

========== 编辑 - 从代码中删除软引用之后 ==========

通过修复代码删除软引用后，情况有了很大改善，现在 SoftRefernece 处理时间可以忽略不计！！！. 最后一个问题我仍然看到“JNI 弱参考”时间逐渐增加。我现在将调查这个问题。

在 G1 中使用 Java 1.6.0_45 我有一个几乎无限期运行 G1 收集器的应用程序。除此之外，这似乎浪费了一些 CPU，它还以我能找到的最低设置快速填充了我的 gc 日志。

我想知道这里发生了什么。正常吗？

这些是我的 JVM 标志：