php购物网站设计代码做曖免费网站
GC简介：
GC(Garbage Collection)是java中的垃圾回收机制，是Java与C++/C的主要区别之一，在使用JAVA的时候，一般不需要专门编写内存回收和垃圾清理代 码。这是因为在Java虚拟机中，存在自动内存管理和垃圾清扫机制。
什么时候GC?
什么时候发生GC？
什么时候full GC?
什么情况下会发生Full GC？
GC类型：
-
Serial GC：为单核CPU上的桌面应用设计的。使用Serial GC会明显的损耗应用的性能。
参数-XX:+UseSerialGC
就是Young区和old区都使用serial 垃圾回收算法， -
Parallel GC：Parallel GC适用于多核CPU且使用了较大内存空间的场景。Parallel GC又被称为"高吞吐GC(throughput GC)“
参数-XX:+UseParallelGC
Young区：使用Parallel scavenge 回收算法
Old 区：可以使用单线程的或者Parallel 垃圾回收算法，由 -XX:+UseParallelOldGC 来控制 -
Parallel Old GC(Parallel Compacting GC)
Parallel的GC算法是为老年代设计的。 -
Concurrent Mark & Sweep GC (or “CMS”)
低延迟GC，适用于所有应用对响应时间要求比较严格的场景。
与其他GC相比，CMS GC要求更多的内存空间和CPU资源
CMS GC默认不提供内存压缩
参数-XX:+UseConcMarkSweepGC
Young区：可以使用普通的或者parallel 垃圾回收算法，由参数 -XX:+UseParNewGC来控制
Old 区：只能使用Concurrent Mark Sweep -
Garbage First (G1) GC
G1最大的改进在于其性能表现，它比以上任何一种GC都更快速
参数：-XX:+UseG1GC
没有young/old区
不同区域用到的算法
什么是GC监控？
GC监控 指的是在运行时跟踪JVM运行GC的过程。例如，通过GC监控，我们能找出：
- 何时新生代的对象会被移动到老年代，有多少对象被移到了老年代。
- 何时stop-the-world发生以及持续时间。
- 通过GC监控，能发现JVM是否在有效的运行GC以及是否需要额外的GC调优。基于这些信息，我们可以通过优化应用或者改变GC运行方式(GC调优)，从而提高应用性能
如何做GC监控？
jstat: Java Virtual Machine Statistics Monitoring Tool
在使用-gcutil选项时，会输出如下字段的信息。在做GC调优时，尤其要关注YGC, YGCT, FGC, FGCT和GCT的数据变化。
[root@hadoop1012 ~]# jstat -gcutil 1845 3000 100S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.0230.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.0230.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.0230.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.0230.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.0230.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.0230.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.0230.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.0230.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.0230.00 100.00 35.86 6.50 95.92 87.40 1 0.023 0 0.000 0.023YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)
新生代的GC大概需要平均时间 YGCT/YGC
老生代的GC大概需要平均时间 FGCT/FGC
在监控的里FullGC发生0次(FGC)，FullGC所用时间为0ms(FGCT)，YGC 1次，所用时间：YGCT为0.023s
当Full GC < 半小时/次且Fulll GC time < 1s，可认为GC工作良好。
•Minor GC执行迅速(50毫秒以内)
•Minor GC执行不频繁(间隔10秒左右一次)
•Full GC执行迅速(1秒以内)
•Full GC执行不频繁(间隔10分钟左右一次)
如不满足，则说明GC有优化的空间，但不是必须，需结合实际业务处理速度来看。
如GC进行优化，则需进行长时间的稳定性测试，同时监控GC的指标来判断GC优化的有效性。
两种监控方式：
在使用-verbosegc时还可同时指定以下附加选项：
- -XX:+PrintGCDetails 可以详细了解GC中的变化
- -XX:+PrintGCTimeStamps 可以了解这些垃圾收集发生的时间，自JVM启动以后以秒计量。
- -XX:+PrintHeapAtGC 了解堆的更详细的信息
- -XX:+PrintGCDateStamps(JDK6U4引入的选项) GC发生的时间信息
- -Xloggc:$CATALINA_BASE/logs/gc.log GC日志产生的路径
- -XX:+PrintGCApplicationStoppedTime 输出GC造成应用暂停的时间
如果只指定-verbosegc选项，则默认会同时指定-XX:+PrintGCDetails。
另外，-verbosegc的附加选项都可以组合使用。
日志输出格式说明
- 当有minor GC发生时：
[GC [<collector>:
<starting occupancy1> -> <ending occupancy1>, <pause time1> secs]
<starting occupancy3> -> <ending occupancy3>, <pause time3> secs]
- Full GC输出的例子
[Full GC [Tenured: 3485K->4095K(4096K), 0.1745373 secs] 61244K->7418K(63104K), [Perm : 10756K->10756K(12288K)], 0.1762129 secs] [Times: user=0.19 sys=0.00, real=0.19 secs]
推荐JVM的选项
先监控GC状态
后分析监控数据并决定是否需要GC调优
参考博文：https://segmentfault.com/a/1190000004369016?utm_source=sf-backlinks