JVM 性能调优之预估调优与问题排查

JVM 调优分类

调优是一个很大的概念，简单说就是把系统进行优化，但是站在一个系统的角度，能够干的事情太多了，我们一般把 JVM 调优分成以下三类：

 JVM 预调优

 优化 JVM 运行环境（慢、卡顿等）

 解决 JVM 中的问题（OOM 等）

调优中，现象最明显的是 OOM，因为有异常抛出，当然它也只是作为调优的一部分。预调优和优化运行环境估计很多人做的就是服务器重启而已。

JVM 预调优

业务场景设定

调优是要分场景的，所以一定要明显你调优项目的场景设定，像现在大家都是微服务架构了，服务拆分出来以后更加适合做场景设定。比如这个服务就注重吞吐量，这个服务注重用户的体验（用户的响应时间）等等。

无监控不优化

这里的监控指的是压力测试，能够看到结果，有数据体现的，不要用感觉去优化，所有的东西一定要有量化的指标，比如吞吐量，响应时间，服务器资源，网络资源等等。总之一句话，无监控不优化。

处理步骤

计算内存需求

计算内存需求，内存不是越大越好，对于一般系统来说，内存的需求是弹性的，内存小，回收速度快也能承受。所以内存大小没有固定的规范。虚拟机栈的大小在高并发情况下可以变小。

元空间（方法区）保险起见还是设定一个最大的值（默认情况下元空间是没有大小限制的），一般限定几百 M 就够用了，为什么说还限定元空间。

举例子：一台 8G 的内存的服务器，如果运行时还有其他的程序加上虚拟机栈加上元空间，占用超过 6 个 G 的话，那么我们设定堆是弹性的（max=4G），那么其实堆空间拓展也超不过 2G，所以这个时候限制元空间还是有必要的。

选定 CPU

对于系统来说， CPU 的性能是越高越好，这个按照你的预算来定（CPU 的成本很高）。

尤其是现在服务器做了虚拟机化之后，虚拟机的性能指标不能单看虚拟化后的参数指标，更应该看实际物理机的情况。

选择合适的垃圾回收器

对于吞吐量优先的场景，就只有一种选择，就是使用 PS 组合（Parallel Scavenge+Parallel Old ）。

对于响应时间优先的场景，在 JDK1.8 的话优先 G1，其次是 CMS 垃圾回收器。

设定新生代大小、分代年龄

吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的新生代和一个较小的老年代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而老年代尽存放长期存活对象。

设定日志参数

-XX:+PrintGC 输出 GC 日志

-XX:+PrintGCDetails 输出 GC 的详细日志

-XX:+PrintGCTimeStamps 输出 GC 的时间戳（以基准时间的形式）

-XX:+PrintGCDateStamps 输出 GC 的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）

-XX:+PrintHeapAtGC 在进行 GC 的前后打印出堆的信息

-Xloggc:../logs/gc.log 日志文件的输出路径

注意：一般记录日志的是，如果只有一个日志文件肯定不行，有时候一个高并发项目一天产生的日志文件就上 T，其实记录日志这个事情，应该是运维干的事情。日志文件帮助我们分析问题。

优化 JVM 运行环境（慢、卡顿等）

一般造成 JVM 卡或者慢的原因无非两个部分，一个是 CPU 占用过高，一个是内存占用过高。所以这个时候需要我们进行问题的排查，进行具体的故障分析。

解决 JVM 中的问题（OOM 等）

前面章节讲过，见：内存溢出（重点）

---

亿级流量电商系统 JVM 调优

亿级流量系统

亿级流量系统，其实就是每天点击量在亿级的系统，根据淘宝的一个官方的数据分析。

每个用户一次浏览点击 20~40 次之间，推测出每日活跃用户（日活用户）在 500 万左右。

同时结合淘宝的一个点击数据，可以发现，能够付费的也就是橙色的部分（cart）的用户，比例只有 10%左右。

90%的用户仅仅是浏览，那么我们可以通过图片缓存、Redis 缓存等技术，我们可以把 90%的用户解决掉。

10%的付费用户，大概算出来是每日成交 50 万单左右。