【死磕JVM】看完这篇我也会排查JVM内存过高了 就是玩儿

于 2024-04-10 03:13:38 发布
阅读量1.4k 收藏 23
点赞数 20
分类专栏： 2024年程序员学习 文章标签： jvm java 开发语言
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2401_84103386/article/details/137576013
版权
1、top 查看进程

受到报警信息后，拿top命令去查询

[root@root ~]# top

在这里插入图片描述

查看内存不断增长，CPU占用率居高不下的。top后你会看到它的PID（31061）。它占比比较高。

2、top -Hp 查看线程

找到CPU占用比较高的进程PID，这里我们以 java 的进程为例

使用命令 top -Hp 31061，这个时候它会把这个进程里面所有的线程全部线程都罗列出来吗，这些都是Java这个进程里面内部的一些线程，如下图所示：

在这里插入图片描述

我们会看到每个线程的占比都差不多，偶尔会有某一个线程比较高，在某些线程占得比较高的时候，这个小例子最终会是垃圾回收的线程占得比较高，因为垃圾回收不过来了，所以需要不停的来回回收，每次都回收一点点，实际这种例子里面非常有可能是你业务逻辑线程，那一块的业务逻辑线程占比非常高，这是时候就需要用到另外的命令——jstack

3、jstack

当我们使用 top -Hp 知道了是哪个线程后，我们下一步就可以使用 jstack命令，比如我们要查看31083这个线程号，31061是我们的进程PID，我们要定位某一个线程cpu的占比会比其他cpu高很多，那么我们就要定位这个线程里面到底是什么样的问题的时候，就需要把这个线程号（31083）记下来。

因为 jstack 用到的线程号是16进制的，所以我们需要把31083的10进制转换成16进制才可以

特点：

  • 每个线程有自己的线程号码，里面有线程的状态，可以观察线程是否阻塞，如果长时间的wait和block说明这个线程是有问题的
4、转换16进制

因为Java线程文件中的线程ID是16进制，所以需要将线程ID从十进制转换成十六进制

命令：echo "obase=16;31083" | bc

在这里插入图片描述

5、jstack用法解析

[root@root ~]# jstack

Usage:

jstack [-l]

(to connect to running process)

jstack -F [-m] [-l]

(to connect to a hung process)

jstack [-m] [-l]

(to connect to a core file)

jstack [-m] [-l] [server_id@]

(to connect to a remote debug server)

Options:

-F to force a thread dump. Use when jstack does not respond (process is hung)

-m to print both java and native frames (mixed mode)

-l long listing. Prints additional information about locks

-h or -help to print this help message

6、jstack查看输出

我们也可以用 jps或者java ps -ef| java来查看Java进程，这里我们用jps来查看

[root@root ~]# jps

在这里插入图片描述

[root@root ~]# jstack 31061

“pool-1-thread-3” #10 prio=5 os_prio=0 tid=0x00007f3568105800 nid=0x7961 waiting on condition [0x00007f35455cf000]

java.lang.Thread.State: WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)

at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)

at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)

at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)

“pool-1-thread-2” #9 prio=5 os_prio=0 tid=0x00007f3568103800 nid=0x7960 waiting on condition [0x00007f35456d0000]

java.lang.Thread.State: WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)

at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)

at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)

at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)

“pool-1-thread-1” #8 prio=5 os_prio=0 tid=0x00007f3568102000 nid=0x795f waiting on condition [0x00007f35457d1000]

java.lang.Thread.State: WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)

at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)

at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)

at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)

“Service Thread” #7 daemon prio=9 os_prio=0 tid=0x00007f35680b4000 nid=0x795d runnable [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

“C1 CompilerThread1” #6 daemon prio=9 os_prio=0 tid=0x00007f35680b1000 nid=0x795c waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

“C2 CompilerThread0” #5 daemon prio=9 os_prio=0 tid=0x00007f35680af000 nid=0x795b waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

“Signal Dispatcher” #4 daemon prio=9 os_prio=0 tid=0x00007f35680ad800 nid=0x795a runnable [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

“Finalizer” #3 daemon prio=8 os_prio=0 tid=0x00007f356807c800 nid=0x7959 in Object.wait() [0x00007f3558301000]

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)

  • locked <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)

at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

“Reference Handler” #2 daemon prio=10 os_prio=0 tid=0x00007f3568077800 nid=0x7958 in Object.wait() [0x00007f3558402000]

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock)

