点击这里，查看常见内存分析思路及其他重要内容
简介：今天，齐光将会基于之前列举的众多指标，给出一些常见的调优分析思路，即：如何在众多异常性能指标中，找出最核心的那一个，进而定位性能瓶颈点，最后进行性能调优。整篇文章会按照代码、CPU、内存、网络、磁盘等方向进行组织，针对对某一各优化点，会有系统的「套路」总结，便于思路的迁移实践。
1. 代码相关
遇到性能问题，首先应该做的是检查否与业务代码相关——不是通过阅读代码解决问题，而是通过日志或代码，排除掉一些与业务代码相关的低级错误。性能优化的最佳位置，是应用内部。
譬如，查看业务日志，检查日志内容里是否有大量的报错产生，应用层、框架层的一些性能问题，大多数都能从日志里找到端倪（日志级别设置不合理，导致线上疯狂打日志）；再者，检查代码的主要逻辑，如 for 循环的不合理使用、NPE、正则表达式、数学计算等常见的一些问题，都可以通过简单地修改代码修复问题。
别动辄就把性能优化和缓存、异步化、JVM 调优等名词挂钩，复杂问题可能会有简单解，「二八原则」在性能优化的领域里里依然有效。当然了，了解一些基本的「代码常用踩坑点」，可以加速我们问题分析思路的过程，从 CPU、内存、JVM 等分析到的一些瓶颈点优化思路，也有可能在代码这里体现出来。
下面是一些高频的，容易造成性能问题的编码要点。
1）正则表达式非常消耗 CPU（如贪婪模式可能会引起回溯），慎用字符串的 split()、replaceAll() 等方法；正则表达式表达式一定预编译。
2）String.intern() 在低版本（Java 1.6 以及之前）的 JDK 上使用，可能会造成方法区（永久代）内存溢出。在高版本 JDK 中，如果 string pool 设置太小而缓存的字符串过多，也会造成较大的性能开销。
3）输出异常日志的时候，如果堆栈信息是明确的，可以取消输出详细堆栈，异常堆栈的构造是有成本的。注意：同一位置抛出大量重复的堆栈信息，JIT 会将其优化后成，直接抛出一个事先编译好的、类型匹配的异常，异常堆栈信息就看不到了。
4）避免引用类型和基础类型之间无谓的拆装箱操作，请尽量保持一致，自动装箱发生太频繁，会非常严重消耗性能。
5）Stream API 的选择。复杂和并行操作，推荐使用 Stream API，可以简化代码，同时发挥来发挥出 CPU 多核的优势，如果是简单操作或者 CPU 是单核，推荐使用显式迭代。
6）根据业务场景，通过 ThreadPoolExecutor 手动创建线程池，结合任务的不同，指定线程数量和队列大小，规避资源耗尽的风险，统一命名后的线程也便于后续问题排查。
7）根据业务场景，合理选择并发容器。如选择 Map 类型的容器时，如果对数据要求有强一致性，可使用 Hashtable 或者 「Map + 锁」 ；读远大于写，使用 CopyOnWriteArrayList；存取数据量小、对数据没有强一致性的要求、变更不频繁的，使用 ConcurrentHashMap；存取数据量大、读写频繁、对数据没有强一致性的要求，使用 ConcurrentSkipListMap。
8）锁的优化思路有：减少锁的粒度、循环中使用锁粗化、减少锁的持有时间(读写锁的选择)等。同时，也考虑使用一些 JDK 优化后的并发类，如对一致性要求不高的统计场景中，使用 LongAdder 替代 AtomicLong 进行计数，使用 ThreadLocalRandom 替代 Random 类等。
代码层的优化除了上面这些，还有很多就不一一列出了。我们可以观察到，在这些要点里，有一些共性的优化思路，是可以抽取出来的，譬如：
空间换时间：使用内存或者磁盘，换取更宝贵的CPU 或者网络，如缓存的使用；
时间换空间：通过牺牲部分 CPU，节省内存或者网络资源，如把一次大的网络传输变成多次；
其他诸如并行化、异步化、池化技术等。
2. CPU 相关
前面讲到过，我们更应该关注 CPU 负载，CPU 利用率高一般不是问题，CPU 负载 是判断系统计算资源是否健康的关键依据。
2.1 CPU 利用率高&&平均负载高
这种情况常见于 CPU 密集型的应用，大量的线程处于可运行状态，I/O 很少，常见的大量消耗 CPU 资源的应用场景有：
正则操作
数学运算
序列化/反序列化
反射操作
死循环或者不合理的大量循环
基础/第三方组件缺陷
排查高 CPU 占用的一般思路：通过 jstack 多次（> 5次）打印线程栈，一般可以定位到消耗 CPU 较多的线程堆栈。或者通过 Profiling 的方式（基于事件采样或者埋点），得到应用在一段时间内的 on-CPU 火焰图，也能较快定位问题。
还有一种可能的情况，此时应用存在频繁的 GC （包括 Young GC、Old GC、Full GC），这也会导致 CPU 利用率和负载都升高。排查思路：使用 jstat -gcutil 持续输出当前应用的 GC 统计次数和时间。频繁 GC 导致的负载升高，一般还伴随着可用内存不足，可用 free 或者 top 等命令查看下当前机器的可用内存大小。
CPU 利用率过高，是否有可能是 CPU 本身性能瓶颈导致的呢？也是有可能的。可以进一步通过 vmstat 查看详细的 CPU 利用率。用户态 CPU 利用率（us）较高，说明用户态进程占用了较多的 CPU，如果这个值长期大于50%，应该着重排查应用本身的性能问题。内核态 CPU 利用率（sy）较高，说明内核态占用了较多的 CPU，所以应该着重排查内核线程或者系统调用的性能问题。如果 us + sy 的值大于 80%，说明 CPU 可能不足。
2.2 CPU 利用率低&&平均负载高
如果CPU利用率不高，说明我们的应用并没有忙于计算，而是在干其他的事。CPU 利用率低而平均负载高，常见于 I/O 密集型进程，这很容易理解，毕竟平均负载就是 R 状态进程和 D 状态进程的和，除掉了第一种，就只剩下 D 状态进程了（产生 D 状态的原因一般是因为在等待 I/O，例如磁盘 I/O、网络 I/O 等）。
排查&&验证思路：使用 vmstat 1 定时输出系统资源使用，观察 %wa(iowait) 列的值，该列标识了磁盘 I/O 等待时间在 CPU 时间片中的百分比，如果这个值超过30%，说明磁盘 I/O 等待严重，这可能是大量的磁盘随机访问或直接的磁盘访问（没有使用系统缓存）造成的，也可能磁盘本身存在瓶颈，可以结合 iostat 或 dstat 的输出加以验证，如 %wa(iowait) 升高同时观察到磁盘的读请求很大，说明可能是磁盘读导致的问题。
此外，耗时较长的网络请求（即网络 I/O）也会导致 CPU 平均负载升高，如 MySQL 慢查询、使用 RPC 接口获取接口数据等。这种情况的排查一般需要结合应用本身的上下游依赖关系以及中间件埋点的 trace 日志，进行综合分析。
2.3 CPU 上下文切换次数变高
先用 vmstat 查看系统的上下文切换次数，然后通过 pidstat 观察进程的自愿上下文切换（cswch）和非自愿上下文切换（nvcswch）情况。自愿上下文切换，是因为应用内部线程状态发生转换所致，譬如调用 sleep()、join()、wait()等方法，或使用了 Lock 或 synchronized 锁结构；非自愿上下文切换，是因为线程由于被分配的时间片用完或由于执行优先级被调度器调度所致。
如果自愿上下文切换次数较高，意味着 CPU 存在资源获取等待，比如说，I/O、内存等系统资源不足等。如果是非自愿上下文切换次数较高，可能的原因是应用内线程数过多，导致 CPU 时间片竞争激烈，频频被系统强制调度，此时可以结合 jstack 统计的线程数和线程状态分布加以佐证。
1、 内存相关
前面提到，内存分为系统内存和进程内存（含 Java 应用进程），一般我们遇到的内存问题，绝大多数都会落在进程内存上，系统资源造成的瓶颈占比较小。对于 Java 进程，它自带的内存管理自动化地解决了两个问题：如何给对象分配内存以及如何回收分配给对象的内存，其核心是垃圾回收机制。
垃圾回收虽然可以有效地防止内存泄露、保证内存的有效使用，但也并不是万能的，不合理的参数配置和代码逻辑，依然会带来一系列的内存问题。此外，早期的垃圾回收器，在功能性和回收效率上也不是很好，过多的 GC 参数设置非常依赖开发人员的调优经验。比如，对于最大堆内存的不恰当设置，可能会引发堆溢出或者堆震荡等一系列问题。
下面看看几个常见的内存问题分析思路。
关键字：设计模式 缓存 JavaScript 网络协议 前端开发 Java API 调度 Perl 容器
