JVM调优的正确姿势
本文简单说一说JVM应如何调优。
Java语言本身的成功，除了天时地利人和，JVM功不可没。
毫不夸张地说，JVM是现代软件工程最成功的案例之一。它规模庞大，代码极其复杂，但运行极其稳定可靠，所以，许多厂商的核心业务系统，才敢放心地用Java编写，运行在JVM之上。
因为JVM自带GC，又有无数可以微调的参数，所以，JVM调优，现在已经被当作Java面试的必考知识点，精通JVM调优参数的童鞋，可以冠名微操小王子。
写了这么多年的Java程序，很遗憾，我迄今为止只会用两个参数：XMS和XMX，能正确写出如下启动脚本：
java -Xms1g -Xmx2g -jar abc.jar
如果-server也算的话，一共会三，估计面试通过的概率不大。
我承认我对JVM调优几乎一无所知，原因在于，还没有遇到过性能问题必须通过JVM调优才能解决。
我发现喜欢研究JVM调优的两类人：
-
准备面试的；
-
自己写的烂代码想甩锅给JVM的。
绝大多数情况下，如果程序出现了性能问题，比如TPS上不去，内存撑爆了，最好自己冷静一下，先监控一下自己程序的日志和性能数据，如果这两个都没有，就一口咬定JVM有问题，有问题的很可能不是JVM，而是态度。
这并不是说JVM不会出问题，或者说JVM就肯定没有bug，而是说，软件领域，bug能不能尽可能地被发现然后修复，很大程度上取决于用的人是否足够多。这个世界上用JVM的人多还是用自己写的程序的人多？很明显，能被某个人发现的JVM的bug可能性很低，尤其是公司线上运行的JVM并不会追求最新版本。
那么JVM正确的调优方式是啥？我个人推荐四步走：
- 记录好日志；
- 对程序做好性能监控；
- 根据日志和性能监控数据修改程序；
- 使用专业工具通过不同的JVM参数进行压测并获得最佳配置。
根据我的个人经验，走完前三步，就可以高质量交付并下班回家了，第四步那是在有摸鱼时间的情况下才做。
这么多年我一共遇到过两次因为JVM参数引发的问题：
一次是某公司的超大型Java程序，导致PermGen OutOfMemoryError，那是JDK 1.6平台，原因很简单，编写的Java类数量太多了，撑爆了默认的128M的PermGen。解决方法也很简单，改成更大的512M（参数叫啥已经忘了，因为新版JVM没有PermGen限制了）。但是根本问题不是出在JVM，而是代码太垃圾，Java类的数量超多造成的。
另一次是因为TPS超高引起内存不足崩溃，但实际上内存有32G非常大，分配给JVM有30G，不可能用完。现实情况是EC2直接被干掉连日志都看不到了。如果手动把TPS降下来（每次sleep 1ms），就能以一定概率成功启动。后咨询AWS技术支持发现，原来是Kafka这货为了提高速度，用了大量的堆外内存结果在高TPS下爆了。解决方法也很简单，把JVM内存限制在系统内存的一半，给操作系统留出足够的内存。这次根本问题是代码性能太高但错误地设定了XMS和XMX造成的。
所以，绝大部分情况下，并不需要特意去调优JVM，因为那是最后一步的优化手段。即使真的需要，到时候再研究也不迟，因为时间是宝贵的，在解决自己程序的性能问题之前，不必在意JVM的性能。
