Java线上故障排查实战：死锁、CPU飙高与内存泄漏处理

1. Java线上故障排查实战指南

作为一名Java开发者，线上环境故障排查是必备的核心技能。与本地开发环境不同，线上环境面临更复杂的网络条件、更高的并发压力和更严苛的资源限制。本文将分享我在处理Java线上故障时的实战经验，涵盖常见问题场景、排查思路和实用工具链。

1.1 线上环境与本地环境的本质差异

线上环境与本地开发环境存在几个关键区别：

• 并发量级不同：线上真实流量可能是本地测试的数百倍
• 资源限制严格：线上服务器通常有严格的内存、CPU配额
• 依赖服务状态：数据库、缓存等中间件在线上可能处于高负载状态
• 网络环境复杂：跨机房调用、DNS解析等都可能引入问题

理解这些差异是有效排查线上问题的前提。下面我们来看几个典型故障场景。

2. 接口突然失效的排查思路

2.1 问题现象分析

当发现"昨天还能用，今天突然挂掉"的接口时，建议按以下优先级排查：

1. 网络连通性检查

   bash复制ping 目标服务IP
   telnet IP 端口
   traceroute IP
   

   网络问题是最高频的故障原因，特别是跨机房服务调用。

2. 服务器基础资源检查

   bash复制df -h    # 磁盘空间
   free -m  # 内存使用
   top      # CPU负载
   

   磁盘满会导致日志无法写入，进而阻塞业务线程。

3. JVM状态检查

   bash复制jps -l    # 查看Java进程
   jstat -gcutil PID 1000  # 实时GC监控
   

   GC频繁或Old区持续增长都可能是问题征兆。

2.2 深度排查工具链

针对不同问题类型，需要使用专业工具：

提示：生产环境建议使用arthas代替jstack，可以避免频繁dump影响服务性能

3. 死锁问题全解析

3.1 死锁的必备条件

一个典型的死锁需要同时满足四个条件：

1. 互斥条件：资源一次只能被一个线程占用
2. 占有且等待：线程持有资源并等待其他资源
3. 不可剥夺：已获得的资源不能被强制拿走
4. 循环等待：多个线程形成资源等待环

3.2 死锁代码示例分析

以下是两个典型的死锁实现方式：

版本1：同步块嵌套

java复制public void deadLock1() {
    final Object lockA = new Object();
    final Object lockB = new Object();
    
    new Thread(() -> {
        synchronized(lockA) {
            sleep(100); // 确保死锁发生
            synchronized(lockB) {
                System.out.println("Thread1 got both locks");
            }
        }
    }).start();

    new Thread(() -> {
        synchronized(lockB) {
            sleep(100);
            synchronized(lockA) {
                System.out.println("Thread2 got both locks");
            }
        }
    }).start();
}

版本2：等待/通知机制

java复制public void deadLock2() {
    final Object lock = new Object();
    
    new Thread(() -> {
        synchronized(lock) {
            try {
                lock.wait(); // 释放锁并等待
            } catch (Exception e) {}
        }
    }).start();

    sleep(100); // 确保线程进入等待
    
    synchronized(lock) {
        lock.notify(); // 无法唤醒，因为当前线程持有锁
    }
}

3.3 死锁排查实战

使用jstack排查死锁的步骤：

1. 找到Java进程PID

   bash复制jps -l
   

2. 生成线程dump

   bash复制jstack -l PID > thread.log
   

3. 搜索"deadlock"关键词
4. 分析线程等待关系图

典型死锁日志特征：

code复制Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x00007f88e4003e58 (object 0x000000076ab45c80)
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00007f88e4003f98 (object 0x000000076ab45c90) 
  which is held by "Thread-1"

4. CPU飙高问题处理

4.1 问题定位步骤

1. 定位高CPU进程

   bash复制top -c
   

   按P按CPU使用率排序

2. 定位问题线程

   bash复制top -Hp PID
   

   记录高CPU线程ID（十进制）

3. 线程ID转换

   bash复制printf "%x\n" 线程ID
   

   转换为十六进制用于jstack查找

4. 分析线程栈

   bash复制jstack PID | grep -A 20 十六进制线程ID
   

4.2 常见原因与解决方案

5. 内存泄漏排查指南

