线上故障次要会包含 cpu、磁盘、内存以及网络问题，而大多数故障可能会蕴含不止一个层面的问题，所以进行排查时候尽量四个方面顺次排查一遍。
同时例如 jstack、jmap 等工具也是不囿于一个方面的问题的，基本上出问题就是 df、free、top 三连，而后顺次 jstack、jmap 服侍，具体问题具体分析即可。
CPU
一般来讲咱们首先会排查 cpu 方面的问题。cpu 异样往往还是比拟好定位的。起因包含业务逻辑问题 (死循环)、频繁 gc 以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑) 导致的，能够应用 jstack 来剖析对应的堆栈状况。
应用 jstack 剖析 cpu 问题
咱们先用 ps 命令找到对应过程的 pid(如果你有好几个指标过程，能够先用 top 看一下哪个占用比拟高)。
接着用 top -H -p pid 来找到 cpu 使用率比拟高的一些线程
而后将占用最高的 pid 转换为 16 进制 printf '%x\n' pid 失去 nid
接着间接在 jstack 中找到相应的堆栈信息jstack pid |grep 'nid' -C5 –color
能够看到咱们曾经找到了 nid 为 0x42 的堆栈信息，接着只有仔细分析一番即可。
当然更常见的是咱们对整个 jstack 文件进行剖析，通常咱们会比拟关注 WAITING 和 TIMED_WAITING 的局部，BLOCKED 就不用说了。咱们能够应用命令 cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c 来对 jstack 的状态有一个整体的把握，如果 WAITING 之类的特地多，那么多半是有问题啦。
频繁 gc
当然咱们还是会应用 jstack 来剖析问题，但有时候咱们能够先确定下 gc 是不是太频繁，应用 jstat -gc pid 1000 命令来对 gc 分代变动状况进行察看，1000 示意采样距离(ms)，S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU 别离代表两个 Survivor 区、Eden 区、老年代、元数据区的容量和使用量。YGC/YGT、FGC/FGCT、GCT 则代表 YoungGc、FullGc 的耗时和次数以及总耗时。如果看到 gc 比拟频繁，再针对 gc 方面做进一步剖析。
上下文切换
针对频繁上下文问题，咱们能够应用 vmstat 命令来进行查看
cs(context switch)一列则代表了上下文切换的次数。
如果咱们心愿对特定的 pid 进行监控那么能够应用 pidstat -w pid 命令，cswch 和 nvcswch 示意被迫及非被迫切换。
磁盘
磁盘问题和 cpu 一样是属于比拟根底的。首先是磁盘空间方面，咱们间接应用 df -hl 来查看文件系统状态
更多时候，磁盘问题还是性能上的问题。咱们能够通过 iostatiostat -d -k - x 来进行剖析
最初一列 %util 能够看到每块磁盘写入的水平，而 rrqpm/ s 以及 wrqm/ s 别离示意读写速度，个别就能帮忙定位到具体哪块磁盘呈现问题了。
另外咱们还须要晓得是哪个过程在进行读写，一般来说开发本人心里有数，或者用 iotop 命令来进行定位文件读写的起源。
不过这边拿到的是 tid，咱们要转换成 pid，能够通过 readlink 来找到 pidreadlink -f /proc/*/task/tid/../..。
找到 pid 之后就可以看这个过程具体的读写状况 cat /proc/pid/io
咱们还能够通过 lsof 命令来确定具体的文件读写状况 lsof -p pid
内存
内存问题排查起来绝对比 CPU 麻烦一些，场景也比拟多。次要包含 OOM、GC 问题和堆外内存。一般来讲，咱们会先用 free 命令先来查看一发内存的各种状况。
堆内内存
内存问题大多还都是堆内内存问题。表象上次要分为 OOM 和 StackOverflow。
OOM
JMV 中的内存不足，OOM 大抵能够分为以下几种：
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
这个意思是没有足够的内存空间给线程调配 java 栈，基本上还是线程池代码写的有问题，比如说遗记 shutdown，所以说应该首先从代码层面来寻找问题，应用 jstack 或者 jmap。如果所有都失常，JVM 方面能够通过指定 Xss 来缩小单个 thread stack 的大小。
另外也能够在零碎层面，能够通过批改 /etc/security/limits.confnofile 和 nproc 来增大 os 对线程的限度
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
这个意思是堆的内存占用曾经达到 -Xmx 设置的最大值，应该是最常见的 OOM 谬误了。解决思路依然是先应该在代码中找，狐疑存在内存透露，通过 jstack 和 jmap 去定位问题。如果说所有都失常，才须要通过调整 Xmx 的值来扩充内存。
Caused by: java.lang.OutOfMemoryError: Meta space
这个意思是元数据区的内存占用曾经达到 XX:MaxMetaspaceSize 设置的最大值，排查思路和下面的统一，参数方面能够通过 XX:MaxPermSize 来进行调整(这里就不说 1.8 以前的永恒代了)。
Stack Overflow
栈内存溢出，这个大家见到也比拟多。
Exception in thread "main" java.lang.StackOverflowError
示意线程栈须要的内存大于 Xss 值，同样也是先进行排查，参数方面通过 Xss 来调整，但调整的太大可能又会引起 OOM。
应用 JMAP 定位代码内存透露
上述对于 OOM 和 StackOverflow 的代码排查方面，咱们个别应用 JMAPjmap -dump:format=b,file=filename pid 来导出 dump 文件
通过 mat(Eclipse Memory Analysis Tools)导入 dump 文件进行剖析，内存透露问题个别咱们间接选 Leak Suspects 即可，mat 给出了内存透露的倡议。另外也能够抉择 Top Consumers 来查看最大对象报告。和线程相干的问题能够抉择 thread overview 进行剖析。除此之外就是抉择 Histogram 类概览来本人缓缓剖析，大家能够搜搜 mat 的相干教程。
日常开发中，代码产生内存透露是比拟常见的事，并且比拟荫蔽，须要开发者更加关注细节。比如说每次申请都 new 对象，导致大量反复创建对象；进行文件流操作但未正确敞开；手动不当触发 gc；ByteBuffer 缓存调配不合理等都会造成代码 OOM。
另一方面，咱们能够在启动参数中指定 -XX:+HeapDumpOnOutOfMemoryError 来保留 OOM 时的 dump 文件。
gc 问题和线程
gc 问题除了影响 cpu 也会影响内存，排查思路也是统一的。个别先应用 jstat 来查看分代变动状况，比方 youngGC 或者 fullGC 次数是不是太多呀；EU、OU 等指标增长是不是异样呀等。
线程的话太多而且不被及时 gc 也会引发 oom，大部分就是之前说的 unable to create new native thread。除了 jstack 细细剖析 dump 文件外，咱们个别先会看下总体线程，通过 pstreee -p pid |wc -l。
或者间接通过查看 /proc/pid/task 的数量即为线程数量。
堆外内存
如果碰到堆外内存溢出，那可真是太可怜了。首先堆外内存溢出体现就是物理常驻内存增长快，报错的话视应用形式都不确定，如果因为应用 Netty 导致的，那谬误日志里可能会呈现 OutOfDirectMemoryError 谬误，如果间接是 DirectByteBuffer，那会报OutOfMemoryError: Direct buffer memory。
堆外内存溢出往往是和 NIO 的应用相干，个别咱们先通过 pmap 来查看下过程占用的内存状况 pmap -x pid | sort -rn -k3 | head -30，这段意思是查看对应 pid 倒序前 30 大的内存段。这边能够再一段时间后再跑一次命令看看内存增长状况，或者和失常机器比拟可疑的内存段在哪里。
咱们如果确定有可疑的内存端，须要通过 gdb 来剖析 gdb –batch –pid {pid} -ex “dump memory filename.dump {内存起始地址} {内存起始地址 + 内存块大小}”
获取 dump 文件后可用 heaxdump 进行查看 hexdump -C filename | less，不过大多数看到的都是二进制乱码。
NMT 是 Java7U40 引入的 HotSpot 新个性，配合 jcmd 命令咱们就能够看到具体内存组成了。须要在启动参数中退出 -XX:NativeMemoryTracking=summary 或者 -XX:NativeMemoryTracking=detail，会有稍微性能损耗。
个别对于堆外内存迟缓增长直到爆炸的状况来说，能够先设一个基线 jcmd pid VM.native_memory baseline。
而后等放一段时间后再去看看内存增长的状况，通过 jcmd pid VM.native_memory detail.diff(summary.diff)做一下 summary 或者 detail 级别的 diff。
能够看到 jcmd 剖析进去的内存非常具体，包含堆内、线程以及 gc(所以上述其余内存异样其实都能够用 nmt 来剖析)，这边堆外内存咱们重点关注 Internal 的内存增长，如果增长非常显著的话那就是有问题了。
detail 级别的话还会有具体内存段的增长状况，如下图。
此外在零碎层面，咱们还能够应用 strace 命令来监控内存调配 strace -f -e “brk,mmap,munmap” -p pid
这边内存调配信息次要包含了 pid 和内存地址。
不过其实下面那些操作也很难定位到具体的问题点，要害还是要看谬误日志栈，找到可疑的对象，搞清楚它的回收机制，而后去剖析对应的对象。比方 DirectByteBuffer 分配内存的话，是须要 full GC 或者手动 system.gc 来进行回收的(所以最好不要应用 -XX:+DisableExplicitGC)。
那么其实咱们能够跟踪一下 DirectByteBuffer 对象的内存状况，通过 jmap -histo:live pid 手动触发 fullGC 来看看堆外内存有没有被回收。如果被回收了，那么大概率是堆外内存自身调配的太小了，通过 -XX:MaxDirectMemorySize 进行调整。如果没有什么变动，那就要应用 jmap 去剖析那些不能被 gc 的对象，以及和 DirectByteBuffer 之间的援用关系了。
GC 问题
堆内内存透露总是和 GC 异样相伴。不过 GC 问题不只是和内存问题相干，还有可能引起 CPU 负载、网络问题等系列并发症，只是相对来说和内存分割严密些，所以咱们在此独自总结一下 GC 相干问题。
咱们在 cpu 章介绍了应用 jstat 来获取以后 GC 分代变动信息。而更多时候，咱们是通过 GC 日志来排查问题的，在启动参数中加上 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps 来开启 GC 日志。
常见的 Young GC、Full GC 日志含意在此就不做赘述了。
针对 gc 日志，咱们就能大抵推断出 youngGC 与 fullGC 是否过于频繁或者耗时过长，从而隔靴搔痒。咱们上面将对 G1 垃圾收集器来做剖析，这边也倡议大家应用 G1-XX:+UseG1GC。
youngGC 过频繁
youngGC 频繁个别是短周期小对象较多，先思考是不是 Eden 区 / 新生代设置的太小了，看是否通过调整 -Xmn、-XX:SurvivorRatio 等参数设置来解决问题。如果参数失常，然而 young gc 频率还是太高，就须要应用 Jmap 和 MAT 对 dump 文件进行进一步排查了。
youngGC 耗时过长
耗时过长问题就要看 GC 日志里耗时耗在哪一块了。以 G1 日志为例，能够关注 Root Scanning、Object Copy、Ref Proc 等阶段。Ref Proc 耗时长，就要留神援用相干的对象。
Root Scanning 耗时长，就要留神线程数、跨代援用。Object Copy 则须要关注对象生存周期。而且耗时剖析它须要横向比拟，就是和其余我的项目或者失常时间段的耗时比拟。比如说图中的 Root Scanning 和失常时间段比增长较多，那就是起的线程太多了。
触发 fullGC
G1 中更多的还是 mixedGC，但 mixedGC 能够和 youngGC 思路一样去排查。触发 fullGC 了个别都会有问题，G1 会进化应用 Serial 收集器来实现垃圾的清理工作，暂停时长达到秒级别，能够说是半跪了。
fullGC 的起因可能包含以下这些，以及参数调整方面的一些思路：
- 并发阶段失败：在并发标记阶段，MixGC 之前老年代就被填满了，那么这时候 G1 就会放弃标记周期。这种状况，可能就须要减少堆大小，或者调整并发标记线程数 -XX:ConcGCThreads。
- 降职失败：在 GC 的时候没有足够的内存供存活 / 降职对象应用，所以触发了 Full GC。这时候能够通过 -XX:G1ReservePercent 来减少预留内存百分比，缩小 -XX:InitiatingHeapOccupancyPercent 来提前启动标记，-XX:ConcGCThreads 来减少标记线程数也是能够的。
- 大对象调配失败：大对象找不到适合的 region 空间进行调配，就会进行 fullGC，这种状况下能够增大内存或者增大 -XX:G1HeapRegionSize。
- 程序被动执行 System.gc()：不要轻易写就对了。
另外，咱们能够在启动参数中配置 -XX:HeapDumpPath=/xxx/dump.hprof 来 dump fullGC 相干的文件，并通过 jinfo 来进行 gc 前后的 dump
jinfo -flag +HeapDumpBeforeFullGC pid
jinfo -flag +HeapDumpAfterFullGC pid这样失去 2 份 dump 文件，比照后次要关注被 gc 掉的问题对象来定位问题。
搜寻 Java 知音，回复“后端面试”，送你一份面试宝典.pdf
网络
波及到网络层面的问题个别都比较复杂，场景多，定位难，成为了大多数开发的噩梦，应该是最简单的了。这里会举一些例子，并从 tcp 层、应用层以及工具的应用等方面进行论述。
超时
超时谬误大部分处在利用层面，所以这块着重了解概念。超时大体能够分为连贯超时和读写超时，某些应用连接池的客户端框架还会存在获取连贯超时和闲暇连贯清理超时。
- 读写超时。readTimeout/writeTimeout，有些框架叫做 so_timeout 或者 socketTimeout，均指的是数据读写超时。留神这边的超时大部分是指逻辑上的超时。soa 的超时指的也是读超时。读写超时个别都只针对客户端设置。
- 连贯超时。connectionTimeout，客户端通常指与服务端建设连贯的最大工夫。服务端这边 connectionTimeout 就有些形形色色了，jetty 中示意闲暇连贯清理工夫，tomcat 则示意连贯维持的最大工夫。
- 其余。包含连贯获取超时 connectionAcquireTimeout 和闲暇连贯清理超时 idleConnectionTimeout。多用于应用连接池或队列的客户端或服务端框架。
咱们在设置各种超时工夫中，须要确认的是尽量放弃客户端的超时小于服务端的超时，以保障连贯失常完结。
在理论开发中，咱们关怀最多的应该是接口的读写超时了。
如何设置正当的接口超时是一个问题。如果接口超时设置的过长，那么有可能会过多地占用服务端的 tcp 连贯。而如果接口设置的过短，那么接口超时就会十分频繁。
服务端接口明明 rt 升高，但客户端依然始终超时又是另一个问题。这个问题其实很简略，客户端到服务端的链路包含网络传输、排队以及服务解决等，每一个环节都可能是耗时的起因。
TCP 队列溢出
tcp 队列溢出是个绝对底层的谬误，它可能会造成超时、rst 等更表层的谬误。因而谬误也更荫蔽，所以咱们独自说一说。
如上图所示，这里有两个队列：syns queue(半连贯队列）、accept queue（全连贯队列）。三次握手，在 server 收到 client 的 syn 后，把音讯放到 syns queue，回复 syn+ack 给 client，server 收到 client 的 ack，如果这时 accept queue 没满，那就从 syns queue 拿出暂存的信息放入 accept queue 中，否则按 tcp_abort_on_overflow 批示的执行。
tcp_abort_on_overflow 0 示意如果三次握手第三步的时候 accept queue 满了那么 server 扔掉 client 发过来的 ack。tcp_abort_on_overflow 1 则示意第三步的时候如果全连贯队列满了，server 发送一个 rst 包给 client，示意废掉这个握手过程和这个连贯，意味着日志里可能会有很多 connection reset / connection reset by peer。
那么在理论开发中，咱们怎么能疾速定位到 tcp 队列溢出呢？
netstat 命令，执行netstat -s | egrep "listen|LISTEN"
如上图所示，overflowed 示意全连贯队列溢出的次数，sockets dropped 示意半连贯队列溢出的次数。
ss 命令，执行 ss -lnt
下面看到 Send-Q 示意第三列的 listen 端口上的全连贯队列最大为 5，第一列 Recv- Q 为全连贯队列以后应用了多少。
接着咱们看看怎么设置全连贯、半连贯队列大小吧：
全连贯队列的大小取决于 min(backlog, somaxconn)。backlog 是在 socket 创立的时候传入的，somaxconn 是一个 os 级别的零碎参数。而半连贯队列的大小取决于 max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)。
在日常开发中，咱们往往应用 servlet 容器作为服务端，所以咱们有时候也须要关注容器的连贯队列大小。在 tomcat 中 backlog 叫做 acceptCount，在 jetty 外面则是 acceptQueueSize。
RST 异样
RST 包示意连贯重置，用于敞开一些无用的连贯，通常示意异样敞开，区别于四次挥手。
在理论开发中，咱们往往会看到 connection reset / connection reset by peer 谬误，这种状况就是 RST 包导致的。
端口不存在
如果像不存在的端口收回建设连贯 SYN 申请，那么服务端发现自己并没有这个端口则会间接返回一个 RST 报文，用于中断连贯。
被动代替 FIN 终止连贯
一般来说，失常的连贯敞开都是须要通过 FIN 报文实现，然而咱们也能够用 RST 报文来代替 FIN，示意间接终止连贯。理论开发中，可设置 SO_LINGER 数值来管制，这种往往是成心的，来跳过 TIMED_WAIT，提供交互效率，不闲就慎用。
客户端或服务端有一边产生了异样，该方向对端发送 RST 以告知敞开连贯
咱们下面讲的 tcp 队列溢出发送 RST 包其实也是属于这一种。这种往往是因为某些起因，一方无奈再能失常解决申请连贯了(比方程序崩了，队列满了)，从而告知另一方敞开连贯。
接管到的 TCP 报文不在已知的 TCP 连贯内
比方，一方机器因为网络切实太差 TCP 报文失踪了，另一方敞开了该连贯，而后过了许久收到了之前失踪的 TCP 报文，但因为对应的 TCP 连贯已不存在，那么会间接发一个 RST 包以便开启新的连贯。
一方长期未收到另一方的确认报文，在肯定工夫或重传次数后收回 RST 报文
这种大多也和网络环境相干了，网络环境差可能会导致更多的 RST 报文。
之前说过 RST 报文多会导致程序报错，在一个已敞开的连贯上读操作会报 connection reset，而在一个已敞开的连贯上写操作则会报 connection reset by peer。通常咱们可能还会看到 broken pipe 谬误，这是管道层面的谬误，示意对已敞开的管道进行读写，往往是在收到 RST，报出 connection reset 错后持续读写数据报的错，这个在 glibc 源码正文中也有介绍。
咱们在排查故障时候怎么确定有 RST 包的存在呢？当然是应用 tcpdump 命令进行抓包，并应用 wireshark 进行简略剖析了。tcpdump -i en0 tcp -w xxx.cap，en0 示意监听的网卡。
接下来咱们通过 wireshark 关上抓到的包，可能就能看到如下图所示，红色的就示意 RST 包了。
TIME_WAIT 和 CLOSE_WAIT
TIME_WAIT 和 CLOSE_WAIT 是啥意思置信大家都晓得。
在线上时，咱们能够间接用命令 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 来查看 time-wait 和 close_wait 的数量
用 ss 命令会更快ss -ant | awk '{++S[$1]} END {for(a in S) print a, S[a]}'
TIME_WAIT
time_wait 的存在一是为了失落的数据包被前面连贯复用，二是为了在 2MSL 的工夫范畴内失常敞开连贯。它的存在其实会大大减少 RST 包的呈现。
过多的 time_wait 在短连贯频繁的场景比拟容易呈现。这种状况能够在服务端做一些内核参数调优:
# 示意开启重用。容许将 TIME-WAIT sockets 从新用于新的 TCP 连贯，默认为 0，示意敞开
net.ipv4.tcp_tw_reuse = 1
#示意开启 TCP 连贯中 TIME-WAIT sockets 的疾速回收，默认为 0，示意敞开
net.ipv4.tcp_tw_recycle = 1当然咱们不要遗记在 NAT 环境下因为工夫戳错乱导致数据包被回绝的坑了，另外的方法就是改小 tcp_max_tw_buckets，超过这个数的 time_wait 都会被干掉，不过这也会导致报 time wait bucket table overflow 的错。
CLOSE_WAIT
close_wait 往往都是因为应用程序写的有问题，没有在 ACK 后再次发动 FIN 报文。close_wait 呈现的概率甚至比 time_wait 要更高，结果也更重大。往往是因为某个中央阻塞住了，没有失常敞开连贯，从而慢慢地耗费完所有的线程。
想要定位这类问题，最好是通过 jstack 来剖析线程堆栈来排查问题，具体可参考上述章节。这里仅举一个例子。
开发同学说利用上线后 CLOSE_WAIT 就始终增多，直到挂掉为止，jstack 后找到比拟可疑的堆栈是大部分线程都卡在了 countdownlatch.await 办法，找开发同学理解后得悉应用了多线程然而确没有 catch 异样，批改后发现异常仅仅是最简略的降级 sdk 后常呈现的 class not found。