预估性优化
估算系统QPS，每个请求会创建多少对象，占多少内存，机器配置选型，年轻代应该给多少内存，YGC触发频率，对象进入老年代的速率，老年代应该给多少内存，Full GC触发的频率。这些都是根据代码可大概合理预估的。
预估完成后，就能采用优化思路，先给自己的系统设置一些初始JVM参数。如堆内存大小，年轻代大小，Eden和Survivor的比例，老年代的大小，大对象的阈值，大龄对象进入老年代的阈值等。
优化思路很简单，尽量让：
$每次 YGC 后的存活对象 ＜ Survivor区/2 $
保证都留存在年轻代里。尽量不让对象进入老年代，以减少Full GC频率，避免频繁Full GC影响JVM性能。
系统压测时的JVM优化
一个新系统开发完后，会经过本地的单元测试，到系统集成测试，再到测试环境的功能测试，预发布环境的压力测试，要保证系统的功能全部正常。在一定压力下性能、稳定性和并发能力都正常，最后才会部署到生产环境运行。
关键环节就是预发布环境的压力测试，会使用一些压力测试工具模拟比如1000个用户同时访问系统，造成每秒500个请求的压力，然后看系统能否支撑住每秒500请求的压力。同时看系统各个接口的响应延时是否在比如200ms内或在数据库中模拟出来百万级单表数据，然后看系统是否还能稳定运行。
具体如何进行系统压测，不是我们这里要讲述的内容，大家自行百度一下“Java压力测试”，就会看到很多开源的工具，可以轻松模拟出N个用户同时访问你系统的场景，还能给你一份压力测试报告，告诉你系统可以支撑每秒多少请求，包括系统接口的响应延时。通常压测工具会对系统发起持续不断的请求，持续很长时间，比如几个小时，甚至几天时间。
所以此时完全就可以在这个环节，对测试机器运行系统，采用jstat分析模拟真实环境的压力下，JVM运行状态。
然后根据压测环境JVM运行状况，如发现对象过快进入老年代，就需要采用之前介绍的优化思路，合理调整新生代、老年代、Eden、Survivor各个区域的内存大小，保证对象尽量留在年轻代，不要过快进入老年代。
当对压测环境下的系统优化好JVM参数之后，观察Young GC和Full GC频率都很低，此时就可部署上线。
监控线上JVM
每天高峰、低峰期用jstat、jmap、jhat等工具观察线上系统的JVM运行是否正常，有无频繁Full GC的问题。有就优化，没有就平时每天都定时或每周都看看。
部署专门监控系统
如Zabbix、OpenFalcon、Ganglia，然后你部署的系统都可以把JVM统计项发送到这些监控系统里去。
此时你就可以在这些监控系统可视化的界面里，看到你需要的所有指标，包括你的各个内存区域的对象占用变化曲线，直接可以看到Eden区的对象增速，还会告诉你Young GC发生的频率以及耗时，包括老年代的对象增速以及Full GC的频率和耗时。
而且这些工具还允许你设置监控。即指定一个监控规则，比如线上系统的JVM，如果10分钟之内发生5 次以上Full GC，就需要发送报警给你。比如发送到你的邮箱、短信。
其实把这些命令行用好了，基本线上系统的JVM监控和优化都能搞定了。
线上运行系统，要不然用命令行工具手动监控，发现问题就优化，要不然就是依托公司监控系统，可视化查看日常系统的运行状态。
|