at java.lang.Object.wait(Object.java:502)

at java.lang.ref.Reference.tryHandlePending(Reference.java:191)

  • locked <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock)

at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

“main” #1 prio=5 os_prio=0 tid=0x00007f3568009800 nid=0x7956 waiting on condition [0x00007f356ed59000]

java.lang.Thread.State: TIMED_WAITING (sleeping)

at java.lang.Thread.sleep(Native Method)

at FullGCTest.main(FullGCTest.java:35)

“VM Thread” os_prio=0 tid=0x00007f356806e000 nid=0x7957 runnable

“VM Periodic Task Thread” os_prio=0 tid=0x00007f35680b7000 nid=0x795e waiting on condition

JNI global references: 205

在这里插入图片描述

通过thread dump分析线程状态

大多数情况下会基于thead dump 分析当前各个线程的运行情况，如是否存在死锁，是否存在一个线程长时间持有锁不释放等等

在dump中，线程一般存在如下几种状态：

1、RUNNABLE，线程处于执行中

2、BLOCKED，线程被阻塞

3、WAITING，线程正在等待

locked <0x000000076bf62208>说明线程 对地址为0x000000076bf62208对象进行了加锁；

waiting to lock <0x000000076bf62208>说明线程 在等待地址为0x000000076bf62208对象上的锁；

waiting for monitor entry [0x000000001e21f000]说明线程 是通过synchronized关键字进入了监视器的临界区，并处于"Entry Set"队列，等待monitor；

waiting on <0x0000000088ca3310> (a java.lang.Object)等待锁的释放

假如有一个进程中有100个线程，很多线程都在waiting on 某一把锁，然后线程不该阻塞的被阻塞了，该结束的没结束掉，一定要找到哪个线程持有这把锁 ，我们可以搜索 jstack dump 的信息，找到<0X...>的信息，看哪个线程只有了这把锁，一般这个线程状态是RUNNABLE，表示这个线程正在运行但是一直持有这把锁不释放，那么就会导致整个线程的死锁

7、jstack分析死锁

