Java死锁排查和Java CPU 100% 排查的步骤整理和OOM FullGc案例

本文介绍如何使用jps+jstack、jconsole等工具排查Java死锁及CPU100%的问题,并通过实例演示排查过程。此外,还提供了一个用于压力测试下性能问题定位的方法。

工欲善其事,必先利其器

此文进行了新的整理,整理后的文章请查看:一文学会Java死锁和CPU 100% 问题的排查技巧

简介

本篇整理两个排查问题的简单技巧,一个是java死锁排查,这个一般在面试的时会问到,如果没有写多线程的话,实际中遇到的机会不多;第二个是java cpu 100%排查,这个实际的开发中,线的应用出现这个问题可能性比较大,所以这里简单总结介绍一下,对自己学习知识的一个整理,提高自己的解决问题能力。

一、Java死锁排查

通过标题我们就要思考三个问题:

  1. 什么是死锁?
  2. 为什么会出现死锁?
  3. 怎么排查代码中出现了死锁?

作为技术人员(工程师),在面对问题的时候,可能需要的能力是怎么去解决这个问题。但是在学习技术知识的时候,那就要多问为什么,一定要锻炼自己这方面的能力,这样才能更好的掌握知识。

解答

  1. 什么是死锁?

死锁是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。百度百科:死锁

死锁图示

注:进程和线程都可以发生死锁,只要满足死锁的条件!

  1. 为什么会出现死锁?

从上面的概念中我们知道
(1)必须是两个或者两个以上进程(线程)
(2)必须有竞争资源

  1. 怎么排查代码中出现了死锁?【重点来了
    首先写一个死锁的代码,看例子:
/**
 * 
 * 使用jstack 排查死锁
 * @author dufyun
 *
 */
public class JStackDemo {
    public static void main(String[] args) {
        Thread t1 = new Thread(new DeadLockTest(true));//建立一个线程
        Thread t2 = new Thread(new DeadLockTest(false));//建立另一个线程
        t1.setName("thread-dufy-1");
        t2.setName("thread-dufy-2");
        t1.start();//启动一个线程
        t2.start();//启动另一个线程
    }
}
class DeadLockTest implements Runnable {
    public boolean falg;// 控制线程
    DeadLockTest(boolean falg) {
        this.falg = falg;
    }
    public void run() {
        /**
         * 如果falg的值为true则调用t1线程
         */
        if (falg) {
            while (true) {
                synchronized (Demo.o1) {
                    System.out.println("o1 " + Thread.currentThread().getName());
                    synchronized (Demo.o2) {
                        System.out.println("o2 " + Thread.currentThread().getName());
                    }
                }
            }
        }
        /**
         * 如果falg的值为false则调用t2线程
         */
        else {
            while (true) {
                synchronized (Demo.o2) {
                    System.out.println("o2 " + Thread.currentThread().getName());
                    synchronized (Demo.o1) {
                        System.out.println("o1 " + Thread.currentThread().getName());
                    }
                }
            }
        }
    }
}

class Demo {
    static Object o1 = new Object();
    static Object o2 = new Object();
}

上面这段代码执行后,就会出现死锁,那么排查的方法有如下:

使用 jps + jstack

第一:在windons命令窗口,使用 jps -l 【不会使用jps请自行查询资料】

jps -l 命令

第二:使用jstack -l 12316 【不会使用jstack请自行查询资料】
jstack

使用jconsole

在window打开 JConsole,JConsole是一个图形化的监控工具!

在windons命令窗口 ,输出 JConsole
这里写图片描述

这里写图片描述

使用Java Visual VM

在window打开 jvisualvm,jvisualvm是一个图形化的监控工具!

在windons命令窗口 ,输出 jvisualvm

Java Visual VM

死锁检测

二、Java CPU 100% 排查

这个如果在实际的应用开发中遇到,要怎么排查呢?

这里没有一步步的图示过程,只有一个简单的操作过程!有空写一个详细的例子。

1 、 使用top命令查看cpu占用资源较高的PID
top命令
2、 通过jps 找到当前用户下的java程序PID

执行 jps -l 能够打印出所有的应用的PID,找到有一个PID和这个cpu使用100%一样的ID!!就知道是哪一个服务了。

3、 使用

pidstat -p < PID > 1 3 -u -t

这里写图片描述
这里写图片描述

