汇总一些日常开发中可能遇到的问题排查和性能优化的case。
Java诊断工具Arthas：https://alibaba.github.io/arthas/
遇到性能问题，首先应该做的是检查否与业务代码相关——不是通过阅读代码解决问题，而是通过日志(日志规范很重要！！！)或代码，排除掉一些与业务代码相关的低级错误。性能优化的最佳位置，是应用内部。
别动辄就把性能优化和缓存、异步化、JVM 调优等名词挂钩，复杂问题可能会有简单解，「二八原则」在性能优化的领域里里依然有效。当然了，了解一些基本的「代码常用踩坑点」，可以加速我们问题分析思路的过程，从 CPU、内存、JVM 等分析到的一些瓶颈点优化思路，也有可能在代码这里体现出来。
下面是一些高频的，容易造成性能问题的编码要点。
- 正则表达式非常消耗 CPU（如贪婪模式可能会引起回溯），慎用字符串的 split()、replaceAll() 等方法；正则表达式表达式一定预编译。
- String.intern() 在低版本（Java 1.6 以及之前）的 JDK 上使用，可能会造成方法区（永久代）内存溢出。在高版本 JDK 中，如果 string pool 设置太小而缓存的字符串过多，也会造成较大的性能开销。
- 输出异常日志的时候，如果堆栈信息是明确的，可以取消输出详细堆栈，异常堆栈的构造是有成本的。注意：同一位置抛出大量重复的堆栈信息，JIT 会将其优化后成，直接抛出一个事先编译好的、类型匹配的异常，异常堆栈信息就看不到了。
- 避免引用类型和基础类型之间无谓的拆装箱操作，请尽量保持一致，自动装箱发生太频繁，会非常严重消耗性能。
- 根据业务场景，通过 ThreadPoolExecutor 手动创建线程池，结合任务的不同，指定线程数量和队列大小，规避资源耗尽的风险，统一命名后的线程也便于后续问题排查。
- 根据业务场景，合理选择并发容器。如选择 Map 类型的容器时，如果对数据要求有强一致性，可使用 Hashtable 或者 「Map + 锁」 ；读远大于写，使用 CopyOnWriteArrayList；存取数据量小、对数据没有强一致性的要求、变更不频繁的，使用 ConcurrentHashMap；存取数据量大、读写频繁、对数据没有强一致性的要求，使用 ConcurrentSkipListMap。
- 锁的优化思路有：减少锁的粒度、循环中使用锁粗化、减少锁的持有时间(读写锁的选择)等。同时，也考虑使用一些 JDK 优化后的并发类，如对一致性要求不高的统计场景中，使用 LongAdder 替代 AtomicLong 进行计数，使用 ThreadLocalRandom 替代 Random 类等。
CPU 利用率高一般不是问题，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 利用率低而平均负载高，常见于 I/O 密集型进程，这很容易理解，毕竟平均负载就是 R 状态进程和 D 状态进程的和，除掉了第一种，就只剩下 D 状态进程了（产生 D 状态的原因一般是因为在等待 I/O，例如磁盘 I/O、网络 I/O 等）。
一般服务部署在容器上，不太会遇到这种case。
先用 vmstat 查看系统的上下文切换次数，然后通过 pidstat 观察进程的自愿上下文切换（cswch）和非自愿上下文切换（nvcswch）情况。自愿上下文切换，是因为应用内部线程状态发生转换所致，譬如调用 sleep()、join()、wait()等方法，或使用了 Lock 或 synchronized 锁结构；非自愿上下文切换，是因为线程由于被分配的时间片用完或由于执行优先级被调度器调度所致。
内存分为系统内存和进程内存（含 Java 应用进程），一般我们遇到的内存问题，绝大多数都会落在进程内存上，系统资源造成的瓶颈占比较小。对于 Java 进程，它自带的内存管理自动化地解决了两个问题：如何给对象分配内存以及如何回收分配给对象的内存，其核心是垃圾回收机制。
Java 应用内存占用 = Heap（堆区）+ Code Cache（代码缓存区) + Metaspace（元空间）+ Symbol tables（符号表）+ Thread stacks（线程栈区）+ Direct buffers（堆外内存）+ JVM structures（其他的一些 JVM 自身占用）+ Mapped files（内存映射文件）+ Native Libraries（本地库）+ ...
Java 进程的内存占用，可以使用 jstat -gc 命令查看，输出的指标中可以得到当前堆内存各分区、元空间的使用情况。
内存溢出是指应用新建一个对象实例时，所需的内存空间大于堆的可用空间。内存溢出的种类较多，一般会在报错日志里看到 OutOfMemoryError 关键字。常见内存溢出种类及分析思路如下：
- java.lang.OutOfMemoryError: Java heap space。原因：堆中（新生代和老年代）无法继续分配对象了、某些对象的引用长期被持有没有被释放，垃圾回收器无法回收、使用了大量的 Finalizer 对象，这些对象并不在 GC 的回收周期内等。一般堆溢出都是由于内存泄漏引起的，如果确认没有内存泄漏，可以适当通过增大堆内存。
- **java.lang.OutOfMemoryError：GC overhead limit exceeded。**原因：垃圾回收器超过98%的时间用来垃圾回收，但回收不到2%的堆内存，一般是因为存在内存泄漏或堆空间过小。
- java.lang.OutOfMemoryError: Metaspace或java.lang.OutOfMemoryError: PermGen space。排查思路：检查是否有动态的类加载但没有及时卸载，是否有大量的字符串常量池化，永久代/元空间是否设置过小等。
- java.lang.OutOfMemoryError : unable to create new native Thread。原因：虚拟机在拓展栈空间时，无法申请到足够的内存空间。可适当降低每个线程栈的大小以及应用整体的线程个数。此外，系统里总体的进程/线程创建总数也受到系统空闲内存和操作系统的限制，请仔细检查。注：这种栈溢出，和 StackOverflowError 不同，后者是由于方法调用层次太深，分配的栈内存不够新建栈帧导致。
内存泄漏的表现是：应用运行一段时间后，内存利用率越来越高，响应越来越慢，直到最终出现进程「假死」。
Java 内存泄漏可能会造成系统可用内存不足、进程假死、OOM 等，排查思路却不外乎下面两种：
- 通过 jmap 定期输出堆内对象统计，定位数量和大小持续增长的对象；
- 使用 Profiler 工具对应用进行 Profiling，寻找内存分配热点。
GC的各项指标，是衡量 Java 进程内存使用是否健康的重要标尺。垃圾回收最核心指标：GC Pause（包括 MinorGC 和 MajorGC） 的频率和次数，以及每次回收的内存详情。什么时候需要进行 GC 调优？这取决于应用的具体情况，譬如对响应时间的要求、对吞吐量的要求、系统资源限制等。一些经验：GC 频率和耗时大幅上升、GC Pause 平均耗时超过 500ms、Full GC 执行频率小于1分钟等，如果 GC 满足上述的一些特征，说明需要进行 GC 调优了。
由于垃圾回收器种类繁多，针对不同的应用，调优策略也有所区别，因此下面介绍几种通用的的 GC 调优策略。
**1）选择合适的 GC 回收器。**根据应用对延迟、吞吐的要求，结合各垃圾回收器的特点，合理选用。推荐使用 G1 替换 CMS 垃圾回收器，G1 的性能是在逐步优化的，在 8GB 内存及以下的机器上，其各方面的表现也在赶上甚至有超越之势。G1 调参较方便，而 CMS 垃圾回收器参数太过复杂、容易造成空间碎片化、对 CPU 消耗较高等弊端，也使其目前处于废弃状态。Java 11 里新引入的 ZGC 垃圾回收器，基本可用做到全阶段并发标记和回收，值得期待。
**2）合理的堆内存大小设置。**堆大小不要设置过大，建议不要超过系统内存的 75%，避免出现系统内存耗尽。最大堆大小和初始化堆的大小保持一致，避免堆震荡。新生代的大小设置比较关键，我们调整 GC 的频率和耗时，很多时候就是在调整新生代的大小，包括新生代和老年代的占比、新生代中 Eden 区和 Survivor 区的比例等，这些比例的设置还需要考虑各代中对象的晋升年龄，整个过程需要考虑的东西还是比较多的。如果使用 G1 垃圾回收器，新生代大小这一块需要考虑的东西就少很多了，自适应的策略会决定每一次的回收集合（CSet）。新生代的调整是 GC 调优的核心，非常依赖经验，但是一般来说，Young GC 频率高，意味着新生代太小（或 Eden 区和 Survivor 配置不合理），Young GC 时间长，意味着新生代过大，这两个方向大体不差。实践中，一般来说用本地cache时，老年代大小可以设置得大一些。
**3）降低 Full GC 的频率。**如果出现了频繁的 Full GC 或者 老年代 GC，很有可能是存在内存泄漏，导致对象被长期持有，通过 dump 内存快照进行分析，一般能较快地定位问题。除此之外，新生代和老年代的比例不合适，导致对象频频被直接分配到老年代，也有可能会造成 Full GC，这个时候需要结合业务代码和内存快照综合分析。
1）查看系统当前网络连接数
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'2）查看堆内对象的分布 Top 50（定位内存泄漏）
jmap –histo:live $pid | sort-n -r -k2 | head-n 503）按照 CPU/内存的使用情况列出前10 的进程
#内存
ps axo %mem,pid,euser,cmd | sort -nr | head -10
#CPU
ps -aeo pcpu,user,pid,cmd | sort -nr | head -104）显示系统整体的 CPU利用率和闲置率
grep "cpu " /proc/stat | awk -F ' ' '{total = $2 + $3 + $4 + $5} END {print "idle \t used\n" $5*100/total "% " $2*100/total "%"}'5）按线程状态统计线程数(加强版)
jstack $pid | grep java.lang.Thread.State:|sort|uniq -c | awk '{sum+=$1; split($0,a,":");gsub(/^[ \t]+|[ \t]+$/, "", a[2]);printf "%s: %s\n", a[2], $1}; END {printf "TOTAL: %s",sum}';6）查看最消耗 CPU 的 Top10 线程机器堆栈信息
推荐大家使用 show-busy-java-threads 脚本，该脚本可用于快速排查 Java 的 CPU 性能问题(top us值过高)，自动查出运行的 Java 进程中消耗 CPU 多的线程，并打印出其线程栈，从而确定导致性能问题的方法调用，该脚本已经用于阿里线上运维环境。链接地址：https://github.com/oldratlee/useful-scripts/。
7）火焰图生成（需要安装 perf、perf-map-agent、FlameGraph 这三个项目）：
# 1. 收集应用运行时的堆栈和符号表信息（采样时间30秒，每秒99个事件）；
sudo perf record -F 99 -p $pid -g -- sleep 30; ./jmaps
# 2. 使用 perf script 生成分析结果，生成的 flamegraph.svg 文件就是火焰图。
sudo perf script | ./pkgsplit-perf.pl | grep java | ./flamegraph.pl > flamegraph.svg8）按照 Swap 分区的使用情况列出前 10 的进程
for file in /proc/*/status ; do awk '/VmSwap|Name|^Pid/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | head -109）JVM 内存使用及垃圾回收状态统计
#显示最后一次或当前正在发生的垃圾收集的诱发原因
jstat -gccause $pid
#显示各个代的容量及使用情况
jstat -gccapacity $pid
#显示新生代容量及使用情况
jstat -gcnewcapacity $pid
#显示老年代容量
jstat -gcoldcapacity $pid
#显示垃圾收集信息（间隔1秒持续输出）
jstat -gcutil $pid 100010）其他的一些日常命令
# 快速杀死所有的 java 进程
ps aux | grep java | awk '{ print $2 }' | xargs kill -9
# 查找/目录下占用磁盘空间最大的top10文件
find / -type f -print0 | xargs -0 du -h | sort -rh | head -n 10