聊聊“JVM 调优JVM 性能优化”是怎么个事？
所谓“调优”就是一个诊断和处理手段，最终的目标是让系统的处理能力，也就是“性能”达到最优化。
计算机系统中，性能相关的资源主要分为这几类：
CPU：CPU 是系统最关键的计算资源，在单位时间内有限，也是比较容易由于业务逻辑处理不合理而出现瓶颈的地方，浪费了 CPU 资源和过渡消耗 CPU 资源都不是理想状态，需要监控相关指标；内存：内存则对应程序运行时直接可使用的数据快速暂存空间，也是有限的，使用过程随着时间的不断的申请内存又释放内存，JVM 的 GC处理了这些事情，但是如果 GC 配置的不合理，一样会在一定的时间后，产生包括 OOM 宕机之类的各种问题，所以内存指标也需要关注；IO（存储+网络）：CPU 在内存中把业务逻辑计算以后，为了长期保存，就必须通过磁盘存储介质持久化，如果多机环境、分布式部署、对外提供网络服务能力，那么很多功能还需要直接使用网络，这两块的 IO 都会比 CPU 和内存速度更慢，所以也是关注的重点。
性能优化中常见的套路
衡量系统性能的三个维度：
延迟(Latency)： 一般衡量的是响应时间(Response Time)，比如平均响应时间。但是有时候响应时间抖动的特别厉害，也就是说有部分用户的响应时间特别高，一般假设要保障 95% 的用户在可接受的范围内响应，从而提供绝大多数用户具有良好的用户体验，这就是延迟的95线（P95，平均 100 个用户请求中 95 个已经响应的时间），同理还有99线，最大响应时间等（95 线和 99 线比较常用；用户访问量大的时候，对网络有任何抖动都可能会导致最大响应时间变得非常大，最大响应时间这个指标不可控，一般不用）。吞吐量(Throughput)： 一般对于交易类的系统使用每秒处理的事务数(TPS)来衡量吞吐能力，对于查询搜索类的系统可以使用每秒处理的请求数（QPS）。系统容量(Capacity)： 也叫做设计容量，可以理解为硬件配置，成本约束。
性能指标还可分为两类:
- 业务需求指标：如吞吐量(QPS、TPS)、响应时间(RT)、并发数、业务成功率等。
- 资源约束指标：如 CPU、内存、I/O 等资源的消耗情况。
可采用的手段和方式包括：
- 使用 JDWP 或开发工具做本地/远程调试
- 系统和 JVM 的状态监控，收集分析指标
- 性能分析: CPU 使用情况/内存分配分析
- 内存分析: Dump 分析/GC 日志分析
- 调整 JVM 启动参数，GC 策略等等
性能调优总结
性能调优的第一步是制定指标，收集数据，第二步是找瓶颈，然后分析解决瓶颈问题。通过这些手段，找当前的性能极限值。压测调优到不能再优化了的 TPS 和 QPS，就是极限值。知道了极限值，就可以按业务发展测算流量和系统压力，以此做容量规划，准备机器资源和预期的扩容计划。最后在系统的日常运行过程中，持续观察，逐步重做和调整以上步骤，长期改善改进系统性能。
两句真言：
“脱离场景谈性能都是耍流氓”，实际的性能分析调优过程中，需要根据具体的业务场景，综合考虑成本和性能，使用最合适的办法去处理。系统的性能优化到 3000TPS 如果已经可以在成本可以承受的范围内满足业务发展的需求，那么再花几个人月优化到 3100TPS 就没有什么意义，同样地如果花一倍成本去优化到 5000TPS 也没有意义。
“过早的优化是万恶之源”，需要考虑在恰当的时机去优化系统。在业务发展的早期，量不大，整体架构、功能实现最重要，性能没那么重要。最后再考虑性能的优化工作。如果一开始就考虑优化，就可能要想太多导致过度设计。而且主体框架和功能完成之前，可能会有比较大的改动，一旦提前做了优化，可能这些改动导致原来的优化都失效了，又要重新优化，多做了很多无用功。