4 、 找到cpu占用较高的线程TID

通过上图发现是 3467的TID占用cup较大

5、 将TID转换为十六进制的表示方式

将3467转为十六进制 d8d,注意是小写!

巧转进制
6、 通过jstack -l < PID > 输出当前进程的线程信息

jstack -l pid /temp/test.log


线程的状态:
NEW,未启动的。不会出现在Dump中。
RUNNABLE,在虚拟机内执行的。
BLOCKED,受阻塞并等待监视器锁。
WATING,无限期等待另一个线程执行特定操作。
TIMED_WATING,有时限的等待另一个线程的特定操作。
TERMINATED,已退出的。

http://www.hollischuang.com/archives/110

7、 查找 TID对应的线程(输出的线程id为十六进制),找到对应的代码

查找

三、压力测试使用jstack找到系统的代码性能问题

1、在进行压力测试的时候,使用jps找到应用的PID
2、然后使用jstack输出出压力测试时候应用的dump信息
3、分析输出的日志文件中那个方法block线程占用最多,这里可能是性能有问题,找到对应的代码分析

四、推荐一个脚本工具

show-busy-java-threads

详情看github中讲解!我自己下载了show-busy-java-threads!

安装和使用:

  1. 下载 show-busy-java-threads
  2. 上传服务器,然后进行解压
  3. 解压后
  4. 然后执行对应的命令
    这里写图片描述

扩展阅读

1、Java应用CPU占用100%原因分析
2、[Java] CPU 100% 原因查找解决
3、线上应用故障排查系列
4、分析JAVA应用CPU占用过高的问题
5. 一次应用 CPU 飙高的血案排查过程
6. 一次堆外OOM问题排查
7. 又是一个程序员粗心的代码引起频繁FullGC的案例
8.linux端口号与PID的互相查询


谢谢你的阅读,如果您觉得这篇博文对你有帮助,请点赞或者喜欢,让更多的人看到!祝你每天开心愉快!



不管做什么,只要坚持下去就会看到不一样!在路上,不卑不亢!

博客首页 : https://aflyun.blog.youkuaiyun.com/

愿你我在人生的路上能都变成最好的自己,能够成为一个独挡一面的人

© 每天都在变得更好的阿飞云