5.1 内存问题分类

1. 内存泄漏：对象无法被GC回收，持续占用内存
2. 内存溢出：申请的内存超过JVM限制
3. 内存抖动：频繁创建/销毁对象引发GC风暴

5.2 排查工具链

1. 实时监控

   bash复制jstat -gcutil PID 1000
   

   关注Old区使用率和Full GC频率

2. 堆转储分析

   bash复制jmap -dump:live,format=b,file=heap.hprof PID
   

   使用MAT/Eclipse Memory Analyzer分析

3. OOM自动转储
   JVM参数配置：

   code复制-XX:+HeapDumpOnOutOfMemoryError 
   -XX:HeapDumpPath=/path/to/dump.hprof
   

5.3 典型内存泄漏场景

1. 静态集合滥用

   java复制public class LeakDemo {
       static List<Object> cache = new ArrayList<>();
       
       public void addToCache(Object obj) {
           cache.add(obj); // 对象永远无法释放
       }
   }
   

2. 未关闭资源

   java复制public void readFile() {
       InputStream is = new FileInputStream("large.txt");
       // 忘记调用is.close()
   }
   

3. 监听器未注销

   java复制eventBus.register(listener);
   // 忘记unregister
   

4. ThreadLocal滥用

   java复制ThreadLocal<BigObject> tl = new ThreadLocal<>();
   tl.set(new BigObject());
   // 线程复用时不清理
   

6. 数据库相关问题排查

6.1 连接池耗尽

现象：

• 获取连接超时
• 活跃连接数达到最大值

排查命令：

sql复制SHOW STATUS LIKE 'Threads_connected';
SHOW PROCESSLIST;

解决方案：

1. 增加连接池大小（临时）
2. 优化慢查询（根本）
3. 添加连接有效性检测

6.2 慢SQL分析

定位方法：

1. 开启慢查询日志

   sql复制SET GLOBAL slow_query_log = 'ON';
   SET GLOBAL long_query_time = 1; 
   

2. 使用explain分析

   sql复制EXPLAIN SELECT * FROM large_table WHERE unindexed_column = 'value';
   

常见优化手段：

• 添加合适索引
• 重写复杂查询
• 避免SELECT *
• 优化JOIN操作

7. 实战经验与技巧

7.1 预防性措施

1. 完善的监控体系：

   • JVM指标（GC次数、堆内存）
   • 系统指标（CPU、内存、磁盘）
   • 业务指标（QPS、成功率）

2. 日志规范：

   • 统一日志格式
   • 关键路径打点
   • 合理日志级别

3. 压测与预案：

   • 定期全链路压测
   • 制定降级方案
   • 故障演练

7.2 排查工具箱推荐

1. Arthas：在线诊断神器

   bash复制thread -b  # 查看阻塞线程
   monitor -c 5 *Test* printParams  # 方法监控
   

2. Async-profiler：低开销性能分析

   bash复制./profiler.sh -d 30 -f flamegraph.html PID
   

3. Prometheus + Grafana：监控可视化

4. JVM参数模板：

   code复制-Xms4g -Xmx4g 
   -XX:+UseG1GC
   -XX:+HeapDumpOnOutOfMemoryError
   -XX:HeapDumpPath=/path/to/dump.hprof
   

7.3 避坑指南

1. 不要盲目重启：

   • 先保留现场证据（线程dump、堆dump）
   • 分析根本原因再处理

2. 谨慎使用jmap：

   • 大堆转储可能导致服务暂停
   • 生产环境建议在低峰期操作

3. 线程池陷阱：

   java复制// 错误示例：无界队列可能导致OOM
   Executors.newFixedThreadPool(200);
   
   // 正确做法：使用有界队列
   new ThreadPoolExecutor(..., new ArrayBlockingQueue<>(1000));
   

4. 缓存使用规范：

   • 设置合理的TTL
   • 考虑缓存穿透/雪崩场景
   • 大对象谨慎缓存

在实际工作中，我总结出一个有效的排查流程：先看监控（确定问题范围）→ 保留现场（收集诊断数据）→ 分析原因（使用专业工具）→ 验证修复（灰度发布）。这个过程可能需要多次迭代，重要的是保持冷静，用数据说话而不是凭猜测行事。