dump java oom 文件 jdk dump文件分析

转载

mob64ca1403528a 2023-08-18 15:59:19

文章标签 dump java oom 文件 jvm java 开发语言对象锁 文章分类 Java 后端开发

为啥需要dump内存文件

服务器CPU，内存占用空间飙升，或者GC频繁，首先需要排除的就是内存泄露，即内存中没有的对象的空间没有被及时回收导致的。而检测内存泄露就需要看哪种类在内存占了较多份额，从而定位到代码，然后修改。

分析思路

1. cpu，mem 飙升，确认是否web服务的问题并记录pid

2. 查看GC情况，如果每次gc效果不明显说明内存泄露

3. 导出dump，分析。定位占用top n的类

4. 分析并找到哪里创建的类占用了大量

制作dump

jstack

打印线程的栈信息，制作线程Dump。

jstack <进程ID> >> <输出文件>

jstack 2316 >> c:\thread.txt

## Linux下使用Kill命令制作线程Dump,输出线程Dump到目标Java进程的标准输出

kill -quit <进程ID>

kill -3 <进程ID>

jmap

使用jmap命令制作堆Dump

# 打印存活的对象大小和个数

jmap -histo:live <pid>

jmap -histo:live 64421 > live.log

dump java oom 文件 jdk dump文件分析_jvm

# 二进制方式存储堆文件

jmap -dump:format=b,file=文件名.hprof <进程ID>

以二进制方式生成文件/opt/wkt/wkt1.hprof，进程PID=64421

jmap -dump:format=b,file=/opt/wkt/wkt1.hprof 64421

dump java oom 文件 jdk dump文件分析_java_02

Dump读取前基础铺垫

Dump文件内容

制作时间
Java 版本
线程信息：名称、优先级、标识、状态、堆栈
死锁信息：存在直接Java线程的死锁时才包含。
内存信息：使用kill制作时才包含。

线程信息

dump java oom 文件 jdk dump文件分析_java_03

线程状态

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

监视器(Monitor)

监视器：对象锁的访问控制结构。也指对象的锁。
监视器项：线程的代理人。
进入区：表示线程通过synchronized要求获取对象的锁。如果对象未被锁住，则进入拥有者；否则则在进入区等待。一旦对象锁被其他线程释放，立即参与竞争。
拥有者：表示某一线程成功竞争到对象锁。
等待区：表示线程通过对象的wait方法，释放对象的锁，并在等待区等待被唤醒。

调用修饰

locked <地址> 目标
waiting to lock <地址> 目标
waiting on <地址> 目标
parking to wait for <地址> 目标
实例锁： (a 类名)——synchronized对象。
类锁：(a Class for 类名）——静态synchronized方法

locked：通过synchronized关键字，成功获取到了对象的锁，成为监视器的拥有者，在临界区内操作。对象锁是可以线程重入的。

at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at com..datasource.PooledConnection.prepareStatement

synchronized (conn) { // conn的类型是T4CConnection
// 同步块操作
}

waiting to lock：通过synchronized关键字，没有获取到了对象的锁，线程在监视器的进入区等待。在调用栈顶出现，线程状态为Blocked。

at com..impl.CacheHolder.isVisibleIn(CacheHolder.java:165)
- waiting to lock <0x0000000097ba9aa8> (a CacheHolder)
at com..impl.CacheGroup$Index.findHolder
at com..impl.ContextImpl.find
at com..BaseDataCenter.findInfo

synchronized (holder) { // holder的类型是CacheHolder
// 临界区操作
}

waiting on：通过synchronized关键字，成功获取到了对象的锁后，调用了wait方法，进去对象的等待区等待。在调用栈顶出现，线程状态为WAITING或TIMED_WATING。

at java.lang.Object.wait(Native Method)
- waiting on <0x00000000da2defb0> (a WorkingThread)
at com..WorkingManager.getWorkToDo
- locked <0x00000000da2defb0> (a WorkingThread)
at com..WorkingThread.run

synchronized(thread) {
     // 同步块操作……
     try {
           thread.wait();
     catch(InterruptException e) { /* 中断异常处理 */ }
}
parking to wait for
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000eb8f35c8> (a FutureTask$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport:156)
...
at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock()
park是基本的线程阻塞原语，不通过监视器在对象上阻塞。
随concurrent包会出现的新的机制，与synchronized体系不同。
synchronized模型相关的调用修饰
1.locked <对象地址> (a 类名)
使用synchronized申请对象锁成功，监视器的拥有者。
2. waiting to lock <对象地址> (a 类名)
使用synchronized申请对象锁未成功，在进入区等待。
3. waiting on <对象地址> (a 类名)
使用synchronized申请对象锁成功后，释放锁并在等待区等待
分析模式
wait on monitor entry 被阻塞的，肯定有问题
runnable 注意IO线程
in Object.wait() 注意非线程池等待
虚拟机执行Full GC时，会阻塞所有的用户线程。因此，即时获取到同步锁的线程也有可能被阻塞。

"wss-635" waiting for monitor entry
  java.lang.Thread.State: BLOCKED (on object monitor)
    at com..impl.CacheHolder.isVisibleIn(CacheHolder.java:165)
    - locked <0x0000000097ba9aa8> (a com..CacheHolder)