public class TestDeadLock {

private static Object obj1 = new Object();

private static Object obj2 = new Object();

public static void main(String[] args) {

new Thread(new Thread1()).start();

new Thread(new Thread2()).start();

}

private static class Thread1 implements Runnable {

@Override

public void run() {

synchronized (obj1) {

System.out.println(“Thread1 拿到了 obj1 的锁！”);

try {// 停顿2秒的意义在于，让Thread2线程拿到obj2的锁

Thread.sleep(2000);

} catch (InterruptedException e) {

e.printStackTrace();

}

synchronized (obj2) {

System.out.println(“Thread1 拿到了 obj2 的锁！”);

}

}

}

}

private static class Thread2 implements Runnable {

@Override

public void run() {

synchronized (obj2) {

System.out.println(“Thread2 拿到了 obj2 的锁！”);

try {

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
img
img
img
img
img
img

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
img

最后

分享一些系统的面试题，大家可以拿去刷一刷，准备面试涨薪。

这些面试题相对应的技术点：

  • JVM
  • MySQL
  • Mybatis
  • MongoDB
  • Redis
  • Spring
  • Spring boot
  • Spring cloud
  • Kafka
  • RabbitMQ
  • Nginx
  • …

大类就是：

  • Java基础
  • 数据结构与算法
  • 并发编程
  • 数据库
  • 设计模式
  • 微服务
  • 消息中间件

程序员，每个月给你发多少工资，你才会想老板想的事？

程序员，每个月给你发多少工资，你才会想老板想的事？

程序员，每个月给你发多少工资，你才会想老板想的事？

程序员，每个月给你发多少工资，你才会想老板想的事？

程序员，每个月给你发多少工资，你才会想老板想的事？

程序员，每个月给你发多少工资，你才会想老板想的事？

程序员，每个月给你发多少工资，你才会想老板想的事？

程序员，每个月给你发多少工资，你才会想老板想的事？

程序员，每个月给你发多少工资，你才会想老板想的事？

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
img

-1712690007398)]

[外链图片转存中…(img-HkvUMR4K-1712690007398)]

[外链图片转存中…(img-iALOEGWn-1712690007399)]

[外链图片转存中…(img-DfKqTAMI-1712690007399)]

[外链图片转存中…(img-yxn3Pz7Z-1712690007399)]

[外链图片转存中…(img-m0aJkhWr-1712690007400)]

[外链图片转存中…(img-3hBKOUZM-1712690007400)]

[外链图片转存中…(img-MjeoHeAc-1712690007401)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-MB0x5g0P-1712690007401)]

2401_84103386
关注
  • 20
    点赞
  • 踩
  • 23
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
jvm堆外内存排查详解
少说，多做
01-31 1万+
内存泄漏想必大家并不陌生，对于jvm的内存泄漏，有很多排查手段和方便的排查工具，例如MAL，但是对于非jvm的内存，如直接内存的使用，排查起来较为麻烦，下面介绍一下相关的排查手段。
jvm问题排查
04-20
jvm问题排查的一个工具手册
如何排查Java内存泄漏？看完我给跪了！
01-20
没有经验的程序员经常认为Java的自动垃圾回收完全使他们免于担心内存管理。这是一个常见的误解：虽然垃圾收集器做得很好，但即使是最好的程序员也完全有可能成为严重破坏内存泄漏的牺牲品。让我解释一下。 当不必要地维护不再需要的对象引用时，会发生内存泄漏。这些泄漏很糟糕。首先，当程序消耗越来越多的资源时，它们会对计算机施加不必要的压力。更糟糕的是，检测这些泄漏可能很困难：静态分析通常很难精确识别这些冗余引用，现有的泄漏检测工具会跟踪和报告有关单个对象的细粒度信息，产生难以解释且缺乏精确度的结果。 换句话说，泄漏要么太难以识别，要么使用太过具体而无用术语来识别。 实际上有四类内存问题具有相似和重叠的特征
排查线上环境 JVM 内存使用过大问题
最新发布
小毕超博客
03-10 547
本文使用`JVM`常用的检查工具 `jcmd、jmap 、mat` 工具排查内存使用过大问题。
一次Jvm old过高的排查过程实战记录
08-26
主要给大家介绍了一次Jvm old过高的排查过程，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
CPU、内存打满排查流程、JVMGC调优
bit-cafe
01-19 3167
This is my, my, my, beautiful day! 一、问题确认 1、top 命令查看各个进程cpu、内存使用量 top　　//每隔5秒显式所有进程的资源占用情况 top -d 2//每隔2秒显式所有进程的资源占用情况 top -c//每隔5秒显式进程的资源占用情况，并显示进程的命令行参数(默认只有进程名) top -p 12345 ...
jvm内存泄漏排查
magic_kid_2010的专栏
04-14 3492
一、内存溢出和内存泄露 一种通俗的说法。 1、内存溢出：你申请了10个字节的空间，但是你在这个空间写入11或以上字节的数据，出现溢出。 2、内存泄漏：你用new申请了一块内存，后来很长时间都不再使用了（按理应该释放），但是因为一直被某个或某些实例所持有导致 GC 不能回收，也就是该被释放的对象没有释放。点击此处查看内存泄漏更多说明。 1.1 内存溢出 java.lang.OutOfMemoryError，是指程序在申请内存时，没有足够的内存空间供其使用，出现OutOfMemoryError。查看&
如何排查JVM内存占用过高
会飞的猪
02-17 5024
1、当程序没有内存溢出OOM(out of memory)时 注意：jmap需要依赖jdk的devel包 查询命令： # jmap -histo pid 先用top命令查询程序的pid # top 找到pid后 # jmap -histo 878193
【死磕JVM】用Arthas排查JVM内存 真爽！我从小用到大
热门推荐
牧小农
04-21 2万+
Arthas是啥 当我们系统遇到JVM或者内存溢出等问题的时候，如何对我们的程序进行有效的监控和排查，就发现了几个比较常用的工具，比如JDK自带的 jconsole、jvisualvm还有一个最好用的工具——jprofiler，但是这个是收费的，或者除了很有钱的公司，一般很少人会用这个，还有一个就是我们今天的主角——Arthas ，为什么今天会重点讲这个呢？ 官网地址：http://arthas.gitee.io/ GitHub地址：https://github.com/alibaba/arthas/ .
【实战总结】JVM内存溢出问题排查
雪落夜的专栏
01-06 7429
这里先说一下结论，堆内存总共3.1G，Suspect1问题指向一个慢SQL，间接导致1.7G内存无法回收，Suspect2 由com.mysql.jdbc.ByteArrayRow导致1.2G内存无法回收，原始sql指向与Suspect1同样的慢SQL，这样就基本可以确定是这一条慢SQL导致的内存溢出。打开MAT，File--->open dump file--->选择本次输出的dump文件，可以看到如下总览页面，点击Leak Suspects查看内存泄露分析。一周前系统有一次投产，之后再没有更新过系统。
JVM堆内存溢出排查
李秀才的博客
12-05 2414
是否有小伙伴在碰到了OOM的时候，抓耳挠腮，不知如何下手，通过这篇保姆级的教程，可以教会你快速定位堆内存溢出的bug，本篇讲述的主题是生成dump文件以及通过Visual VM分析dump文件
jvm排查cpu占用过高的线程
01-09
cpu占用过高，服务器卡死，问题排查 java进程占用CPU过高常见的两种情况： 代码中有死循环或者接近死循环的操作 快速创建大量临时变量，导致频繁触发gc回收 问题解决： 1、用top命令找到cpu占用率最高的进程号是...
Java高级面试JVM虚拟机、内存结构、垃圾回收机制
12-28
java工程师高级面试之JVM虚拟机底层原理篇：VM种类，内存结构，运行原理，垃圾回收算法，各种垃圾回收器等。
idea插件JVM内存工具JProfiler11
12-09
idea插件JVM内存工具JProfiler11，下载完，即可导入idea，可idea快捷打开使用。
JVM内存问题排查
01-09
初步诊断思路考虑是不是这台机器上的某个服务把内存撑爆了，所以开始排查内存问题，使用jdk自带脚本，进行内存诊断分析。 1.查看所有Java应用占用的进程（linux常用的是ps -ef|grep java） jps -l 2.查看需要监控...
JVM内存溢出问题排查
Tester_muller的博客
08-31 4978
当然，分析和解决内存溢出相关问题的步骤，不是固定的，还需要根据实际情况去做调整，止损是第一位的，正常情况我们需要快速重启的先，重启可以使服务快速恢复，但是只重启，指标不治本，如果没有定位到溢出的原因，重启一段时间可能又会溢出。内存溢出 out of memory : 通俗理解就是内存不够用了，是我们工作当中经常会遇到的问题，内存溢出有可能发生在正常的情况下，而非代码层面问题导致，比如高并发下，大量的请求占用内存，垃圾回收机制无法进行回收，而导致的内存溢出,这种情况就需要我们去调整架构了。...
分别在Linux和Windows下设置JVM内存的简单方法
01-20
Linux服务器： 在/usr/local/apache-tomcat-5.5.23/bin 目录下的catalina.sh 添加:JAVA_OPTS=’-Xms512m -Xmx1024m’ 或者 JAVA_OPTS=”-server -Xms800m -Xmx800m  -XX:MaxNewSize=256m” 或者 CATALINA_OPTS=”-...
JVM堆内存分析工具，OOM排查工具。包括ha和mat两种
03-21
ha和mat两种工具，用来进行JVM堆内存分析
jvm内存溢出故障排查
11-28
当JVM运行的程序需要的内存超过了JVM所能提供的最大内存时，就会发生内存溢出。解决内存溢出问题的方法因业务和系统大小而异。以下是一些可能有用的故障排查方法： 1. 查看错误日志：当内存溢出时，JVM会在错误日志中记录相关信息。查看错误日志可以帮助你了解内存溢出的原因和位置。 2. 使用Heap Dump文件：Heap Dump文件是一个二进制文件，它记录了JVM中所有对象的状态。当内存溢出时，可以使用Heap Dump文件来分析内存使用情况。可以使用jmap命令生成Heap Dump文件，例如： ```shell jmap -dump:format=b,file=heapdump.bin <pid> ``` 其中，`<pid>`是JVM进程的ID。 3. 使用内存分析工具：内存分析工具可以帮助你分析Heap Dump文件，找出内存泄漏和内存溢出的原因。常用的内存分析工具包括Eclipse Memory Analyzer和VisualVM。 4. 调整JVM参数：可以通过调整JVM参数来避免内存溢出。例如，可以增加JVM的最大堆内存大小，或者调整垃圾回收器的参数。 以下是一个使用jmap命令生成Heap Dump文件的例子： ```shell jmap -dump:format=b,file=heapdump.bin 1234 ``` 其中，`1234`是JVM进程的ID。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值