一次线程阻塞问题排查

  • 一个后端项目会起多个线程进行数据处理然后入库,发现某个表的数据不更新了,于是想到了线程可能阻塞了,查看日志发现了报了一个oom:GC overhead limit exceeded,
  • 查询了一下这个oom的定义:当 Java 进程花费 98% 以上的时间执行 GC,但只恢复了不到 2% 的内存,且该动作连续重复了 5 次,就会抛出 java.lang.OutOfMemoryError:GC overhead limit exceeded 错误。简单地说,就是应用程序已经基本耗尽了所有可用内存, GC 也无法回收。
  • 按照如下思路排查
  1. 查看进程内存和cpu使用状态,ps -ef查看java进程pid 为1
  2. 查看java进程内各个线程的使用情况,top -Hp 加进程Id,现场没有保存,可以看到几个线程确实占了很大的cpu
    在这里插入图片描述
  3. 比如线程6占用cpu或者内存更高,需要查看此线程的堆栈,使用jstack pid命令查看当前java进程的堆栈状态
  4. 在top命令中,已经获取到了占用cpu资源较高的线程pid,将该pid转成16进制的值
  5. 每个线程都有一个nid,找到对应的nid即可,根据这个nid查看线程状态,RUNNABLE,线程处于执行中;BLOCKED,线程被阻塞WAITING,线程正在等待
  6. 没有进一步分析,通过堆栈信息显示了有问题代码的行数
    在这里插入图片描述
    代码里有一处死循环,里面起了几个新线程,要等子线程返回结果再执行主线程,可能是每次都new一个list一起的,每次执行完手动执行一下list.clear()确实没再出现过这个oom
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值