<think>嗯,用户问的是OOM溢出怎么排查解决。首先,我得回忆一下OOM是什么。OOM就是Out Of Memory,内存溢出,通常发生在Java应用里,但其他语言也可能有。用户可能遇到了程序崩溃,或者性能问题,需要知道怎么处理。 首先,排查问题。需要确定错误类型,比如Java的OutOfMemoryError有不同的子类,比如堆溢出、元空间溢出等。这时候需要看日志,找出具体的错误信息。如果是堆溢出,可能是对象太多无法回收;元空间的话可能是类加载器的问题。 然后,用户可能需要分析堆转储。生成堆转储文件可以用jmap或者JVM参数自动生成。用MAT或者VisualVM这些工具来分析,找出内存泄漏的对象。比如,查看支配树,找到占用内存最大的对象,看看是否有不应该存在的引用。 接着是内存监控。用jstat看内存使用情况,各个代的变化,GC频率效果。如果老年代一直增长,可能是有内存泄漏。另外,用top或者htop看系统内存,确认是不是物理内存不足导致的。 线程堆栈分析也可能有帮助,比如jstack查看线程是否有死锁或者大量等待,虽然不一定直接关联OOM,但有时候资源竞争会导致问题。 代码审查方面,检查是否有大对象频繁创建,或者缓存没有限制,静态集合未清理等。比如,静态Map不断添加数据,没有移除机制,就会导致内存泄漏。 解决问题的话,调整JVM参数是常见方法,比如增大堆大小,设置元空间大小,调整GC算法。比如-XX:+UseG1GC可能更适合大堆。另外,优化代码,避免内存泄漏,及时释放资源,使用弱引用等。 引入内存分析工具,比如在测试环境用Valgrind或JProfiler提前发现问题。如果是系统内存不足,可能需要加内存或者优化其他进程的使用。 用户可能需要具体的例子,比如如何生成堆转储,或者MAT的使用步骤。但用户的问题比较概括,可能需要分步骤说明,确保他们能一步步操作。 还要考虑用户的技术水平,可能不熟悉命令行工具,所以需要给出常用命令,比如jmap -dump,或者JVM参数-XX:+HeapDumpOnOutOfMemoryError。同时,提醒他们测试环境生产环境的区别,避免在线服务受影响。 总结下来,排查OOM需要结合日志、堆转储分析、监控工具代码审查,解决则需要调整参数、优化代码资源管理。需要结构清晰,分步骤说明,确保用户能理解并操作。</think>### OOM(Out Of Memory)溢出排查与解决指南 #### 一、问题定位 1. **明确错误类型** OOM 错误通常伴随具体类型(如 `Java heap space`、`Metaspace``、`GC overhead limit exceeded` 等),需通过日志或报错信息确定根源。 - **堆内存溢出**:对象数量超出堆容量,常见于缓存未限制、大对象未释放。 - **元空间溢出**:加载的类信息超出 Metaspace 限制,常见于动态生成类(如反射、CGLIB)。 - **直接内存溢出**:NIO 使用的堆外内存不足,常见于未正确释放 `ByteBuffer`。 2. **生成内存快照(Heap Dump)** - **手动触发**:通过 `jmap` 工具导出堆转储文件: ```bash jmap -dump:format=b,file=heapdump.hprof <pid> ``` - **自动触发**:在 JVM 启动参数中添加: ```bash -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump ``` 3. **分析内存占用** 使用工具(如 **Eclipse MAT**、**VisualVM**、**JProfiler**)分析堆转储文件: - **Dominator Tree**:定位占用内存最大的对象。 - **Leak Suspects Report**:自动检测潜在内存泄漏。 - **Histogram**:按类统计对象数量,排查异常增长类。 4. **监控内存动态变化** - **JVM 内存监控**: ```bash jstat -gcutil <pid> 1000 # 每秒打印 GC 统计信息 ``` - **系统级监控**: 使用 `top`、`htop` 或 `Prometheus + Grafana` 观察物理内存交换分区使用情况。 --- #### 二、常见原因 1. **内存泄漏** - **静态集合未清理**:静态 Map/List 长期持有对象引用。 - **未关闭资源**:数据库连接、文件流、线程池未释放。 - **监听器未注销**:事件监听器未移除导致对象无法回收。 2. **配置不合理** - **堆内存设置过小**:未根据业务需求调整 `-Xmx` `-Xms`。 - **Metaspace 不足**:动态加载类过多,未调整 `-XX:MaxMetaspaceSize`。 - **GC 策略不当**:频繁 Full GC 但回收效率低。 3. **代码设计问题** - **大对象频繁创建**:如一次性加载超大文件到内存。 - **缓存未限制**:本地缓存未设置 LRU 淘汰策略或 TTL。 --- #### 三、解决方案 1. **调整 JVM 参数** - **堆内存扩容**: ```bash -Xmx4g -Xms4g # 根据实际需求设置 ``` - **优化 Metaspace**: ```bash -XX:MaxMetaspaceSize=512m ``` - **优化 GC 策略**: ```bash -XX:+UseG1GC # 对大堆场景更友好 ``` 2. **修复内存泄漏** - **清理无用引用**:确保集合对象在不再使用时置为 `null`。 - **使用弱引用**:对缓存场景改用 `WeakHashMap` 或 `SoftReference`。 - **关闭资源**:在 `finally` 块中释放连接、流等资源。 3. **优化代码逻辑** - **分页处理数据**:避免一次性加载全量数据到内存。 - **限制缓存大小**:使用 `Guava Cache` 或 `Caffeine` 设置上限淘汰策略。 - **减少对象创建**:复用对象(如通过对象池)或使用基本类型替代包装类。 4. **引入监控与告警** - **APM 工具**:通过 **Arthas**、**SkyWalking** 实时监控内存使用。 - **日志分析**:通过 ELK 收集 OOM 相关日志并设置阈值告警。 --- #### 四、验证与预防 1. **压力测试** 使用 **JMeter** 或 **Gatling** 模拟并发场景,观察内存增长是否正常。 2. **代码审查** 定期检查静态集合、资源释放逻辑缓存设计。 3. **容器化部署** 在 Kubernetes 中设置内存 Limit,防止单一 Pod 耗尽节点资源。 --- **总结**:OOM 问题需结合日志分析、内存快照监控工具定位根本原因,通过参数调优、代码优化资源管理综合解决。关键是通过可观测性手段提前预防,而非被动应对。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值