如何减少长时间的 GC 停顿？
垃圾回收是非常重要的，但处理不好，反而会成为性能杀手，采用以下步骤确保GC停顿时间最少且最短，一般50ms以下。
长时间的GC停顿对应用非常不友好，不仅影响服务的级别（SLA），而且用户的体验也会下降，对核心应用程序的服务造成不可估量的损害。
以下针对各种原因进行分析及解决方法
1.高速率创建对象
如果应用程序的对象创建率很高，那么为了跟上它，垃圾回收率也会升高，高垃圾回收率也会增加GC停顿时间，因此，优化应用程序以创建更少的对象是减少GC停顿的有效策略，但它是个耗时工作，并且需要修改代码，可行性不高，不过如果时间充裕，还是值得去做的，查看对象创建率可以通过JVisualVM，也可以将GC日志上传GCEasy在线分析，可以得到如下信息：
- 创建了哪些对象？
- 创建这些对象的速率是多少？
- 它们占用内存多少空间？
- 谁在创建它们？
始终尝试去优化占用最大内存量的对象。
2.年轻代空间不足
当年轻代过小时，对象会过早地进入老年代，从老年代收集垃圾比从年轻代收集垃圾耗时要多，因此，增加年轻代的大小有可能减少长时间的GC停顿，可以通过设置JVM参数增加年轻代的大小。
**-Xmn** ：指定年轻代的大小。**-XX:NewRatio** ：指定年轻代相对于老年代的大小比例。例如，设置 -XX:NewRatio=2 表示年轻代与老年代之间的比率为 1:2。年轻代的大小将是整个堆的 1/3。因此，如果堆大小为 2 GB，则年轻代大小将为 2G / 3 = 667 MB。
3.选择GC算法
GC算法对GC停顿时间也有很大的影响，如果你是 GC 专家或打算成为一个（或你的团队中的有人是 GC 专家），你可以调整 GC 参数配置以获得最佳 GC 停顿时间。如果你没有大量的 GC 的专业知识，那么我建议使用 G1 GC 算法，因为它有自动调节的能力。在 G1 中，可以使用系统属性 -xx：MaxGCPauseMillis来设置 GC 预期最大停顿时间。例如：
-XX:MaxGCPauseMillis=200
按照上面的例子。最大的GC停顿时间设置为200ms,这是一个目标，JVM将尽力去实现它。
4.进程使用了Swap
有时由于物理内存不足（RAM），操作系统可能将应用程序暂时不用的数据从内存交换出去。这个交换动作是非常昂贵的，因为它需要访问磁盘，这比物理内存访问要慢得多。
建议在生产环境中，任何一个重要的应用程序都不应该交换，当进程使用了Swap时，GC将需要很长的世界才能完成。下面的脚本来自StackOverflow（感谢作者），当执行脚本时，将显示所有正在发生交换的进程，请确保你的应用进程没有使用Swap。
#!/bin/bash
# Get current swap usage for all running processes
# Erik Ljungstrom 27/05/2011
# Modified by Mikko Rantalainen 2012-08-09
# Pipe the output to "sort -nk3" to get sorted output
# Modified by Marc Methot 2014-09-18
# removed the need for sudo
SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"`
do
PID=`echo $DIR | cut -d / -f 3`
PROGNAME=`ps -p $PID -o comm --no-headers`
for SWAP in `grep VmSwap $DIR/status 2>/dev/null | awk '{ print $2 }'`
do
let SUM=$SUM+$SWAP
done
if (( $SUM > 0 )); then
echo "PID=$PID swapped $SUM KB ($PROGNAME)"
fi
let OVERALL=$OVERALL+$SUM
SUM=0
done
echo "Overall swap used: $OVERALL KB"
如果发现进程使用了Swap分区，则可以执行下列操作之一：
- 分配更多的物理内存
- 减少在服务器上运行的进程的数量，以便它可以释放内存（RAM）
- 减少应用程序的堆大小（我不建议这么做，可能会导致其他副作用，不过，它可能会解决你的问题）
5.调整GC线程数
对于 GC 日志中报告的每个 GC 事件，会打印用户、系统和实际执行时间。例如：
[Times: user=25.56 sys=0.35, real=20.48 secs]
如果在 GC 事件中，您始终注意到 real 时间并不显著小于 user 时间，那么它可能指示没有足够的 GC 线程。考虑增加 GC 线程数。假设 user 时间为 25s，并且将 GC 线程计数配置为 5，那么 real 应该接近 5s（因为 25s/5＝5s）。
警告：添加太多的 GC 线程将消耗大量 CPU，从而占用应用程序的资源。因此，在增加 GC 线程数之前，需要进行充分的测试。
6.后台I/O活动
如果有大量的文件系统 I/O 活动（即发生大量的读写操作），也可能导致长时间的 GC 停顿。此繁重的文件系统 I/O 活动可能不是由应用程序引起的。可能是由于运行在同一服务器上的另一进程造成的。但它仍然会导致应用程序遭受长时间的 GC 停顿。
当有严重的 I/O 活动时，你会注意到 real 的时间明显高于 user 的时间。例如：
[Times:user=0.20 sys=0.01, real=18.45 secs]
当这种情况发生时，以下是一些可能的解决方案：
- 如果高 I/O 活动是由应用程序引起的，那么优化它。
- 消除在服务器上导致高 I/O 活动的进程。
- 将应用程序移动到 I/O 活动较少的其他服务器。
提示: 如何监视 I/O 活动
在类 Unix系统 中，你可以使用的 SAR 命令（系统活动情况报告）监视 I/O 活动。例如：
sar -d -p 1
上面的命令每 1 秒会报告一次读取/秒和写入/秒的统计数据。有关 SAR 命令的更多细节，可以自行参阅相关资料。
7. System.gc()调用
当调用 System.gc() or Runtime.getRuntime().gc() 方法时，它将导致 stop-the-world 的 Full GC。在 Full GC 期间，整个 JVM 被冻结（即在此期间不会执行任何用户活动）。System.gc() 调用一般来源于以下情况：
1、 开发人员可能会显式地调用 System.gc() 方法。2、 使用的第三方库、框架，有时甚至是应用程序服务器。其中任何一个都可能调用 System.gc() 方法。3、 还可以通过使用 JMX 从外部工具（如 VisualVM）触发。4、 如果你的应用程序正在使用 RMI，那么 RMI 会定期调用 System.gc() 。可以使用以下系统属性配置此调用间隔：
-Dsun.rmi.dgc.server.gcInterval=n
-Dsun.rmi.dgc.client.gcInterval=n
评估是否显式调用 System.gc() 是绝对必要的。如果不需要，请把它删掉。另一方面，可以通过传递 JVM 参数来强制禁用 System.gc() 调用 -XX:+DisableExplicitGC。
提示：如何知道是否显示调用了 System.gc()
将 GC 日志上传到通用 GC 日志分析器工具GCeasy。此工具有一个名为 GCCauses的部分。如果由于System.gc()调用而触发 GC 活动，则此部分将报告该情况。请看下图（摘自 GCeasy 生成的报告目录），显示了 System.gc() 在这个应用程序的生命周期中被做了四次。
警告：所有上述战略只有经过彻底的测试和分析才能推广到生产。所有策略可能不一定适用于你的应用程序。如果不当使用可能会导致负面的结果。
参考:GCEasy原文