Java线程CPU飙高、僵尸进程和磁盘满的排查技巧
作者：予枫的编程笔记
线上故障就像埋在系统里的“定时炸弹”——CPU突然飙高导致服务卡顿、海量日志找不到异常、磁盘满了直接宕机，每一种都能让程序员头皮发麻。
不用瞎试错，不用靠经验瞎猜，今天整理了4类高频线上故障的排查套路，附实操命令，从定位到解决一步到位，收藏起来，下次故障直接抄作业！
一、CPU飙高：快速定位到具体Java线程（实操拉满）
线上服务突然卡顿、接口响应超时，大概率是CPU飙高惹的祸。很多新手遇到这种情况，只会用top命令看一眼CPU占用，却不知道怎么定位到具体的代码线程，最后只能瞎折腾。
分享一套极简排查流程，从定位进程到找到异常线程，全程只需几行命令，新手也能快速上手👇
1. 第一步：定位CPU占用最高的进程
先用top命令查看系统CPU使用情况，重点关注%CPU列，找到占用率最高的进程（PID）：
top
- 操作技巧：输入top后，按「P」键（大写），可以按CPU占用率从高到低排序，一眼就能找到“罪魁祸首”进程。
- 关键说明：如果是Java服务，进程名一般是java，记住对应的PID（比如12345），后续用得上。
2. 第二步：定位进程中CPU占用最高的线程
找到异常进程后，用top -H -p 命令，定位该进程下占用CPU最高的线程（TID）：
top -H -p 12345 # 12345替换为第一步找到的PID
- 核心作用：-H参数会将进程拆分到线程级别，按「P」键排序后，就能找到占用CPU最高的线程ID（TID，比如12346）。
3. 第三步：将线程ID转换为16进制（关键一步）
因为Java的jstack日志中，线程ID是16进制的，所以需要将第二步找到的TID（十进制）转换为16进制：
printf "%x\n" 12346 # 12346替换为第二步找到的TID
- 示例：假设转换后得到的16进制线程ID是303a（注意小写，jstack日志中是小写）。
4. 第四步：用jstack打印日志，定位异常线程
最后用jstack命令打印该进程的线程日志，并用grep过滤出目标线程，就能找到异常代码的堆栈信息：
jstack 12345 | grep 303a -A 20 # 12345是进程PID，303a是16进制线程ID，-A 20表示显示后续20行
- 关键解读：日志中会显示该线程正在执行的代码行、方法名，顺着堆栈信息找下去，就能快速定位到导致CPU飙高的具体代码（比如死循环、频繁GC等）。
小提示：排查完成后，记得点赞收藏，下次遇到CPU飙高，直接按这个流程来，不用再翻资料！
二、日志分析：海量日志中快速定位异常（grep组合拳）
线上服务报错，日志文件动辄几百M、几个G，直接打开查找异常信息，不仅耗时，还容易看漏。
分享3个最实用的grep组合命令，帮你快速从海量日志中筛选出异常信息，效率翻倍👇
1. 基础用法：筛选包含指定关键词的日志
最常用的场景：查找包含“Error”“Exception”等异常关键词的日志，快速定位报错位置：
# 筛选包含Error的日志，显示行号 grep -n "Error" app.log # 筛选包含Exception的日志，忽略大小写（比如Exception、exception都能匹配） grep -i "Exception" app.log
2. 进阶用法：筛选指定时间段的日志
很多时候，我们知道故障发生的大致时间段，只需筛选该时间段内的日志，缩小查找范围：
# 假设日志格式是 2026-02-10 14:30:00 错误信息，筛选14:30-14:40之间的Error日志 grep "2026-02-10 14:3[0-4]" app.log | grep "Error"
- 灵活调整：根据自己项目的日志格式，修改时间匹配规则（比如yyyy-MM-dd HH:mm:ss、MM-dd HH:mm等）。
3. 高阶用法：筛选异常日志并输出到文件
如果异常日志较多，可将筛选结果输出到单独的文件中，方便后续分析（避免反复执行命令）：
# 筛选近1小时内的Exception日志，输出到error.log文件中 grep "2026-02-10 13:" app.log | grep -i "Exception" > error.log
小技巧：如果日志是滚动日志（比如app.log.1、app.log.2），可以用grep “关键词” app.log* 批量筛选所有日志文件。
三、僵尸进程：产生原因+清理方法（避免占用系统资源）
僵尸进程（Zombie）是线上常见的“隐形杀手”——它本身不占用CPU和内存，但会占用系统进程号（PID），如果大量堆积，会导致系统无法创建新进程，最终引发服务异常。
1. 先搞懂：僵尸进程是什么？怎么产生？
- 定义：僵尸进程是指子进程已经终止，但父进程没有调用wait()或waitpid()函数回收子进程资源，导致子进程残留的“空壳进程”。
- 核心原因：父进程异常退出、父进程逻辑缺陷（未回收子进程）、子进程执行时间过短，父进程还没来得及回收。
2. 第一步：查找系统中的僵尸进程
用ps命令筛选出僵尸进程，僵尸进程的状态标记为「Z」：
ps -ef | grep defunct # defunct是僵尸进程的标识
# 或者更精准的筛选
ps aux | awk '{if($8=="Z") print $0}'
- 输出解读：筛选结果中，STAT列显示为Z的，就是僵尸进程，记住对应的PID和父进程PID（PPID）。
3. 第二步：清理僵尸进程（两种方法，按需选择）
清理僵尸进程的核心是“回收子进程资源”，优先用温和方法，避免影响正常服务：
方法1：重启父进程（推荐，温和安全）
僵尸进程是父进程未回收导致的，重启父进程后，系统会自动回收其下属的僵尸进程：
# 先查看父进程名称（PPID是父进程ID） ps -ef | grep 1234 # 1234是父进程PPID # 重启父进程（根据自己的服务启动方式调整） systemctl restart 服务名 # 比如systemctl restart java-service
方法2：强制杀死父进程（紧急情况使用）
如果父进程无法重启，可强制杀死父进程，系统会将僵尸进程托管给init进程（PID=1），init进程会自动回收僵尸进程：
kill -9 1234 # 1234是父进程PPID，谨慎使用！
警告：强制杀死父进程会导致父进程对应的服务中断，仅在紧急情况下使用，提前做好备份。
四、磁盘满：inode耗尽与文件删除后空间未释放（坑点规避）
线上服务突然宕机，登录服务器后发现磁盘满了（df -h查看使用率100%），但删除大文件后，磁盘空间还是没释放——这两个坑，很多程序员都踩过。
1. 坑点1：文件删除后，空间未释放（原因+解决）
核心原因：
删除的文件正在被进程占用（比如日志文件被Java进程占用），此时rm命令只是删除了文件的目录项，文件的实际内容还在磁盘中，空间不会释放。
排查+解决步骤：
查找被占用的已删除文件：
lsof | grep deleted # 筛选出已删除但仍被进程占用的文件
找到对应的进程（PID），重启该进程（释放文件占用）：
systemctl restart 服务名 # 比如重启Java服务，释放日志文件占用
补充说明：如果无法重启进程，可通过echo “” > 文件名 的方式清空文件（避免删除文件导致的占用问题）：
echo "" > app.log # 清空日志文件，释放空间，且不影响进程占用
2. 坑点2：inode耗尽（磁盘有空间，但无法创建文件）
核心原因：
磁盘的inode节点耗尽了——inode是文件的索引，每个文件对应一个inode，即使磁盘有剩余空间，inode耗尽后，也无法创建新文件（报错：no space left on device）。
排查+解决步骤：
查看inode使用情况：
df -i # 查看各分区inode使用率，Ifree列是剩余inode数量
定位inode占用最多的目录（找到大量小文件的目录）：
# 从根目录开始查找，统计每个目录的inode数量 for i in /*; do echo $i; find $i | wc -l; done
解决方法：删除目录下的大量小文件（比如日志碎片、临时文件），释放inode：
# 批量删除指定目录下的小文件（谨慎操作，确认文件可删除） rm -rf /tmp/* # 比如删除/tmp目录下的临时文件
预防建议：定期清理临时文件、日志碎片，避免小文件堆积导致inode耗尽，可写定时脚本自动清理。
五、总结
线上故障排查的核心不是“瞎试错”，而是“找对逻辑、用对命令”——CPU飙高找线程、日志繁杂用grep、僵尸进程清父进程、磁盘满分两种坑点，按本文的套路来，大部分高频故障都能在10分钟内定位并解决。
以上就是Java线程CPU飙高、僵尸进程和磁盘满的排查技巧的详细内容，更多关于Java线程CPU飙高、僵尸进程和磁盘满的资料请关注脚本之家其它相关文章！