线上故障快速定位及恢复

Java线程堆栈

• Linux jstack命令

jstack 7756(Java进程号) > java.stack

• Linux kill命令

kill -3 7756(Java进程号)

向JVM发送QUIT信号 

Java线程

• JVM创建线程

• 用户线程

main函数代表主线程

• 线程堆栈的第一行

1、java线程转换LINUX 内核库pthread即本地线程
2、tid 语言层面的id比如Java 线程编号
3、nid（Native Thread）运行在操作系统基础上的本地id

• 线程调用含义

堆栈信息其中一行的调用关系

• pstatck 7756(Java进程号)

nid(16进制) == LWP(10进制)

16进制的nid

10进制的LWP（轻量级进程）

锁是否释放

• wait() 会释放监视锁

• sleep会占用锁

• 当一个线程占有一个锁时

堆栈会打印 -locked 

• 当该线程等待别的线程释放该锁

堆栈会打印 -waiting to lock 

• 如果代码中有wait调用

首先是locked 然后又会打印 waiting on 
这种会导致死锁即死循环 占用了锁等待其他锁

线程死锁

0时刻 线程0获取锁0 线程1获取锁1 
2时刻 线程0获取锁1 线程1获取锁0 
两个线程各得到锁 都等待对方的锁

Java堆栈直接给出死锁的结果

死锁报错

死锁详情

死锁情况分析导致CPU过高分析

方法1

步骤

为什么要去掉wait和sleep的线程 因为其不占用cpu资源

原因

方法2 TOP&堆栈方法（一次命中）

JNI是Java Native Interface

5578是java的进程号
打印这个进程中所有线程
cpu消耗倒叙排列 shit+h
jstack把线程堆栈打印出来 里面有很多线程 其中有一个就等于cpu消耗最多的那个pid
就可以直接定位到这行代码有问题

不消耗CPU的线程状态

• JVM的RUNNABLE状态

网络IO不消耗CPU 是同步阻塞的过程

• TIMED_WAITING(on object monitor)

obj.wait(time)

• TIMED_WAITING(sleeping)

Thread.sleep(time)

• TIMED_WAITING(parking)

被挂起

• WAITING(on object monitor)

obj.wait()
通过notify()唤醒

• BLOCKED (on object monitor)

等待监视锁

• WAITING(parking)

被挂起

Java线程堆栈

• 一次线程堆栈信息

• 多次线程堆栈

资源不足导致性能下降原因

大量线程停在同样的调用上下文中

原因

未及时释放连接的情况

多个锁导致的锁链分析

很多线程在等待不同的锁 有的锁竞争可能由于另外一个锁对象竞争导致 需要找到根源

案例分析

WebAPI性能瓶颈

线上表现

1、连接阻塞比较多RECQ(接收的队列)
2、超时日志疯狂打印
3、通过重启webapi进程临时缓解压力

解决步骤

线程A

线程B

线上故障处理方式

• 保留现场

比如通过jstack保存堆栈快照信息

• 恢复服务

第一时间恢复服务 比如restart、reboot

• 排查解决
• 验证

常规操作

• 重启
• 回滚
• 降级
• 摘机

现象收集&故障定位

潜在bug被激发的情况重启有效

故障排除&服务恢复

确定服务进程排查问题

CPU

top 
shift+p 按pid 进程编号升序
shift+m 按占用内存大小降序

内存

free -g

内存

vmstat -n

tcp连接数量

netstat -aonp|grep tcp |wc -l

端口映射

netstat -natp|sort -m

磁盘情况

iostat -d 1

文件占用情况

ls -l /proc/*/fd

目标服务内观察

问题协查方法论

异常处理原则

错误永远无法避免 且发生的角度永远无法预期
在故障发生时尽可能维持系统核心功能的可用性