0x01-Java Dump小结

/ Java / 0 条评论 / 210浏览

JavaDump

  Java虚拟机的运行时快照。将Java虚拟机运行时的状态和信息保存到文件

线程Dump

  包含所有线程的运行状态。纯文本格式。

堆Dump

  包含线程Dump,并包含所有堆对象的状态。二进制格式。

制作JavaDump

JVM参数

-XX:+HeapDumpOnOutOfMemoryError

  指示虚拟机在发生内存不足错误时,自动生成堆Dump

命令行制作

  在JDK的bin目录下,包含了java命令及其他实用工具

  使用jps查看Java进程ID(PID);Linux下还可以使用ps命令

jps
jps -l
jps -v
ps -ef|grep java
jstack <进程ID> >> <输出文件>
jstack 2316 >> c:\thread.txt
## Linux下使用Kill命令制作线程Dump,输出线程Dump到目标Java进程的标准输出
kill -quit <进程ID> 
kill -3 <进程ID>

  使用jmap命令制作堆Dump

jmap -dump:format=b,file=<输出文件> <进程ID>

  jstat显示java进程的堆内存使用情况和GC情况

0x01-jstat.jpg

jstat -gcutil -pid 100 10
S0   — Heap上的 Survivor space 0 区已使用空间的百分比
S1   — Heap上的 Survivor space 1 区已使用空间的百分比 
E    — Heap上的 Eden space 区已使用空间的百分比 
O    — Heap上的 Old space 区已使用空间的百分比 
P    — Perm space 区已使用空间的百分比 
YGC  — 从应用程序启动到采样时发生 Young GC 的次数 
YGCT – 从应用程序启动到采样时 Young GC 所用的时间(单位秒) 
FGC  — 从应用程序启动到采样时发生 Full GC 的次数 
FGCT – 从应用程序启动到采样时 Full GC 所用的时间(单位秒) -- 总的fullgc时间
GCT  — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)

分析线程dump

线程Dump的内容

0x01-线程dump内容.jpg

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

线程信息

0x01-线程信息.jpg

线程状态

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

监视器(Monitor)

0x01-监视器.jpg

  当使用synchronized定义同步块时时,监视器是用来控制对象的锁的并发访问的结构。

synchronized(obj){
    // 同步块,只允许一个线程进入
}

synchronized void method(){
    // 同步块,只允许一个线程进入
}
监视器:对象锁的访问控制结构。也指对象的锁。
监视器项:线程的代理人。
进入区:表示线程通过synchronized要求获取对象的锁。如果对象未被锁住,则进入拥有者;否则则在进入区等待。一旦对象锁被其他线程释放,立即参与竞争。
拥有者:表示某一线程成功竞争到对象锁。
等待区:表示线程通过对象的wait方法,释放对象的锁,并在等待区等待被唤醒。

调用修饰

locked <地址> 目标
waiting to lock <地址> 目标
waiting on <地址> 目标
parking to wait for <地址> 目标

实例锁: (a 类名)——synchronized对象。
类锁:(a Class for 类名)——静态synchronized方法

  通过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
// 同步块操作
}

  通过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
// 临界区操作
}

   通过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) { /* 中断异常处理 */ }
}
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模型相关的调用修饰

  使用synchronized申请对象锁成功,监视器的拥有者。

  使用synchronized申请对象锁未成功,在进入区等待。

  使用synchronized申请对象锁成功后,释放锁并在等待区等待

线程动作

runnable:状态一般为RUNNABLE。
in Object.wait():等待区等待,状态为WAITING或TIMED_WAITING。
waiting for monitor entry:进入区等待,状态为BLOCKED。
waiting on condition:等待区等待、被park。
sleeping:休眠的线程,调用了Thread.sleep()。

分析线程Dump的工具

分析模式

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)

如何找到耗用cpu资源的线程

  Liunx系统可以使用ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpu 输出线程信息,可以将这些信息输出到文本文件以便核对。 在执行ps命令时,同时做线程dump,然后把ps命令中的tid十进制转换为16进制与线程dump中的nid匹配,就能分析出什么线程在占用大量cpu

分析堆Dump

Java虚拟机的内存模型

0x01-内存划分jpg.jpg

三块:年轻代、年老代、永久代。
新创建的对象放在年轻代。
年轻代垃圾回收后,残余的对象会被移动到年老代。
永久代存放类信息等,一般不会被回收。

  堆内存可细分为年轻代(新生代)与年老代(旧生代),年青代又可细分为一个Eden区和两个Survivor区(S0,S1),可通过-XX:SurvivorRatio=8设置Eden区和Survivor区大小,S0:S1:Eden的比例是1:1: 8 对象新创建时,都会分配在Eden区,Eden区满后,会触发young gc,清空Eden区,并将仍存活的对象copy到一个Survivor区,下次young gc时,会将Eden区存活的对象和Survivor区存活的对象一块copy到另一个Survivor区,如此循环,总会保证有一个Survivor区是空的,每在Survivor区熬过1次young gc,则对象年龄增加1岁,默认当年龄增加到15岁时(可通过-XX:MaxTenuringThreshold=15设置),若对象仍存活,则会被转移到年老代,当年老代内存满时则会触发full gc。

垃圾回收(GC)的介绍

垃圾回收根、对象的保留大

0x01-GC.jpg

从垃圾回收根开始,不再被引用到的对象即为垃圾对象
GC Root一般为线程、会话等对象
从对象上,能递归引用到的对象的合计大小
非准确数,循环引用等造成

内存不足的错误

OutOfMemoryError年老代内存不足。
OutOfMemoryError:PermGen Space永久带内存不足。
OutOfMemoryError:GC overhead limit exceed垃圾回收时间占用系统运行时间的98%或以上。

分析工具

使用MAT分析堆Dump,查看LeakSuspect及DominatorTree。
阅读代码,确定对象引用的错误关联而导致的生命周期错误

使用飞行记录

  settings=profile这个参数必须加,不加会使用默认模板制作,有些参数无法收集到   模板路径在"\Java\jre7\lib\jfr"

  飞行记录主要关注几点:TLAB\垃圾回收\线程转储