声明：本文为学习总结篇，参考资料见文末，如有侵权请联系作者，调优实践总结篇可参考以往文章：JVM学习笔记与调优实战系列总结文章，感谢阅读~
一、 定义
性能是指系统的响应能力，即经过多长时间才能对某个事件做出响应，或者在某个整个内系统所能处理的事件的个数。
从性能的角度看，通常关注三个方面，内存占用（footprint）、延时（latency）和吞吐量（throughput）。
性能调优是指通过优化设计方案、调整参数配置、修改相关代码达到业务、运维、开发各方期望。
大多数情况下，很难同时兼顾三个不同的角度，一般会侧重于其中一个或者两个，并以此作为调优目标。当然除了通常的三个方面，也可能需要考虑其他GC相关的场景，如，OOM可能与某些不合理的GC参数有关。
二、 思路
调优过程分成三大步：性能监控、性能分析、性能优化。
性能监控：不侵入系统代码，分析运行日志：了解业务运转流程及节点，收齐网络、操作系统、容器各项数据，预估性能所在点。
通俗来说，就是掌握JVM和GC的状态，定位具体的问题，确定是否真的需要进行调优，常见手段有很多，比如，通过visualVM、jstat等诊断工具来查看GC日志（dump文件），判断GC相关状态。
性能分析：修改相关配置、屏蔽代码降级或增加资源，验证性能所在点。
例如，通过追踪GC日志，查找是不是GC在特定时间发生了长时间的暂停，进而导致了应用响应不及时；或者在诊断工具里面查看是否存在死循环或者连接池缓冲区满了，进而导致堆内存溢出问题。
性能优化：优化方案或修改代码实现，解决达到性能目标的瓶劲。
即通过分析来确定具体的调整参数或者软硬件配置，并验证是否达到调优目标，否则重复完整以上过程。
三、 约定
性能调优是为达到多方期望。各方及其期望如下：
业务角度的“业务指标”：关注并发用户数、TPS、成功率、响应时间。
运维角度的“资源指标”：关注CPU、内存、磁盘I/O、网络I/O。
开发角度的“应用指标”：关注空闲线程数、数据库连接数、GC/FULL GC次数、函数耗时。
DBA角度的“数据指标”：关注耗时SQL、锁、会话、cpu、异常事件、tps。
性能调优是对具体的程序或用户使用过程进行，对于程序与使用过程进行如下约定：
接口：程序模块之间的一次请求与响应。
场景：系统对一次用户操作的完整响应或商户系统的服务端请求完整响应。场景的响应由一个或多个系统接口来完成。
性能调优以“多个程序模块按一定数目比例组成一组服务节点”为单元进行场景的分析、优化、验证及扩展。
当出现以下情况，可视为系统存在性能瓶劲：
1、应用程序或操作系统cpu使用率超过45%。
2、内存超过4G，10分钟压力范围内出现多次垃圾回收时间超过平均响应时间，引发tps趋势图波动。
3、场景响应时间超过2秒，tps提上去、响应时间开始往下掉，成功率低于99.99%。
4、空闲内存少，分页交换内存使用占比达到30%。
5、10分钟压测试范围内，tps趋势图形出现波峰、波谷。
四、 分析及解决
性能瓶劲的主要因素：网络设备（带宽、新建连接数、并发连接数），操作系统（可用端口数、端口复用及回收时间），应用程序及其容器（连接池获取及日志输出锁、网络访问阻塞、代码调用链路长、垃圾回收次数多且耗时长），数据库（会话数、异常事件、锁、内存）。
性能监控
1、运行单个节点、收齐日志，理清业务的所有系统调用链接（RPC）：确定压测环境单节点、预估场景/接口的关键节点。
2、运行场景压测脚本，查看系统运行状况：通过jconsole远程连接上应用程序查看其cpu、内存、线程使用情况。通过”jstack 应用程序进程号“ 命令查看应用程序的线程使用情况（weblogic 对应的命令是 :"jrcmd 应用程序进程号 print_threads“）。以了解工作的线程数及其工作状态（lock资源）、cpu使用情况、垃圾回收情况。
3、核实压力传递状态：通过netstat -at | grep 客户端ip地址 | wc -l 监控压力的透传情况。锁定性能发生点。(备注：系统之间使用长链接，随着压力增大，系统间的连接数达到最大值则不增长；短链接则不断上涨)。
4、监控操作系统（linux）资源。查看系统负载（top命令）、监控内存使用情况（watch -n 1 -d vmstat）、监控网卡流量（watch -n 1 -d ifconfig）、监控网络状态（netstat –at）、监控磁盘读写（watch -n 1 -d iostat）、监控应用程序错误日志(tail –f 200 应用程序错误日志文件名 )。
性能分析
通过修改操作系统内核（/etc/sysctl.conf）相关配置( net.ipv4.tcp_max_tw_buckets 、net.ipv4.tcp_fin_timeout 、net.ipv4.tcp_synack_retries 、net.core.netdev_max_backlog),调整运行容器（tomcat、weblogic）工作线程、支撑连接数，修改jvm内存大小、垃圾回收策略、工作参数配置，修改应用程序日志级别、异步输出，连接池数目，应用程序代码加入开关、降低服务，优化数据库索引、表结构，确认性能瓶颈问题、原因及解决办法。
性能优化
根据性能分析及验证的改动，进行要应实现，达到期望值。
性能应对方案
业务设计方面：
1）分离业务：申请与受理分离，申请受理权利、业务异步处理；
2）服务降级。
应用程序方面：
1）升级资源（内存、连接沲连接数目、cpu核数、工作线程数）；
2）横向扩展；
3）jvm参数优化（垃圾回收策略、运行参数设置）；
4）代码优化（日志异步输出、业务辅助功能异步处理、缓存、RPC调用合并、减少调用节点链路、使用连接池/长链接、降代方法调用层级、减少大数据对象的构建）；
5）负载保护（指定IP访问量、整体受理量）。
网络节点方面：扩张流量、限制流量、负载保护。
五、 测试环境构建
测试环境网络及应用部署架构与生产环境架构完全相同，软件版本完全相同（主要包括：操作系统、中间件、数据库、应用等），测试环境参数配置与生产环境完全相同（主要包括：操作系统参数、中间件参数、数据库参数、应用参数），测试环境基础数据量与生产环境基础数据量需在同一个数量级、测试环境机型与生产环境机型尽量相同部署规模按生产环境的1/2或1/4（能验证节点横向扩展性）。
参考资料：
1、作者：竿牍，原文链接：https://www.jianshu.com/p/465efe89e18c
2、极客时间《Java核心知识36讲》