- 浏览: 482226 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
alvin198761:
renzhengzhi 写道我参与过12306余票查询系统的开 ...
别给12306 辩解了 -
renzhengzhi:
我参与过12306余票查询系统的开发,用户请求被前面3层缓存拦 ...
别给12306 辩解了 -
renzhengzhi:
写的很好。
JAVA线程dump的分析 -
liyonghui160com:
说好的附件呢
分布式服务框架 Zookeeper -- 管理分布式环境中的数据 -
ghpaas:
orbeon作为xforms标准的实现,不论其设计器还是运行时 ...
XForms 1.1 中文翻译—第1章 关于XForms标准
对于大型 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 故障诊断的方法和技巧,希望能够为大家提供一些帮助。 Java dump 通常是文本格式(.txt),因此可以通过一般的文本编辑器进行阅读,阅读时需要注意段与行的格式: 为了便于大家的分析,Java dump 的每一段的开头,都会用“-----”与上一段明显的区分开来。而每一段的标题也会用“=====”作为标识,这样我们就能够很容易的找到每一段的开头和标题部分(如清单 1)。 Java dump 文件中,每一行都包含一个标签,这个标签最多由 15 个字符组成(如清单2中所示)。其中第一位数字代表信息的详细级别(0,1,2,3,4),级别越高代表信息越详细;接下来的两个字符是段标题的缩写,比如,“CI” 代表 “Command-line interpreter”,“CL” 代表 “Class loader”,“LK” 代表 “Locking”,“ST” 代表 “Storage”,“TI” 代表 “Title”,“XE” 代表 “Execution engine”等等;其余部分为信息的概述。 不同版本的 JVM 所产生的 Java dump 的格式可能会稍有不同,但基本上都会包含以下几个方面的内容: 由于 Java dump 文件包含的内容比较广泛,因此 JVM 的很多问题都可以通过 java dump进行诊断。这些问题主要包括线程阻塞,CPU 使用率过高,JVM Crash,堆内存不足,和类装载等问题。 线程阻塞是我们在 java 多线程编程中经常遇到的问题。由于对后端有限资源的争用以及过度同步等问题,经常会发现 Java dump 中某个资源(锁对象)下有太多的线程处于等待状态,这时候我们通常需要从以下三个方面去诊断这个问题: 比线程阻塞更严重的是死锁问题,当两个以上的线程互相等待对方的锁,从而形成一个环的时候,就会发生死锁。关于如何使用 Java dump 诊断死锁的问题,请参考 在 WebSphere Application Server V6.1 应用程序中跟踪死锁 一文,该文对此问题做了较为详细的介绍。 JVM Crash 是我们所碰到的最棘手的问题之一,它对整个系统的影响是致命的,并且总是让人防不胜防。导致 JVM 崩溃的原因有很多,通常都是一些底层的错误。比如 JVM 本身的 bug,错误的 JNI 调用,第三方原生模块(比如数据库驱动程序)中的 bug 等。JVM崩溃的原因复杂,并且大多都难以重现,所以诊断起来有一定的难度。 一般来说,JVM 崩溃的时候,系统一般会自动产生一个 Java dump 文件(JVM 默认的设置参数就会触发)。这个 Java dump 会帮我们记录下 JVM 崩溃的原因,相关的信息会记录在 TITLE 信息块,GPINFO 信息块和 THREADS 信息块中。 下面我们通过一个具体的例子来介绍 JVM Crash 问题的诊断方法。TestJni 是一个简单的 Java 应用,它通过 JNI 调用本地代码 CallJin.dll 中的 doSomeThing() 函数。 CallJin.dll 是 C++ 编写得本地库,其源代码如清单 3 所示: 在这段 C++ 代码中,整形指针 I 还没有分配空间就被赋了值,这是一个非常严重的错误。当然 java 应用程序员并不知道这一点,并且在 java 应用程序中调用了 doSomeThing() 这个 JNI 函数。结果导致 JVM 发生了崩溃。 在这段 C++ 代码中,整形指针 I 还没有分配空间就被赋了值,这是一个非常严重的错误。当然 java 应用程序员并不知道这一点,并且在 java 应用程序中调用了 doSomeThing() 这个 JNI 函数。结果导致 JVM 发生了崩溃。 下面是 JVM 崩溃时,系统为我们生成的 Java dump 文件的片断。 从 TITLE 信息块中我们可以看到,这个 java 是由一个 "gpf" 事件触发的,GPF 是 General Protection Fault 的缩写,表明应用程序发生了一般性保护错误,这种错误常常导致 JVM 突然崩溃。 除了 "gpf" 之外,Java dump 还可能由如下事件触发(清单 6)。 从 TITLE 信息块,我们只能初步了解问题产生的原因,如果要进一步了解问题的详细信息,还要查看 GPINFO 信息块(清单 7): GPINFO 信息块中我们可以找到问题的异常代码, 例如,Module: C:\JDK\IBM\java1.5.0\jre\bin\j9jit23.dll 说明 JIT 模块发生问题,用户可以使用 JITC_COMPILEOPT 变量的 SKIP 选项禁用对当前方法进行 JIT 编译,然后再对系统的运行情况进行进一步的跟踪。 除此之外,查看 THREADS 信息块中当前线程的执行堆栈也有助于我们对问题的诊断。从清单 9 我们可以看到 main 线程在执行 CallJni.doSomeThing 方法数的过程中发生了问题,据此我们可以返回源代码中查找相应的方法,进而确定问题的根源。 CPU 使用率过高可能是由于某些线程陷入了死循环或者执行了不适当的操作引起的,其诊断方法就是将这些线程找出来,修正问题或者进行代码优化。由于 Java Dump 中并没有包含各线程的资源使用情况,因此我们需要结合其他的操作系统命令/工具(prstat、top、pslist 等等),将 CPU 使用率较高的线程映射到 Java Dump 中,并分析这些线程的状态以及可能发生的问题。 从下面这段 PSList 的输出结果中我们可以看到 jvm 内部每个线程消耗的总的“用户时间”和“内核时间”,比较几次 PSList 的输出结果,我们就能从中找出那些 CPU 使用时间显著增加的线程,再将这些线程的 TID 映射到Java Dump中,进而查看问题线程的详细信息。 与线程死锁问题不同,在分析 CPU 利用率过高的问题时,我们不需要关心那些处于等待状态的线程,因为线程处于等待状态不需要消耗 CPU 资源。我们关注的重点应该是 THREADS 信息块中那些正在运行(state:R 状态)的线程。很多时候为了分析线程状态的一些变化,我们需要对比多个 Java Dump 文件,看哪些线程状态发生了变化,哪些一直在执行相同的函数,从而找出那些可疑的问题线程。 除了 Thread 相关的信息外,Java Dump 还包含 Memory 和 GC 等方面的信息,虽然这些信息不像 Heap Dump 和 VerboseGC 那么详细,但对于一些比较简单的问题定位还是很有帮助的。例如,下面的 Java dump 清单中, 常见的类加载问题包括: ClassNotFoundException,Jar 包冲突以及由类装入引发的其他问题(例如 jdk 1.4 中的内存碎片问题) Java Dump 文件的 Classes 信息块的格式如清单中示,这些信息可以帮我们确定以下问题: 关于 Java dump,下面是一些有可能让你产生困惑的问题: 为什么发生 JVM Crash 时,JVM 没有自动生成 Java dump 文件? 答:这种情况大多与系统的环境变量或者 JVM 启动参数的设置有关,比如设置了 JVM 在生成 Java dump 的同时也生成了 Heap dump,它们之间有没有什么联系? 答:有,但是关系不大。因为 java dump 主要反映的是线程的运行状态,而 Heap dump 则主要反映对象之间的引用关系,所以两者之间没有太大的联系。有时候我们可以通过锁对象或者 Class 对象的起始地址找到它在 Heap dump 中的位置,但大多数时候这对故障诊断并没有多大意义。 为什么有些 java dump 的锁没有 owner? 答:并不是所有的锁都被其它线程持有,有些锁是用作主动等待的,比如 sleep() ,wait(),join() 等,这些锁并没有被其它线程占用,被它阻塞的线程只是在等待通知,即 “Waiting to be notified”。从线程状态上看,这些锁一般都处于 “CW” 状态。 Java Dump 中的很多线程处于 state:CW 和 state:B 状态,它们之间有何区别? 答:两者都处于等待状态。不同是: CW - Condition Wait – 条件等待. 这种等待一般是线程主动等待或者正在进行某种 IO 操作,而并非等待其它线程释放资源。比如 sleep() ,wait(),join() 等方法的调用。 B – Blocked – 线程被阻塞,与条件等待不同,线程被阻塞一般不是线程主动进行的,而是由于当前线程需要的资源正在被其他线程占用,因此不得不等待资源释放以后才能继续执行,例如 synchronized 代码块。 为什么我在 PsList 里看到的线程无法映射到 Java dump 中? 答:由于很多操作系统工具和命令输出的线程的 TID 都是十进制的,映射到 Java dump 时首先要将其转换为十六进制数字,然后再到 Java dump 中查找对应的 native ID。Java dump 中每个线程都有两个ID, 一个是 java 线程的TID, 另一个是对应操作系统线程的 native ID。 阅读 Websphere Appliaction Server 产生的 Java dump 文件有没有什么特别的技巧? 答:对于 WAS 应用程序来说,线程信息往往要比一般的应用程序复杂的多。记住一些常见的 ThreadName 可以帮助我们更好的理解应用程序的运行状态,例如: 本文比较全面的介绍了 Java dump 在 JVM 故障诊断过程中的作用。正像你所看到的,Java dump 文件主要帮我们解决与线程相关的各种问题,但同时它还为我们提供了很多其它有用的信息(比如 JVM Crash),在某些情况下,这些信息对于我们至关重要,所以充分的利用 Java dump 文件可以帮我们更快的找到解决问题的方向。
清单 1. Java dump 段标题示例
NULL --------------------------------
0SECTION TITLE subcomponent dump routine
NULL ===============================
清单 2. Java dump 行标签和内容示例
1TISIGINFO Dump Event "uncaught" (00008000) Detail "java/lang/OutOfMemoryError" received
清单 3. 在 TestJni 类中调用 CallJin.dll 中的函数
package test;
public class TestJin {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
TestJin testObj = new TestJin();
testObj.work();
}
public void work() {
CallJni.doSomeThing();
}
}
package test;
public class CallJni {
static
{
System.loadLibrary("CallJni");
System.out.println("Dll Loaded");
}
public native static void doSomeThing();
}
清单 4. CallJni.dll 的 C++ 实现代码
#include <com_test_CallJni.h>
/*
* Class: com_test_CallJni
* Method: doSomeThing
*/
JNIEXPORT void JNICALL Java_test_CallJni_doSomeThing
(JNIEnv *, jclass){
int *i;
*i = 100;
}
清单5. Java dump 文件片断
NULL ----------------------------------------------
0SECTION TITLE subcomponent dump routine
NULL ===============================
1TISIGINFO Dump Event "gpf" (00002000) received
1TIDATETIME Date: 2008/11/12 at 20:45:24
1TIFILENAME Javacore filename:
C:\eclipse\workspace\Serviceability\TestApps\SampleLeak\TestJin\
javacore.20081112.204522.5656.txt
清单 6. 常见 Java dump 触发事件
user SIGQUIT signal (Ctrl-Brk on Windows, Ctrl-\ on Linux, Ctrl-V on z/OS)
abort a controlled crash, as triggered by the abort() system call
vmstart the VM has finished initialization
vmstop the VM is about to shutdown
load a new class has been loaded
unload a classloader has been unloaded
throw a Java exception has been thrown
catch a Java exception has been caught
uncaught a Java exception was not handled by the application
thrstart a new thread has started
thrstop an old thread has stopped
blocked a thread is blocked entering a monitor
fullgc garbage collection has started
清单7. GPINFO 信息块
NULL ----------------------------------------------
0SECTION GPINFO subcomponent dump routine
NULL ================================
2XHOSLEVEL OS Level : Windows XP 5.1 build 2600 Service Pack 3
2XHCPUS Processors -
3XHCPUARCH Architecture : x86
3XHNUMCPUS How Many : 2
NULL
1XHEXCPCODE J9Generic_Signal_Number: 00000004
1XHEXCPCODE ExceptionCode: C0000005
1XHEXCPCODE ExceptionAddress: 412E136E
1XHEXCPCODE ContextFlags: 0001003F
1XHEXCPCODE Handler1: 7EFB04E0
1XHEXCPCODE Handler2: 7F057A80
1XHEXCPCODE InaccessibleAddress: CCCCCCCC
NULL
1XHEXCPMODULE Module:
C:\eclipse\workspace\Serviceability\TestApps\SampleLeak\TestJin\CallJni.dll
1XHEXCPMODULE Module_base_address: 412D0000
1XHEXCPMODULE Offset_in_DLL: 0001136E
NULL
1XHFLAGS VM flags:00040000
NULL
ExceptionCode: C0000005
代表内存访问错误或者非法的内存操作。Module: C:\eclipse\workspace\Serviceability\TestApps\TestJin\CallJni.dll
指明了发生问题的原生模块。 CallJni.dll 这个动态连接库是我们自己的 JNI 代码,因此很容易发现问题的所在。在一个复杂的 java 运行环境下,很多时候异常是在第三方的代码库中产生的,我们没有办法查看源代码中的问题,这时候只能通过文件名中的一些关键字来推测问题发生的位置,这些关键字包括(清单 8):
清单 8. 需要注意的关键字
GC = garbage collection/collector (how Java frees memory)
JIT = just-in-time compiler, a feature of JVM
JDBC = Java feature for database access
ORB = object request broker, lower layer of app server
JMS = java messaging service, feature of web server or add-on
JITC_COMPILEOPT=SKIP{failingPackage/failingClass}{failingMethod}
清单 9. Threads 信息块
NULL ----------------------------------------------------
0SECTION THREADS subcomponent dump routine
NULL =================================
NULL
1XMCURTHDINFO Current Thread Details
NULL ----------------------
3XMTHREADINFO "main" (TID:0x408C7C00, sys_thread_t:0x00366278, state:R,
native ID:0x000016CC) prio=5
4XESTACKTRACE at test/CallJni.doSomeThing(Native Method)
4XESTACKTRACE at test/TestJin.work(TestJin.java:16)
4XESTACKTRACE at test/TestJin.main(TestJin.java:11)
NULL
清单 10. PSList 的输出结果
pslist -d <Java PID>
Tid Pri Cswtch State User Time Kernel Time Elapsed Time
2908 8 2025 Wait:Executive 0:00:00.359 0:00:01.312 1:48:08.046
4344 15 157 Wait:UserReq 0:00:00.218 0:00:00.015 1:48:07.921
4836 15 415456 Wait:UserReq 0:00:00.000 0:00:00.000 1:48:07.921
2496 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 1:48:07.796
4648 9 1 Wait:UserReq 0:00:00.000 0:00:00.000 1:48:07.796
3116 9 7 Wait:UserReq 0:00:00.000 0:00:00.000 1:48:07.796
5268 8 189 Wait:UserReq 0:00:00.015 0:00:00.000 1:48:07.796
5220 7 6991523 Running 1:47:42.031 0:00:01.218 1:48:05.593
3932 9 2 Wait:UserReq 0:00:00.000 0:00:00.000 1:48:05.125
Dump Event "uncaught" (00008000) Detail "java/lang/OutOfMemoryError" received
告诉我们问题是由于内存溢出引起的,并且从 MEMINFO 信息块中可以找到当前堆中的空间使用情况, 1ffa0 的剩余空间说明系统的可用堆内存已经严重不足了,需要我们扩大堆内存的大小或者修改应用程序使其占用更少的内存。
清单 11. MEMINFO 信息块
NULL ----------------------------------------------------
0SECTION TITLE subcomponent dump routine
NULL ===============================
1TISIGINFO Dump Event "uncaught" (00008000) Detail "java/lang/OutOfMemoryError" received
1TIDATETIME Date: 2008/04/20 at 19:13:50
1TIFILENAME Javacore filename:
c:\Serviceability\AppServer\profiles\AppSrv01\javacore.20080420.185326.948.txt
NULL ----------------------------------------------------
0SECTION MEMINFO subcomponent dump routine
NULL =================================
1STHEAPFREE Bytes of Heap Space Free: 1ffa0
1STHEAPALLOC Bytes of Heap Space Allocated: 40000000
清单 12. CLASSES 信息块
NULL ---------------------------------------------------------
0SECTION CLASSES subcomponent dump routine
NULL =================================
1CLTEXTCLLOS Classloader summaries
1CLTEXTCLLSS 12345678:
1=primordial,2=extension,3=shareable,4=middleware,5=system,
6=trusted,7=application,8=delegating
2CLTEXTCLLOADER p---st-- Loader *System*(0x008DA0B0)
3CLNMBRLOADEDLIB Number of loaded libraries 3
3CLNMBRLOADEDCL Number of loaded classes 347
2CLTEXTCLLOADER -x--st-- Loader sun/misc/Launcher$ExtClassLoader(0x008E5E38),
Parent *none*(0x00000000)
3CLNMBRLOADEDLIB Number of loaded libraries 0
3CLNMBRLOADEDCL Number of loaded classes 0
2CLTEXTCLLOADER -----ta- Loader sun/misc/Launcher$AppClassLoader(0x008EF3E0),
Parentsun/misc/Launcher$ExtClassLoader(0x008E5E38)
3CLNMBRLOADEDLIB Number of loaded libraries 0
3CLNMBRLOADEDCL Number of loaded classes 2
1CLTEXTCLLIB ClassLoader loaded libraries
2CLTEXTCLLIB Loader *System*(0x008DA0B0)
3CLTEXTLIB C:\JDK\IBM\java1.5.0\jre\bin\java
3CLTEXTLIB C:\JDK\IBM\java1.5.0\jre\bin\jclscar_23
3CLTEXTLIB C:\JDK\IBM\java1.5.0\jre\bin\zip
1CLTEXTCLLOD ClassLoader loaded classes
2CLTEXTCLLOAD Loader *System*(0x008DA0B0)
3CLTEXTCLASS java/io/ByteArrayOutputStream(0x40D40098)
3CLTEXTCLASS sun/nio/ByteBuffered(0x40D40330)
3CLTEXTCLASS java/lang/ref/PhantomReference(0x40DB9360)
3CLTEXTCLASS sun/misc/Cleaner(0x40DB94A8)
回页首
DISABLE_JAVADUMP=true,IBM_NOSIGHANDLER=true
等等,因此可以首先检查系统设置和 JVM 启动参数。当然也不排除因为一些不确定因素导致 JVM 无法产生 Java dump,虽然这种可能性比较小。
线程名
线程信息
Web Container: #
WAS web container *
Alarm Thread #
handles timer processing
Session.Transports.Threads:###
servlet threads for processing HTTP requests
ORB.thread.pool:###
ORB thread (ORB data)
P=437206:O=0:
StandardRT=19027:LocalPort=9001:RemoteHost=hostname.ibm.com:RemotePan ORB thread for receiving an EJB request or other ORB request
Thread-##
JVM thread (default name)
学习
发表评论
-
.NET开源核心运行时,且行且珍惜
2014-12-25 15:39 1869背景 2014年11月12日,ASP.NET之父、微软云 ... -
常用 Java Profiling 工具的分析与比较
2010-08-15 22:04 1203相对于静态代码分析,Profiling 是通过收集程序运行 ... -
监控系统内存
2010-07-01 14:15 1216public CollectorThread(int seco ... -
Debugging the JNI
2010-06-18 14:03 1002If you think you have a JNI p ... -
JNI原理2
2010-06-18 13:31 162115.2 调用C程序 JNI规范 ... -
JNI原理1
2010-06-18 13:14 1263在某些Java的忠实支持者眼中,JNI(Java Nati ... -
JNI的crash终于搞定<转>
2010-06-18 13:08 1677今天终于搞定困扰我一周的一个问题了。我们的算法通过jni封装, ... -
java的volatile是什么意思
2010-04-20 15:39 1338我们知道,在Java中设置变量值的操作,除了long和d ... -
Concurrent kickoff
2010-04-19 15:55 1390This example shows you the ... -
IBM JDK和sun jdk区别
2010-04-19 15:52 2592在IBM的虚拟机官方指导文档中明确指出,禁止将虚拟机的最大 ... -
如何在IBM JDK 1.4.2的环境中避免Java堆空间的碎片问题
2010-04-19 15:48 880用户在使用WebSphere Applic ... -
Concurrent mark
2010-04-15 19:39 1022Concurrent mark gives reduced ... -
Java 技术,IBM 风格: 垃圾收集策略,第 1 部分
2010-04-15 16:51 1004可以使用 4 种不同的策略配置 IBM Developer ... -
Java 网页浏览器组件介绍
2010-04-12 23:44 1506前言 在使用 Java 开发客户端程序时,有时会需要在界 ... -
IBM JVM垃圾回收原理——1
2010-04-06 15:42 1621原文下载:IBM Garbage Collection ... -
Java 理论与实践: 垃圾收集简史
2010-04-06 14:34 834垃圾收集的好处是无 ... -
关注性能: 调优垃圾收集
2010-04-06 14:08 841随着网志作为公共日 ... -
Java 理论与实践: JVM 1.4.1 中的垃圾收集
2010-04-06 10:42 899老对象和年轻对象 ... -
优化 Java 垃圾收集器改进系统性能
2010-04-02 16:05 923From http://www.ibm.com/de ... -
搞懂java中的synchronized关键字
2010-04-01 19:54 815实际上,我关于java的基 ...
相关推荐
《实战JAVA虚拟机 (JVM故障诊断与性能优化)》是一本深度剖析JVM的实践指南,旨在帮助读者掌握JVM的内部工作机制,提升故障排查和性能调优的能力。本书可与周志明的《深入理解JAVA虚拟机》相媲美,提供了丰富的源码...
《实战Java虚拟机——JVM故障诊断与性能优化》是一本深入探讨Java开发人员和运维人员必备技能的书籍。本书作者葛一鸣以其丰富的实战经验,详细阐述了JVM(Java Virtual Machine)的工作原理,以及如何有效地进行故障...
在《实战Java虚拟机——JVM故障诊断与性能优化》一书中,作者深入探讨了如何对JVM进行故障排查和性能调优,通过源码分析来帮助读者理解其内部工作原理。下面我们将根据书中的主题,详细阐述相关的知识点。 1. **JVM...
《实战Java虚拟机 JVM故障诊断与性能优化》是由葛一鸣编著的一本专业书籍,主要探讨了如何在实际工作中解决Java虚拟机(JVM)的相关问题,以及如何进行性能调优。书中涵盖了许多关键的知识点,让我们一一展开讨论。 ...
《实战JAVA虚拟机 JVM故障诊断与性能优化》这本书主要涵盖了Java开发者在实际工作中可能遇到的JVM相关问题,包括但不限于故障排查、性能调优、内存管理、垃圾收集机制等内容。以下将详细介绍这些知识点: 1. **Java...
《实战JAVA虚拟机 JVM故障诊断与性能优化》是一本深度探讨Java虚拟机(JVM)的专著,旨在帮助开发者解决实际工作中遇到的JVM相关问题,提升系统的性能表现。通过对JVM内部机制的深入理解,我们可以更有效地调试、...
《实战JAVA虚拟机 JVM故障诊断与性能优化》是一本深度探讨Java虚拟机(JVM)的书籍,旨在帮助开发者解决在实际工作中遇到的JVM相关问题,提升系统的性能。这本书提供了丰富的源码实例,让读者能够深入理解JVM的工作...
《实战JAVA虚拟机 JVM故障诊断与性能优化》是一本深度剖析Java虚拟机(JVM)的实战型书籍,旨在帮助读者理解JVM的工作原理,掌握JVM的故障诊断技巧,以及进行有效的性能优化。在Java开发中,JVM扮演着至关重要的角色...
在Java开发及运维工作中,Thread Dump是一项极其重要的工具,它能够帮助我们诊断并解决Java应用程序中出现的各种问题。Thread Dump,即线程快照,是指Java虚拟机(JVM)在某一时间点捕捉到的所有线程的状态快照。通过...
- `IBM_JAVADUMP_OUTOFMEMORY`:当JVM遇到OutOfMemoryError时,是否生成Heapdump。 - `IBM_JAVA_HEAPDUMP_TXT`:控制Heapdump的文本格式输出。 - `IBM_HEAPDUMPDIR`:指定Heapdump文件的存储路径。 - `IBM_...
### Java线上故障分析:线程dump与堆内存分析 #### 引言 在现代软件开发中,Java作为一门广泛使用的编程语言,在企业级应用、Web服务、大数据处理等多个领域发挥着重要作用。然而,随着系统复杂度的提升,线上环境...
在"JVMInPractice:实战JAVA虚拟机.JVM故障诊断与性能优化.葛一鸣.2015源代码"这个资源中,葛一鸣专家分享了关于JVM的实际操作、故障诊断和性能调优的实践经验。源代码的提供使学习者能够深入理解JVM的工作原理,并...
在IBM AIX操作系统环境下,Java应用服务器可能会遇到各种运行时问题,这时系统会生成dump文件以供诊断。"AIX dump分析工具"是专门用于解析和理解这些dump文件的工具,帮助管理员识别并解决Java应用服务器的问题。...
在IT领域,尤其是在Java应用程序的性能调优过程中,生成javacore和heapdump文件是非常重要的步骤。这些文件能帮助我们诊断应用程序的内存泄漏、性能瓶颈等问题。本篇将详细讲解如何利用wsadmin工具来生成这两种文件...
在 WebSphere Application Server 中,javacore 文件可以帮助我们分析和判断一些故障,如:100% CPU Usage、Crash、Hang/Performance 问题。 需要注意的是,在某些情况下,javacore 文件可能不能正常产生,可能是...
在Java开发与运维过程中,针对JVM(Java虚拟机)进行性能调优、故障排查是非常重要的环节。本文将详细介绍三种常用的JVM问题诊断工具:`jinfo`、`jmap` 和 `jstack` 的功能、用法以及应用场景。 #### 1. jinfo **...
总的来说,IBM Thread and Monitor Dump Analyzer for Java 是一个强大的故障诊断工具,它为Java开发者提供了深入洞察应用程序内部工作状态的能力,帮助他们快速定位并解决性能和稳定性问题。通过理解和熟练使用这款...