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 <Oxe7402c48>

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

堆栈会打印 -waiting to lock <Oxe7402c48>

• 如果代码中有wait调用
  

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

线程死锁

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+hjstack把线程堆栈打印出来 里面有很多线程 其中有一个就等于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

目标服务内观察

问题协查方法论

异常处理原则

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