javadump分析教学内容
利用 Java dump 进行 JVM 故障诊断
清单5. Java dump 文件片断 NULL ---------------------------------------------0SECTION TITLE subcomponent dump routine NULL 1TISIGINFO =============================== Dump Event "gpf" (00002000) received 2008/11/12 at 20:45:24
页码，1/6
利用 Java dump 进行 JVM 故障诊断
WebSphere Application Server 故障诊断最佳实践 简介： 本文将向读者介绍利用 Java dump 诊断 JVM Crash 和 CPU 饥饿等问题的方法和技巧，以便使用户更加全面的了解 Java dump 在故障诊断过程中的作用。 发布日期： 2009 年 3 月 11 日 级别： 初级 更多关于 Java dump 进行 JVM 故障诊断的内容，请参考：
l
在 WAS V6.1 应用程序中跟踪死锁：本文讲述了如何使用 WAS V6.1 中的线程转储工具了解您的系统环境，检查是否发生死锁以及提取信息来帮助避免或解决自己应用程序的死锁情 况。
本文对上面的文章做了进一步的补充，介绍了如何利用 Java dump 诊断 JVM Crash 和 CPU 饥饿等问题的方法和技巧。 引言 对于大型 java 应用程序来说，再精细的测试都难以堵住所有的漏洞，即便我们在测试阶段进行了大量卓有成效的工作，很多问题还是会在生产环境下暴露出来，并且很难在测试环境中进行重 现。JVM 能够记录下问题发生时系统的运行状态并将其存储在转储(dump)文件中，从而为我们分析和诊断问题提供了重要的依据。常见的转储文件包括 Java Dump， Heap dump 和 System dump。这里我们主要介绍 Java dump 在 JVM 故障诊断中的应用。 Java dump，也叫做 Thread dump，是 JVM 故障诊断中最重要的转储文件之一。JVM 的许多问题都可以使用这个文件进行诊断，其中比较典型的包括线程阻塞，CPU 使用率过高，JVM Crash，堆内存不足，和类装载等问题。作为一款轻量级（与 Heap dump 和 System dump 相比）的转储文件，Java dump 的确是我们诊断 JVM 问题的首选。本文将系统的介绍使用 Java dump 进行 JVM 故障诊断的方法和技巧，希望能够为大家提供一些帮助。
jvm dump参数
JVM Dump参数什么是JVM Dump？JVM（Java虚拟机）Dump是指在Java应用程序运行时，将JVM的内部状态转储到文件中的过程。
这些转储文件包含了应用程序在运行时的堆栈跟踪、线程信息、对象实例等重要信息。
通过分析这些转储文件，我们可以了解应用程序在发生故障或异常时的状态，有助于定位和解决问题。
为什么需要JVM Dump？在调试和解决Java应用程序中的问题时，JVM Dump起着关键作用。
它可以提供以下信息：1.内存快照：通过JVM Dump，可以获取应用程序在某个时间点的内存快照。
这对于分析内存泄漏、内存溢出等问题非常有帮助。
2.线程信息：JVM Dump中包含了所有线程的堆栈跟踪和状态信息。
这对于查找死锁、线程阻塞等问题非常有帮助。
3.对象实例：通过JVM Dump，可以获取当前堆中存在的所有对象实例以及它们的引用关系。
这对于分析对象创建和销毁情况、查找对象泄漏等问题非常有帮助。
4.GC信息：JVM Dump中还包含了GC（垃圾回收）的详细信息，包括GC算法、GC线程状态、堆内存使用情况等。
这对于分析GC性能和调优非常有帮助。
综上所述，JVM Dump提供了详尽的应用程序状态信息，帮助开发人员快速定位和解决问题，提高应用程序的稳定性和性能。
如何生成JVM Dump？在Java应用程序中，可以通过以下方式生成JVM Dump：1.使用命令行工具：可以使用jmap命令生成JVM Dump。
例如，执行以下命令将生成一个名为dump.bin的转储文件：jmap -dump:format=b,file=dump.bin <pid>其中，<pid>是Java进程的进程ID。
2.使用JDK工具：JDK提供了一些图形化工具，如jvisualvm、Java MissionControl等，可以通过这些工具生成JVM Dump。
在这些工具中，通常有一个按钮或菜单项可以直接生成转储文件。
JavaCore HeapDump文件及其分析方法
产生时间Java程序运行时，有时会产生JavaCore及HeapDump文件，它一般发生于Java程序遇到致命问题的情况下。
∙有时致命问题发生后，Java应用不会死掉，还能继续运行；∙但有时致命问题发生，Java进程会死掉；为了能够保留Java应用发生致命错误前的运行状态，JVM在死掉前产生两个文件，分别为JavaCore及HeapDump文件。
有何区别JavaCore是关于CPU的，而HeapDump文件是关于内存的。
∙JavaCore文件主要保存的是Java应用各线程在某一时刻的运行的位置，即JVM执行到哪一个类、哪一个方法、哪一个行上。
它是一个文本文件，打开后可以看到每一个线程的执行栈，以stack trace的显示。
通过对JavaCore文件的分析可以得到应用是否“卡”在某一点上，即在某一点运行的时间太长，例如数据库查询，长期得不到响应，最终导致系统崩溃等情况。
∙HeapDump文件是一个二进制文件，它保存了某一时刻JVM堆中对象使用情况，这种文件需要相应的工具进行分析，如IBM Heap Analyzer这类工具。
这类文件最重要的作用就是分析系统中是否存在内存溢出的情况。
怎么生成这两个文件可以用手工的方式生成，当我们会遇到系统变慢或无响应的情况，这时就以采用手工的方式生成JavaCore及HeapDump文件。
在Unix/Linux上，产生这两个文件的方法如下：# ps -ef | grep javauser 46164582017:30 pts/0 00:00:00 grep javaroot 558010 Oct27 ? 00:02:27/usr/bin/java -server -XX:PermSize=64M-XX:MaxPermSi ze=128m-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.uti l.logging.config.file=/usr/local/tomcat8090/conf/logging.properties-Djava.endorsed.dirs=/u sr/local/tomcat8090/endorsed -classpath :/usr/local/tomcat8090/bin/bootstrap.jar -Dcatali na.base=/usr/local/tomcat8090-Dcatalina.home=/usr/local/tomcat8090 -Djava.io.tmpdir=/ usr/local/tomcat8090/temp org.apache.catalina.startup.Bootstrap start# kill -3 5580首先，找出Java进程id ，然后再执行…kill -3 进程号‟的操作，等文件生成后再做一次同样的操作，再产生一组文件。
Dump文件分析（转发）
Dump⽂件分析（转发）原⽂：本⽂主要介绍Dump⽂件结构，理解Dump⽂件对于分析线程⾼占⽤、死锁、内存溢出等⾼级问题有⾮常重要的指导意义。
什么是Dump⽂件Dump⽂件是进程的内存镜像。
可以把程序的执⾏状态通过调试器保存到dump⽂件中。
Dump⽂件是⽤来给程序编写⼈员调试程序⽤的，这种⽂件必须⽤专⽤⼯具软件打开。
如何⽣成Dump⽂件使⽤命令：jstack pid可以查看到当前运⾏的java进程的dump信息。
Dump⽂件结构⾸先浏览⼀下dump⽂件的⽂本内容：Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode):"Attach Listener" #37 daemon prio=9 os_prio=0 tid=0x00007f87b42b7000 nid=0x680f waiting on condition [0x0000000000000000]ng.Thread.State: RUNNABLE"Druid-ConnectionPool-Destory-331358539" #36 daemon prio=5 os_prio=0 tid=0x00007f87a4278800 nid=0x67e4 waiting on condition [0x00007f87b8dce000] ng.Thread.State: TIMED_WAITING (sleeping)at ng.Thread.sleep(Native Method)at com.alibaba.druid.pool.DruidDataSource$DestroyConnectionThread.run(DruidDataSource.java:1724)"Druid-ConnectionPool-Create-331358539" #35 daemon prio=5 os_prio=0 tid=0x00007f87a4022000 nid=0x67e3 waiting on condition [0x00007f87ce86a000] ng.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for <0x00000000b3804848> (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 com.alibaba.druid.pool.DruidDataSource$CreateConnectionThread.run(DruidDataSource.java:1629)"Abandoned connection cleanup thread" #31 daemon prio=5 os_prio=0 tid=0x00007f87e0d91800 nid=0x672b in Object.wait() [0x00007f87cd2c2000]ng.Thread.State: TIMED_WAITING (on object monitor)at ng.Object.wait(Native Method)at ng.ref.ReferenceQueue.remove(ReferenceQueue.java:143)- locked <0x00000000b422d1e8> (a ng.ref.ReferenceQueue$Lock)at com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:43)"DestroyJavaVM" #30 prio=5 os_prio=0 tid=0x00007f87e0008800 nid=0x670b waiting on condition [0x0000000000000000]ng.Thread.State: RUNNABLE"http-nio-8081-AsyncTimeout" #28 daemon prio=5 os_prio=0 tid=0x00007f87e016e800 nid=0x6727 waiting on condition [0x00007f87b94cf000]ng.Thread.State: TIMED_WAITING (sleeping)at ng.Thread.sleep(Native Method)at org.apache.coyote.AbstractProtocol$AsyncTimeout.run(AbstractProtocol.java:1211)at ng.Thread.run(Thread.java:745)"http-nio-8081-Acceptor-0" #27 daemon prio=5 os_prio=0 tid=0x00007f87e0166000 nid=0x6726 runnable [0x00007f87b95d0000]ng.Thread.State: RUNNABLEat sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)- locked <0x00000000b410d480> (a ng.Object)at .NioEndpoint$Acceptor.run(NioEndpoint.java:455)at ng.Thread.run(Thread.java:745)"http-nio-8081-ClientPoller-0" #26 daemon prio=5 os_prio=0 tid=0x00007f87e0292800 nid=0x6725 runnable [0x00007f87b96d1000]ng.Thread.State: RUNNABLEat sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)- locked <0x00000000b410d6c0> (a sun.nio.ch.Util$2)- locked <0x00000000b410d6b0> (a java.util.Collections$UnmodifiableSet)- locked <0x00000000b410d668> (a sun.nio.ch.EPollSelectorImpl)at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)at .NioEndpoint$Poller.run(NioEndpoint.java:793)at ng.Thread.run(Thread.java:745)"http-nio-8081-exec-10" #25 daemon prio=5 os_prio=0 tid=0x00007f87e028c000 nid=0x6724 waiting on condition [0x00007f87b97d2000]ng.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for <0x00000000b410d898> (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.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:103)at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:31)at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)at ng.Thread.run(Thread.java:745)其中每个空⾏⽤于分隔⼀个线程，每个线程的信息是以堆栈信息的⽅式展开，显⽰了⽬前正在调⽤的⽅法以及所在的代码⾏。
dump函数的用法 -回复
dump函数的用法-回复[Dump函数的用法]Dump函数是一种程序员常用的调试工具，用于输出变量的详细信息，以便于程序员进行错误诊断和调试。
在本文中，我们将深入探讨Dump函数的用法，包括其功能、语法和一些常见的应用场景。
一、Dump函数的功能和作用Dump函数通常用于输出变量的值、数据类型和其他相关信息。
它可以帮助程序员了解变量的实际值，进而找出代码中的错误或潜在问题。
Dump函数的主要功能包括：1. 输出变量的值。
通过使用Dump函数，可以打印出变量的具体数值，以及数组、结构体等复杂数据结构中的元素。
2. 输出变量的数据类型。
Dump函数可以告诉我们变量的数据类型，这对于排查类型错误非常有帮助。
3. 输出变量的内存地址。
有时候，我们需要了解变量在内存中的位置，以便于进行更深入的调试。
Dump函数可以提供变量的内存地址信息。
二、Dump函数的语法和参数在不同的编程语言和调试工具中，Dump函数的具体语法和参数可能会有所不同。
下面是一些常见的Dump函数语法示例：1. Python中的Dump函数在Python中，我们经常使用pprint模块来实现类似于Dump函数的功能。
pprint模块提供了pretty print的功能，可以输出可读性更高的变量信息。
以下是pprint模块的使用方法的示例代码：pythonimport pprintdata = {'Name': 'John', 'Age': 25, 'Residence': 'USA'}pprint.pprint(data)这段代码将输出类似于以下内容的结果：{'Age': 25,'Name': 'John','Residence': 'USA'}2. PHP中的Dump函数在PHP中，我们通常使用var_dump函数来实现类似于Dump函数的输出。
一次Java内存溢出异常的分析过程
一次Java内存溢出异常的分析过程2011-08-28 00:00中国IT实验室佚名字号：A+|A-前些天，服务器上一个服务跑了一个多月突然当掉了。
看了下日志，程序抛出了ng.OutOfMemoryError，之前也出现过同样的错误，服务跑了三个月内存溢出。
出现这个异常，初步判断是程序有内存泄漏，接下来需要利用一些工具来分析具体原因。
首先使用jdk自带的工具jmap转储(dump)java内存堆数据到本地文件中。
jmap转储(dump)命令格式如下：jmap -dump:表示dump选项，表示需要dump的java应用程序的进程IDdump-options可以有以下三种参数，参数之间用逗号隔开：live，只dump活动的object，如果没有指定，表示dump所有objectformat=b，字节流格式file=，是转储文件的保存路径下面是dump命令的一个例子:jmap -dump:format=b,file=heap.bin 8023dump完成后，用Eclipse Memory Analyzer打开转储文件进行分析。
Eclipse Memory Analyzer是一个java内存堆转储文件分析工具，可以生成内存分析报告(包括内存泄露Leak Suspects )。
下面是分析完成后查看Top Consumers所看到的图表:看到这两张图表，问题就比较明朗了。
berkeley db中的数据结点com.sleepycat.je.tree.BIN占用了大量内存，导致内存溢出了。
为了提高访问效率，berkeley db会缓存大量的结点，缓存大小限制可以在EnvironmentConfig设置，默认为jvm 内存大小限制的60%。
而这个应用程序中使用了5个EnvironmentImpl，并且都未单独设置缓存大小，总的缓存限制为jvm内存限制的300%(图表中BIN结点已经占用了94.55%的内存)，远远超出java的内存限制。
记一次dump文件分析历程
记⼀次dump⽂件分析历程⼀、背景今天下午，正酣畅淋漓的搬砖，突然运维同事在群⾥通知，核⼼服务某个节点内存异常，服务假死。
神经⼀下⼦紧张起来，赶紧跑到运维那边观察现象。
观察的结果是服务内存溢出，该服务是核⼼服务，分配了5G内存。
运维在转存快照后，⽴刻重启服务后正常。
在接下来的⼀段时间⾥，另⼀台服务节点也发⽣了同样的情况。
⼆、分析过程这个服务是另外⼀个同事负责开发的，本着学习的态度，在拿到运维转存的dump⽂件后，就准备尝试着分析下问题，由于之前没有类似的经历，于是先在⽹上查了下⼀般怎么分析类似的问题。
⾸先尝试使⽤MAT(Memory Analyzer)⼯具进⾏分析，下载后就准备载⼊dump⽂件，很不幸由于dump⽂件过⼤，载⼊失败了，于是调⼤了内存⼤⼩，尝试再次载⼊，但此时这个⽂件不再尝试重新载⼊，直接提⽰载⼊失败。
先不纠结⼯具的问题，然后⽹上说JDK⾃带的jvisualvm也可以⽤来分析dump⽂件, 但也遇到了同样内存不⾜的问题，再尝试修改jvisualvm的内存限制后, 成功载⼊了。
看到的界⾯是这样的，很明显看到char[]占⽤了近70%的内存，接近4G，这太不正常了，点进去看对应的实例(加载的⾮常慢，需要耐⼼)。
在实例数界⾯中看到实例数达到了千万级，⼤部分都是⼀些⽂件的路径字符串信息。
在业务中，我们会⽣成很多临时⽂件，然后这些临时⽂件会删除，这⾥⾯⼤部分保存的是这些临时⽂件路径。
到这⾥导致内存泄露的原因似乎找到了，但好像⼜还不够，是什么原因导致这些临时变量没有被回收呢。
回到家后，还是想着这个事情，于是⼜开始研究起来，这个时候想起来可以再⽤MAT试着分析下，毕竟据说⼯具很强⼤。
重启了电脑之后，经过漫长的等待，载⼊成功了(果然重启能解决⼀切问题)。
MAT的界⾯是这样的，⾥⾯包含的信息⽐较多，对于我这个菜鸟来说，确实⼀下⼦不知道看哪⾥。
那就⼀个个慢慢看吧，Histogram⾥⾯的与使⽤jvisualvm中看到的信息是相同的。
本地模拟内存溢出并分析Dump文件
本地模拟内存溢出并分析Dump⽂件java Dump⽂件分析前⾔dump⽂件是java虚拟机内存在某⼀时间点的快照⽂件，⼀般是.hprof⽂件，下⾯⾃⼰模拟⼀下本地内存溢出，⽣成dump⽂件，然后通过mat ⼯具分析的过程。
配置虚拟机参数要想本地模拟oom异常，那么建议将堆内存设置的⼩⼀点，那样容易触发-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${⽬录} -Xms20m -Xmx20m1. -XX:+HeapDumpOnOutOfMemoryError表⽰jvm发⽣oom异常时，⾃动⽣成dump⽂件，⽂件格式⼀般是：java_pid20804.hprof ，其中20804是java进程id2. -XX:HeapDumpPath=${⽬录}，表⽰⽣成dump⽂件的⽬录，也可以指定⽂件名称，例如：-XX:HeapDumpPath=${⽬录}/java_heapdump.hprof，此步骤实验出了点问题，暂时跳过3. -Xms：表⽰给jvm分配的初始化堆内存4. -Xmx：表⽰最⼤堆内存模拟oom异常的程序public class Test1 {public static void main(String[] args) {List<Person> personList = new ArrayList<>();while (true){Person person = new Person();person.setDate(new Date());person.setAge(20);person.setName("test");personList.add(person);}}}很明显，⼀直创建Person对象，却⼜⽆法释放，很快就内存溢出了。
ng.OutOfMemoryError: GC overhead limit exceededDumping heap to java_pid21892.hprof ...Heap dump file created [33907612 bytes in 0.152 secs]Exception in thread "main" ng.OutOfMemoryError: GC overhead limit exceededat Test1.main(Test1.java:15)⽣成的⽂件名称是java_pid21892.hprof，在项⽬的根⽬录下⾯，⽂件⼤⼩33.9MMAT⼯具分析dump⽂件预览预览界⾯，能清楚的看到整个堆总内存18.7M，但是有18.3M的内存被⼀个类的对象占⽤了功能介绍1. Histogram柱状图：以class类的维度展⽰每个class类的实例存在的个数、占⽤的 [Shallow内存] 和 [Retained内存] ⼤⼩，可以分别排序显⽰，从图中看到，Person类的实例占⽤内存最⼤，⽽它就是没有回收引起内存溢出的对象2. Dominator Tree⽀配树：该视图以实例对象的维度展⽰当前堆内存中Retained Heap占⽤最⼤的对象，以及依赖这些对象存活的对象的树状结构展开会展⽰下⼀层⼦节点，可以这么理解：⽗节点引⽤了⼦节点，⼦节点没有被回收，所以⽗节点也没法被回收3. Thread Overview：：可以看到线程栈/线程对象信息把线程进⾏⼀个排序，同样能看到引起内存溢出的是最上⾯线程⾥⾯的Person对象4. 可以选择展⽰什么样的报告信息，我们最开始打开dump⽂件时，会弹出⼀个窗⼝让我们选择，如果选错了这⾥可以重新选择5. 这⾥的功能⽐较强⼤，主要⽤来分析GC引⽤关系，每个对象到GCRoot的引⽤，可以在柱状图或者⽀配树界⾯⾥选择可疑对象进⾏分析，⽐较常⽤的两个是：Path to GC ROOTS和Merge Shortest Paths to GC Roots，当然选中对象双击，也能进⼊到这样的界⾯6. Group分组功能：在 Histogram视图和 Domiantor Tree视图时可操作，即以什么样的维度展⽰7. 将分析报告以什么样的格式导出，可选的有html、csv、txt。
java dump高级用法
Java dump通常指的是Java堆转储（Java Heap Dump），它是一个包含Java应用程序运行时堆内存信息的文件。
Java堆转储可以帮助开发者诊断和解决Java应用程序的性能问题、内存泄漏和其他相关的错误。
以下是一些Java堆转储的高级用法：
1.分析内存泄漏：内存泄漏是Java应用程序中常见的问题之一，它会导致应用程序的可用内存逐
渐减少，最终导致应用程序崩溃。
通过分析Java堆转储，可以确定哪些对象占用了大量的内存，哪些对象无法被垃圾回收器回收，从而找到内存泄漏的原因。
常用的工具包括Eclipse Memory Analyzer、VisualVM等。
2.诊断性能问题：性能问题通常表现为应用程序运行缓慢或响应时间过长。
通过分析Java堆转储，
可以找到导致性能问题的对象，例如大量的临时对象、大对象等。
这可以帮助开发者优化应用程序的内存使用和垃圾回收策略，从而提高应用程序的性能。
3.识别线程阻塞：线程阻塞是导致应用程序卡顿和死锁的原因之一。
通过分析Java堆转储，可以
找到导致线程阻塞的对象，例如锁、同步块等。
这可以帮助开发者优化线程的使用和管理，避免线程阻塞的发生。
4.识别内存溢出：内存溢出是Java应用程序中非常严重的问题，它会导致应用程序崩溃。
通过分
析Java堆转储，可以找到导致内存溢出的原因，例如大量的对象无法被垃圾回收器回收、内存泄漏等。
这可以帮助开发者及时发现和修复内存溢出问题。
Java Dump 的简单使用和MAT(Memory Analyzer Tool)分析工具使用
JAVA Dump 是当tomcat出现假死状态时，保留当前内存情况下记录二进制文件。
使用MAT工具进行分析内存泄漏问题。
第一步：需要在tomcat的catalina.sh中添加如下配置JAVA_OPTS="-Xms8192m -Xmx8192m -XX:PermSize=2048M -XX:MaxNewSize=2048m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=你的文件路径只要tomcat出现内存泄漏（假死）状态就会保留下内存二进制文件。
（当然添加后要重启tomcat）第二步: 需要下载xxxx.hprof文件，这个可能会很大。
第三步：安装MAT下载https:///download/cdszdd8/10831451第四步：导如xxx.hprof文件这个过程比较漫长对了，在使用分析工具之前，一定要找一个比xxxx.hprof文件内存大机器进行分析（我这边分析了一个8G 的文件在16G内存的机器上运行分析的）第五步：导入点击工具file->Open Heap Dump 选择我们到处的.hprof文件（需要等....）等待完毕后如下图点击Leak Suspects这个是分析出的问题点击Details如下图工具定位到线程上点击线程查看线程情况找出是哪行代码出现的问题然后在返回上层点击查看数据返回情况最后定位到是一个SQL语句由于条件没有控制住导致查询数据800多万数据，都加载到内存占据内存3G多。
到此就可以找到问题了。
希望对大家有帮助。
写的不好大家多担待，谢谢观看。
JVM调优dump文件怎么生成和分析
JVM调优dump⽂件怎么⽣成和分析1、获取JVM的dump⽂件的两种⽅式 1. JVM启动时增加两个参数:#出现 OOME 时⽣成堆 dump:-XX:+HeapDumpOnOutOfMemoryError#⽣成堆⽂件地址：-XX:HeapDumpPath=/home/liuke/jvmlogs/ 2. 发现程序异常前通过执⾏指令，直接⽣成当前JVM的dmp⽂件，6214是指JVM的进程号jmap -dump:format=b,file=/home/admin/logs/heap.hprof 6214 获得heap.hprof以后，就可以分析你的java线程⾥⾯对象占⽤堆内存的情况了。
推荐使⽤Eclipse插件Memory Analyzer Tool来打开heap.hprof⽂件。
由于第⼀种⽅式是⼀种事后⽅式，需要等待当前JVM出现问题后才能⽣成dmp⽂件，实时性不⾼，第⼆种⽅式在执⾏时，JVM是暂停服务的，所以对线上的运⾏会产⽣影响。
所以建议第⼀种⽅式。
2. 查看整个JVM内存状态 jmap -heap [pid]3. 查看JVM堆中对象详细占⽤情况 jmap -histo [pid]4. 导出整个JVM 中内存信息，可以利⽤其它⼯具打开dump⽂件分析，例如jdk⾃带的visualvm⼯具 jmap -dump:file=⽂件名.dump [pid] jmap -dump:format=b,file=⽂件名 [pid] format=b指定为⼆进制格式⽂件利⽤MAT进⾏分析⽂件，下⾯是MAT安装教程在Eclipse help -> Eclipse Marketplace下搜索Memory:安装后打开导出的⽂件：1、打开MAT⾯板2、打开导出⽂件暂时不写了参照android的分析 https:///p/c8e0f8748ac0。
javadump文件怎么生成和分析-JMAP用法详解
javadump⽂件怎么⽣成和分析-JMAP⽤法详解jmap是java⾃带的⼯具
1. 查看整个JVM内存状态
jmap -heap [pid]
2. 查看JVM堆中对象详细占⽤情况
jmap -histo [pid]
3. 导出整个JVM 中内存信息，可以利⽤其它⼯具打开dump⽂件分析，例如jdk⾃带的visualvm⼯具
jmap -dump:file=⽂件名.dump [pid]
补充知识：Jmap导出java运⾏中的堆内存dump及Jprofiler分析⽅法
1.jmap导出dump
1.1运⾏程序的java\bin⽬录，执⾏jmap -dump:format=b,file=⽂件名 [pid]
1.2⽣成dump⽂件
2.Jprofiler分析⽅法
2.1 将jmap导出的⽂件web.dump⽂件更改后缀为web.jsp，*.jps为Jprofiler可识别后缀。
使⽤jprofiler打开web.jps⽂件
这⾥可以看到内存使⽤情况，查看具体占⽤内存的是什么，然后选中该项右键
然后选择references，在⾥⾯选择cumulated incoming references查看具体
可以看到具体内存占⽤的什么
以上这篇java dump⽂件怎么⽣成和分析-JMAP⽤法详解就是⼩编分享给⼤家的全部内容了，希望能给⼤家⼀个参考，也希望⼤家多多⽀持。
Java线程Dump分析工具jstack解析及使用场景
Java线程Dump分析⼯具jstack解析及使⽤场景jstack⽤于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64"，Windows的jstack使⽤⽅式只⽀持以下的这种⽅式：jstack [-l][F] pid如果java程序崩溃⽣成core⽂件，jstack⼯具可以⽤来获得core⽂件的java stack和native stack的信息，从⽽可以轻松地知道java程序是如何崩溃和在程序何处发⽣问题。
另外，jstack⼯具还可以附属到正在运⾏的java程序中，看到当时运⾏的java程序的java stack和native stack的信息, 如果现在运⾏的java程序呈现hung的状态，jstack是⾮常有⽤的。
进程处于hung死状态可以⽤-F强制打出stack。
dump ⽂件⾥，值得关注的线程状态有：死锁，Deadlock(重点关注)执⾏中，Runnable等待资源，Waiting on condition(重点关注)等待获取监视器，Waiting on monitor entry(重点关注)暂停，Suspended对象等待中，Object.wait() 或 TIMED_WAITING阻塞，Blocked(重点关注)停⽌，Parked在摘了另⼀篇博客的三种场景：实例⼀：Waiting to lock 和 Blocked"RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd4f8684000]ng.Thread.State: BLOCKED (on object monitor)at org.apache.log4j.Category.callAppenders(Category.java:201)- waiting to lock <0x00000000acf4d0c0> (a org.apache.log4j.Logger)at org.apache.log4j.Category.forcedLog(Category.java:388)at org.apache.log4j.Category.log(Category.java:853)at mons.logging.impl.Log4JLogger.warn(Log4JLogger.java:234)at ng.cache.remote.SpyMemcachedClient.get(SpyMemcachedClient.java:110)说明：1)线程状态是 Blocked，阻塞状态。
thread dump分析
1.1Thread dump定位瓶颈1.1.1Thread dump概述JAVA 的线程 DUMP，就象当前 JAVA进程的一个快照，打印出所有线程的状态和调用堆栈，以及Monitor的状态。
在实际运行中，往往一次 dump的信息，还不足以确认问题。
建议产生三次dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性。
1.1.2分析过程举例以实际环境举例1.1.2.1产生dump日志步骤如下1.对主机的中心进行加压, 使中心每秒钟处理约60笔交易.2.对中心执行thread dump (kill -3 PID)3.取出thread dump日志进行分析4.如下是截取的其中一个thread 的信息,标黄部分是需要关注的部分."IS " prio=7 tid=01b8fde8 nid=288 lwp_id=5016325 waiting for monitor entry [32082000..32080738]at app.b2b.server.jdbc.JDBCConnectionPool.getConnection(JDBCConnectionPool.java:330) - waiting to lock <47c9e5d0> (a app.b2b.server.jdbc.JDBCConnectionPool)-------------------------------------中间略取一部分-----------------at com.wm.app.b2b.server.ServiceThread.run(ServiceThread.java:80)- locked <53c2af70> (a app.b2b.server.ServiceThread)at com.wm.util.pool.PooledThread.run(PooledThread.java:118)- locked <43de02c8> (a app.b2b.server.TMPooledThread)at ng.Thread.run(Thread.java:595)1.1.2.2线程状态分析在多线程的 JAVA程序中，实现线程之间的同步，就要说说 Monitor。
dump分析帮助
用 IBM HeapAnalyzer 和 MOD4J 分析 Java 内存泄漏（2009 年 7 月 5 日）使用的较多的是 Memory Dump Diagnostic for Java (MDD4J)和 IBM HeapAnalyzer，这两个工具都能支持几乎所有 JDK 版本所生成的堆转储文件。
先说一下 IBM HeapAnalyzer， 下载之后首先阅读一下 readme， 详细写了 HeapAnalyzer 的使用方法。
可以在命令行中输入<Java path>java –Xmx[heapsize] –jar ha26.jar <heapdump file>来启动工具并加载 heapdump 文件。
对于比较大的 heapdump， 将-Xmx 设置一个较大的值 （大于 heapdump 的大小） 来避免加载过程中的 OOM。
， 对于 64 位机器上产生的超大 heapdump， 个人机器上分析就不大可能了。
打开 heapdump 文件后，我一般点击“Analysis”里的“Tree View”，以树的形式从根节点展示内存对象分配的信息第一行 ng.ref.Refenrence 这个 class 及它的 76 个 children 占用了 67%的已用堆大小（31M/46M），它本身仅占用了 76bits。
双击 ng.ref.Refenrence，我们可以看到它 所引用的两个子节点。
其中一个子节点 ng.ref.Finalizer 后的 67%指引我们内存泄漏的问题应该在它的引用上。
接下去你可以逐级展开，或者右键点击“Locate a leak suspect”，让 HeapAnalyzer 帮你找到泄漏可能发生的地方。
泄漏一般发生在那些拥有“超乎寻常多”的引用（子节点）的 class 上，正是 这些创建后没有释放、累积了成千上百的对象，造成了 OutOfMemory。
java dump 命令 简书
java dump 命令简书
dump 命令用于将 java 虚拟机状态内容保存到一个磁盘文件中，以便在内存不足的情况下保存相应的应用程序状态、信息和数据。
dump 命令仅在 HotSpot 虚拟机上提供，HotSpot 虚拟机支持常见的 UNIX 和windows 等操作系统。
dump 命令可以直接在命令行中使用，也可以使用 Java 程序执行。
在命令行上，使用以下命令来生成 dump 文件：
jmap -dump:format=b,file=<filename> <java process id>。
其中，<filename> 是要保存 dump 文件的路径，<java process id>是 java 进程的 ID。
使用 Java 程序使用 dump 命令，可以使用下面的代码进行：
Runtime rt = Runtime.getRuntime();。
Process p = rt.exec("jmap -dump:format=b,file=<filename>
<java process id>");。
其中，<filename> 是要保存 dump 文件的路径，<java process id>是 java 进程的 ID。
JavaDump分析
JavaDump分析JavaDump分析一、Java Dump概述Dump，即“转储”。
Java Dump可以保留Java虚拟机的瞬时快照。
相比于传统的控制台输出，提供了更多的信息用于分析运行系统状态及错误。
可弥补传统在Java平台上分析Bug手段的一些不足。
Java Dump分为两种：●线程Dump：纯文本格式。
包含所有线程的运行状态、调用栈、锁信息等。
●堆Dump：二进制格式，需要工具查看。
包含了线程Dump的所有信息，此外还包括系统信息、Java虚拟机参数以及堆对象的状态。
Java Dump的分析，特别适合于生产环境下，并且针对非功能性的问题，主要为：多线程并发、内存泄漏。
二、制作Dump1.Java虚拟机发行版不同Java虚拟机的Dump规范不完全相同，所以在制作Dump 时，需要注意虚拟机发行版。
●HotSpot VM：原Sun提供的官方Java虚拟机，支持Linux、Windows、Solaris平台。
●OpenJDK：Sun JDK的开源版本，1.6后跟HotSpot差别不太大了。
●JRockit：WebLogic使用的Java虚拟机，BEA开发。
●IBM J9 VM：IBM开发的Java虚拟机，AIX平台上的唯一实现。
2.原理3.注意事项1)Java虚拟机发行版使用相同的Java虚拟机发行版。
即意味着使用SunJDK的工具，连接SunJRE的应用系统来制作Dump。
2)版本要求●目标虚拟机必须为1.6或以及的jdk。
使用OOM参数制作堆Dump可使用1.5的jdk。
（各虚拟机差异较大）●制作工具需要使用相同发行版的jdk，并且建议1.6以上。
3)堆Dump格式相对纯文本的线程dump而言，堆Dump目前存在多种不同的格式。
●HPROF，Sun 的Java虚拟机的堆Dump格式。
●PHD，IBM Portable Heap Dump。
IBM J9 VM生成的Dump 格式。
4.使用虚拟机参数1)内存溢出时自动堆Dump为虚拟机增加启动参数：则当虚拟机发生OutOfMemoryError时，自动生成堆Dump。
java yml的dump的用法
java yml的dump的用法在Java中，使用yml文件进行配置管理通常会使用一些第三方库来处理。
其中，常见的库是snakeyaml，它提供了对YAML文件的解析和操作功能。
要使用snakeyaml库进行YAML文件的序列化（dump），可以按照以下步骤进行操作：首先，确保你已经将snakeyaml库添加到你的Java项目中。
可以通过在项目的pom.xml文件中添加以下依赖来引入库：xml<dependency><groupId>org.yaml</groupId><artifactId>snakeyaml</artifactId><version>版本号</version></dependency>创建一个Java类，用于定义要序列化为YAML的数据结构。
例如，你可以创建一个Java类来表示配置信息：javaimport org.yaml.snakeyaml.Yaml;import java.util.HashMap;import java.util.Map;public class Config {private Map<String, Object> properties = new HashMap<>();public void setProperty(String key, Object value) {properties.put(key, value);}public Object getProperty(String key) {return properties.get(key);}}在Java代码中使用snakeyaml库将数据序列化为YAML字符串：javaimport org.yaml.snakeyaml.Yaml;public class YamlDumpExample {public static void main(String[] args) {// 创建Config对象并设置属性Config config = new Config();config.setProperty("name", "John");config.setProperty("age", 30);config.setProperty("isStudent", true);// 创建Yaml对象并序列化数据为YAML字符串Yaml yaml = new Yaml();String yamlString = yaml.dump(config);// 打印YAML字符串到控制台或写入文件System.out.println(yamlString);}}上述代码中，我们创建了一个Config对象并设置了属性值。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
j a v a d u m p分析Java 的线程线程是指能独立于程序的其它部分运行的执行单元。
JAVA语言能够很好的实现多线程的程序。
我们在调试程序，或者在开发后期需要做性能调优的时候，往往也需要了解当前程序正在运行的线程的状态，正在执行的操作，从而分析系统可能存在的问题。
在阅读本文之间，应对 Java线程的编程原理，同步机制有一定了解 .产生 JAVA线程 dumpJAVA 的线程 DUMP，就象当前 JAVA进程的一个快照，打印出所有线程的状态和调用堆栈，以及 Monitor的状态。
在不同的操作系统下，产生线程 DUMP 的方式是不同的。
在启动程序的控制台里敲： Ctrl - Break，线程的 dump会产生在标准输出中（缺省标准输出就是控制台，如果对输出进行了重定向，则要查看输出文件）。
在 unix， linux和 MacOS 环境中，在控制台中敲： Ctrl-\，或者，用“kill -3 <pid>” ，或者“kill –QUIT <pid>”。
Pid是用所关注的 JAVA 进程号，您可以用“ps -ef | grep java” 找到，或者使用 JDK 5.0中的“jps -v” 命令获得。
在各个操作系统平台，都可以用 JDK 5.0工具包中的 jstack <pid>这里要注意的是：1. 不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的，不同的 JVM版本， dump信息也有差别。
本文中，只以 SUN的 hotspot JVM 5.0_06 为例。
2. 在实际运行中，往往一次 dump的信息，还不足以确认问题。
建议产生三次 dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性。
线程分析：1. JVM 线程在线程中，有一些 JVM内部的后台线程，来执行譬如垃圾回收，或者低内存的检测等等任务，这些线程往往在 JVM初始化的时候就存在，如下所示："Low Memory Detector" daemon prio=10 tid=0x081465f8 nid=0x7 runnable [0x00000000..0x00000000]"CompilerThread0" daemon prio=10 tid=0x08143c58 nid=0x6 waiting on condition [0x00000000..0xfb5fd798]"Signal Dispatcher" daemon prio=10 tid=0x08142f08 nid=0x5 waiting on condition [0x00000000..0x00000000]"Finalizer" daemon prio=10 tid=0x08137ca0 nid=0x4 in Object.wait()[0xfbeed000..0xfbeeddb8]at ng.Object.wait(Native Method)- waiting on <0xef600848> (a ng.ref.ReferenceQueue$Lock)at ng.ref.ReferenceQueue.remove(ReferenceQueue.java:116)- locked <0xef600848> (a ng.ref.ReferenceQueue$Lock)at ng.ref.ReferenceQueue.remove(ReferenceQueue.java:132)at ng.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)"Reference Handler" daemon prio=10 tid=0x081370f0 nid=0x3 in Object.wait() [0xfbf4a000..0xfbf4aa38]at ng.Object.wait(Native Method)- waiting on <0xef600758> (a ng.ref.Reference$Lock)at ng.Object.wait(Object.java:474)at ng.ref.Reference$ReferenceHandler.run(Reference.java:116)- locked <0xef600758> (a ng.ref.Reference$Lock)"VM Thread" prio=10 tid=0x08134878 nid=0x2 runnable"VM Periodic Task Thread" prio=10 tid=0x08147768 nid=0x8 waiting on condition我们更多的是要观察用户级别的线程，如下所示："Thread-1" prio=10 tid=0x08223860 nid=0xa waiting on condition[0xef47a000..0xef47ac38]at ng.Thread.sleep(Native Method)at testthread.MySleepingThread.method2(MySleepingThread.java:53)- locked <0xef63d600> (a testthread.MySleepingThread)at testthread.MySleepingThread.run(MySleepingThread.java:35)at ng.Thread.run(Thread.java:595)我们能看到：线程的状态： waiting on condition线程的调用栈线程的当前锁住的资源：<0xef63d600>这些信息对我们随后的分析都有用处。
2. 线程的状态分析正如我们刚看到的那样，线程的状态是一个重要的指标，它会显示在线程Stacktrace的头一行结尾的地方。
那么线程常见的有哪些状态呢？线程在什么样的情况下会进入这种状态呢？我们能从中发现什么线索？< /span>1.1 Runnable该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。
1.2 Wait on condition该状态出现在线程等待某个条件的发生。
具体是什么原因，可以结合 stacktrace 来分析。
最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。
在 Java引入 NewIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。
在 NewIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。
如果发现有大量的线程都在处在 Wait on condition，从线程 stack看，正等待网络读写，这可能是一个网络瓶颈的征兆。
因为网络阻塞导致线程无法执行。
一种情况是网络非常忙，几乎消耗了所有的带宽，仍然有大量数据等待网络读写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。
所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。
另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。
1.3 Waiting for monitor entry 和 in Object.wait()在多线程的 JAVA程序中，实现线程之间的同步，就要说说 Monitor。
Monitor 是 Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者Class的锁。
每一个对象都有，也仅有一个 monitor。
下面这个图，描述了线程和 Monitor之间关系，以及线程的状态转换图：从图中可以看出，每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是“Active Thread”，而其它线程都是“Waiting Thread”，分别在两个队列“ En try Set”和“Wait Set”里面等候。
在“Entry Set”中等待的线程状态是“Waiting for monitor entry”，而在“Wait Set”中等待的线程状态是“in Object.wait()”。
先看“Entry Set”里面的线程。
我们称被 synchronized保护起来的代码段为临界区。
当一个线程申请进入临界区时，它就进入了“Entry Set”队列。
对应的 code 就像：synchronized(obj) {.........}这时有两种可能性：·该 monitor不被其它线程拥有， Entry Set里面也没有其它等待线程。
本线程即成为相应类或者对象的 Monitor的 Owner，执行临界区的代码·该 monitor被其它线程拥有，本线程在 Entry Set队列中等待。
在第一种情况下，线程将处于“Runnable”的状态，而第二种情况下，线程DUMP会显示处于“waiting for monitor entry”。
如下所示："Thread-0" prio=10 tid=0x08222eb0 nid=0x9 waiting for monitor entry[0xf927b000..0xf927bdb8]at testthread.WaitThread.run(WaitThread.java:39)- waiting to lock <0xef63bf08> (a ng.Object)- locked <0xef63beb8> (a java.util.ArrayList)at ng.Thread.run(Thread.java:595)临界区的设置，是为了保证其内部的代码执行的原子性和完整性。