1. 认识jstackJava线程快照分析利器当你发现Java应用突然卡死或者服务器CPU莫名其妙飙到100%时jstack就是你的救命稻草。这个JDK自带的小工具能在不重启服务的情况下帮你拍下JVM线程的X光片。我处理过不少线上事故90%的线程问题靠它就能初步定位。jstack生成的线程快照包含每个线程的完整调用栈、锁状态和线程状态。想象一下这就像给正在运行的Java程序做CT扫描你能清晰看到哪些线程在干活Runnable哪些在等锁Blocked哪些在睡大觉Waiting更关键的是能直接揪出死锁的罪魁祸首2. jstack命令全解析从基础到高阶2.1 基础命令格式最常用的命令格式其实就两种# 直接输出到控制台 jstack pid # 保存到文件推荐方便反复查看 jstack pid thread_dump.log第一次用可能会遇到权限问题记住两点要用和Java进程相同的用户执行容器环境需要先进入容器再执行2.2 实用参数详解除了基本用法这几个参数能应对特殊场景# 强制dump适用于进程假死 jstack -F pid # 显示锁的附加信息分析死锁必用 jstack -l pid # 混合模式查看JNI调用栈 jstack -m pid特别提醒生产环境慎用-F参数可能造成短暂停顿。去年我们有个核心服务用-F抓dump结果引发了短暂流量抖动后来改用常规方式多次采样就稳多了。3. 实战死锁分析从快照到解决方案3.1 死锁特征识别先看个典型死锁快照片段Thread-1 #12 prio5 os_prio0 tid0x00007f48740f7000 nid0x5e waiting for monitor entry [0x00007f486b7fe000] java.lang.Thread.State: BLOCKED (on object monitor) at com.DeadLockDemo$1.run(DeadLockDemo.java:25) - waiting to lock 0x00000000f6c02b80 (a java.lang.Object) - locked 0x00000000f6c02b70 (a java.lang.Object) Thread-2 #13 prio5 os_prio0 tid0x00007f48740f8800 nid0x5f waiting for monitor entry [0x00007f486b6fd000] java.lang.Thread.State: BLOCKED (on object monitor) at com.DeadLockDemo$2.run(DeadLockDemo.java:40) - waiting to lock 0x00000000f6c02b70 (a java.lang.Object) - locked 0x00000000f6c02b80 (a java.lang.Object)关键点解读两个线程都处于BLOCKED状态Thread-1持有0xf6c02b70等待0xf6c02b80Thread-2正好相反形成环形等待明确指出了死锁发生的代码行数3.2 解决方案与预防根据多年踩坑经验推荐这几个解决方案锁排序统一按固定顺序获取锁锁超时使用tryLock设置超时时间减少锁粒度大锁拆小锁预防死锁的编码习惯避免在同步块中调用外部方法尽量使用并发工具类代替显式锁加锁顺序在文档中明确标注4. CPU飙高问题排查指南4.1 标准排查流程上周刚处理过一个CPU 100%的案例完整流程分享给大家定位问题进程top -c找到CPU高的Java进程PID定位问题线程top -Hp PID记下占用高的线程ID十进制转换线程IDprintf %x\n 线程ID得到十六进制值用于jstack搜索分析热点栈jstack PID | grep -A 30 十六进制线程ID4.2 常见CPU问题模式通过上百次排查总结出这些高频问题空转循环while(true)没加sleep复杂计算JSON解析/加密算法没缓存锁竞争大量线程处于BLOCKED状态GC问题频繁Full GC导致CPU飙升有个经典案例某接口突然变慢用jstack发现大量线程卡在Log4j的同步块上原来是同步打印大日志文件导致的改成异步日志就解决了。5. 高级技巧与自动化方案5.1 自动化监控方案手动执行jstack毕竟麻烦推荐这些自动化方案Arthasthread -n 3命令自动统计最忙线程PrometheusGrafana通过JMX暴露线程指标自研监控定时jstack关键字报警我们团队现在用的方案是当CPU超过阈值时自动抓取3次jstack间隔5秒通过Flume传到ELK分析大大缩短了故障定位时间。5.2 线程快照分析技巧时间戳标记每次dump前先echo $(date) dump.log多次采样间隔5-10秒取3次样本观察变化结合其他工具jmap看内存情况jstat看GC状态vmstat看系统负载曾经遇到个诡异问题jstack显示线程正常但服务就是不响应。后来结合vmstat发现是磁盘IO打满证明线程分析要结合系统整体状态。6. 常见问题与避坑指南6.1 典型报错处理Unable to open socket file原因进程已退出或权限不足解决检查进程是否存在用正确用户执行Process unavailable原因容器环境未正确进入命名空间解决使用nsenter或docker execNo such process原因PID写错或进程已终止解决用ps -ef | grep java确认PID6.2 性能优化建议控制线程数避免创建过多线程推荐使用线程池减少锁竞争用ConcurrentHashMap代替同步的HashMap避免阻塞IO改用NIO或异步编程模型合理设置栈大小-Xss参数不宜过大通常1-2MB足够有个性能优化的黄金法则线程数 ≈ CPU核数 * (1 等待时间/计算时间)。我们有个视频处理服务按这个公式调整线程池后吞吐量提升了3倍。