JVM调优的目的
其实“调优”是一个诊断和处理手段，我们最终的目标是让系统的处理能力，也就是“性能”达到最优化
如何进行JVM调优
大致过程如下：
- 量化性能相关指标，然后对系统问题进行排查
- 排查出问题，如：系统延迟和抖动增加，偶尔宕机，这说明JVM配置不合理
- 针对问题对症下药，如：针对配置不合理的问题，我们需要对JVM配置进行调整，如果问题比较严重是否进行系统重构和调整，同时提出对日常运维的要求和建议
- 最后经过我们的调优，系统延迟降低，不在抖动，不再宕机
量化性能相关指标
量化性能指标是一个标准化判断依据的过程，根据量化性能指标我们能够有效指出那些指标与平常不同存在问题
要排查问题，那么我们就要直到哪里出了问题，一般我们需要对下面这些方面进行排查：
- 分析系统性能问题： 比如是不是达到了我们预期性能指标，判断资源层面有没有问题，JVM 层面有没有问题，系统的关键处理流程有没有问题，业务流程是否需要优化；
- 通过工具收集系统的状态，日志，包括打点做内部的指标收集，监控并得出关键性能指标数据，也包括进行压测，得到一些相关的压测数据和性能内部分析数据；
- 根据分析结果和性能指标，进行资源配置调整，并持续进行监控和分析，以优化性能，直到满足系统要求，达到系统的最佳性能状态。
计算机系统中，性能相关的资源主要分为这几类:
- CPU：CPU是系统最关键的计算资源，在单位时间内有限，也是比较容易由于业务逻辑处理不合理而出现瓶颈的地方，浪费了CPU资源和过渡消耗CPU资源都不是理想状态，我们需要监控相关指标；
- 内存：内存则对应程序运行时直接可使用的数据快速暂存空间，也是有限的，使用过程随着时间的不断的申请内存又释放内存，好在 JVM 的 GC 帮我们处理了这些事情，但是如果 GC 配置的不合理，一样会在一定的时间后，产生包括 OOM 宕机之类的各种问题，所以内存指标也需要关注；
- IO（存储+网络）：CPU在内存中把业务逻辑计算以后，为了长期保存，就必须通过磁盘存储介质持久化，如果多机环境、分布式部署、对外提供网络服务能力，那么很多功能还需要直接使用网络，这两块的 IO 都会比 CPU 和内存速度更慢，所以也是我们关注的重点。
性能优化中常见的套路
性能优化一般存在瓶颈问题，而瓶颈问题都遵循80/20原则，即把所有的整个处理过程中比较慢的因素都列一个清单，并按照对性能的影响排序，那么前 20% 的瓶颈问题，至少会对性能的影响占到 80% 比重。换句话说，我们优先解决了最重要的几个问题，那么性能就能好一大半。
一般我们像排查性能资源是否称为瓶颈问题，看资源够不够，只要成本允许，加配置可能是最快速的解决方案，还可能是最划算，最有效的解决方案。 与 JVM 有关的系统资源，主要是 CPU 和 内存 这两部分。 如果发生资源告警/不足, 就需要评估系统容量，分析原因。
衡量性能的维度
- 延迟，一般指响应用户请求的平均时间，但是响应时间一般抖动的特别厉害（即部分用户的响应时间特别高）这时我们一般需要保证95线或99线，即保证95%或99%以上的用户在可接收的范围内响应，另外在用户请求量巨大的时候，最大响应时间可能变得非常大，所以最大响应时间这个指标一般不可靠，我们一般不用
- 吞吐量：一般对于交易类的系统我们使用每秒处理的事务数(TPS)来衡量吞吐能力，对于查询搜索类的系统我们也可以使用每秒处理的请求数（QPS）。
- 系统容量：也叫做设计容量，可以理解为硬件配置，成本约束
一般只要系统架构允许，增加硬件配置一般都能提升性能指标，但随着摩尔定律的失效，增加硬件配置并不能得到线性的性能提升，比如增加一倍的内存容量并不能带来一倍的性能提升，所以目前来说，整体上使用分布式的解决办法，以及局部上对每个系统进行分析调优，是性价比最高的选择。
同时性能指标还可以分为两类：
业务需求指标：如吞吐量(QPS、TPS)、响应时间(RT)、并发数、业务成功率等。 资源约束指标：如 CPU、内存、I/O 等资源的消耗情况。
一般批处理/流处理系统更关注吞吐量, 延迟可以适当放宽，而高可用 Web 系统，既关注高并发情况下的系统响应时间，也关注吞吐量
性能调优的手段
我们可采用的手段和方式包括：
- 使用 JDWP 或开发工具做本地/远程调试
- 系统和 JVM 的状态监控，收集分析指标
- 性能分析: CPU 使用情况/内存分配分析
- 内存分析: Dump 分析/GC 日志分析
- 调整 JVM 启动参数，GC 策略等等
总结
性能调优的第一步是制定指标，收集数据，第二步是找瓶颈，然后分析解决瓶颈问题。通过这些手段，找当前的性能极限值。压测调优到不能再优化了的 TPS 和 QPS，就是极限值。知道了极限值，我们就可以按业务发展测算流量和系统压力，以此做容量规划，准备机器资源和预期的扩容计划。最后在系统的日常运行过程中，持续观察，逐步重做和调整以上步骤，长期改善改进系统性能。
注意：过早的优化是万恶之源，不能脱离实际应用场景做优化，虽然目前的性能不是很好，但能满足实际生产，那么就没必要做优化，除此之外当系统的性能优化到 3000TPS 如果已经可以在成本可以承受的范围内满足业务发展的需求，那么再花几个人月优化到 3100TPS 就没有什么意义，同样地如果花一倍成本去优化到 5000TPS 也没有意义。
因为考虑到实际生产，那么就要综合考虑成本和性能的平衡