JVM GC调优基础

垃圾收集(GC)中的性能指标

延迟时间(Latency)

在日常开发中，经常会有这样的需求，要求用户的某个操作，必须在1秒内得到响应，这个时候首先需要确认的是，垃圾收集(GC)造成的暂停时间是否占用得过多，若GC造成的暂停时间仅几十毫秒，则可以尝试从其他层面去作优化处理，比如外部数据源，锁争用等问题，事实证明，这些问题可能会比GC问题出现得更多。假设，现在的性能需求是：90%的操作的响应时间必须小于1000ms，没有任何操作的响应时间大于10000ms，并假设GC停顿占用的时间不能超过10%，即90%的GC暂停时间不能超过100ms，没有一次GC的暂停时间超过1000ms。如下面的GC日志：

[Full GC (Ergonomics) [PSYoungGen: 93677K- >70109K(254976K)] [ParOldGen: 499597K->511230K(761856K)] 593275K->581339K(1016832K), [Metaspace: 2936K->2936K(1056768K)], 0.0713174 secs] [Times: user=0.21 sys=0.02, real=0.07 secs    

本次GC的暂停时间为0.0713174 secs，尽管耗费的总CPU时间为0.21 secs，但我们更专注的是应用暂停时间，由于采用的是并行垃圾收集器，真实耗时仅0.07 secs，满足了延迟性能需求。

吞吐量(Throughput)

与延迟时间不同，吞吐量更关注垃圾收集(GC)在应用运行时所占用的时间比。假设，现在性能的需求是：系统每分钟处理1000次事务，要求GC占用的总时间不能超过10%，即6s。如上面的GC日志，一次GC耗时0.07 secs，若一分钟内的GC次数 * 70ms不超过6000ms，也满足了吞吐量性能需求。

容量(Capacity)

容量要求对运行时环境作出更改(如调整内存大小，限制成本等)，以达到延迟和吞吐量的性能需求。