jmc线程转储_查找线程转储中的异常和错误

jmc线程转储

线程转储是解决生产问题/调试生产问题的重要工件。在像过去我们已经讨论了几种有效的线程转储故障模式：堵车，跑步机， RSI ，一个 LL条条大路通罗马 .........。在本文中，我们想介绍另一种线程转储故障排除模式。

 How to capture thread dumps?  There are 8 different options to capture thread dumps. You can use the option that is convenient to you. dumps. You can use the option that is convenient to you.

线程转储通常在线程堆栈跟踪中包含异常或错误。应该检查在其堆栈跟踪中包含异常或错误的线程。因为它们指出了问题的根源。

最近，一个应用程序引发了java.lang.OutOfMemoryError。从此应用程序捕获了线程转储。当我们分析线程转储时，我们会注意到一个特定的线程正在抛出java.lang.OutOfMemoryError：

 Thread 0x3ff781e764e0 at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) at java.lang.ClassLoader.defineClass1(Ljava/lang/String;[BIILjava/security/ProtectionDomain;Ljava/lang/String;)Ljava/lang/Class; (Native Method) at java.lang.ClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/ProtectionDomain;)Ljava/lang/Class; (ClassLoader.java:757) at java.lang.ClassLoader.defineClass(Ljava/lang/String;[BII)Ljava/lang/Class; (ClassLoader.java:636) at sun.reflect.GeneratedMethodAccessor37.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; (Method.java:498) at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Ljava/lang/String;[B)Ljava/lang/Class; (Injector.java:125) at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Ljava/lang/ClassLoader;Ljava/lang/String;[B)Ljava/lang/Class; (Injector.java:48) at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)Ljava/lang/Class; (AccessorInjector.java:51) at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(Ljava/lang/reflect/Field;)Lcom/sun/xml/bind/v2/runtime/reflect/Accessor; (OptimizedAccessorFactory.java:128) at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Lcom/sun/xml/bind/v2/runtime/JAXBContextImpl;)Lcom/sun/xml/bind/v2/runtime/reflect/Accessor; (Accessor.java:213) at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(Lcom/sun/xml/bind/v2/runtime/JAXBContextImpl;Lcom/sun/xml/bind/v2/runtime/Transducer;Lcom/sun/xml/bind/v2/runtime/reflect/Accessor;)V (TransducedAccessor.java:195) : : at com.sun.xml.ws.client.WSServiceDelegate.getPort(Ljavax/xml/ namespace /QName;Ljava/lang/Class;[Ljavax/xml/ws/WebServiceFeature;)Ljava/lang/Object; (WSServiceDelegate.java:274) /QName;Ljava/lang/Class;[Ljavax/xml/ws/WebServiceFeature;)Ljava/lang/Object; (WSServiceDelegate.java:274) at com.sun.xml.ws.client.WSServiceDelegate.getPort(Ljavax/xml/ namespace /QName;Ljava/lang/Class;)Ljava/lang/Object; (WSServiceDelegate.java:267) /QName;Ljava/lang/Class;)Ljava/lang/Object; (WSServiceDelegate.java:267)

从该堆栈跟踪中，我们能够确定该线程在尝试将xml转换为java对象时遇到了OutOfMemoryError。

显然没有为该应用程序分配足够的内存来处理大型XML有效负载。因此，当将大型XML发送到此应用程序时，它开始抛出OutOfMemoryError。当分配了足够的内存（即，增加-Xmx值）时，问题得到解决。因此，在线程转储中查找“异常”或“错误”是确定问题根源的好模式。

但是在线程转储中查找异常或错误并不是一件容易的事。因为线程转储往往包含数百或数千个线程。每个线程将具有多行堆栈跟踪。遍历堆栈跟踪的每一行以发现异常或错误是一个繁琐的过程。线程转储分析工具在这里很方便。您可能考虑使用免费的线程转储分析工具，例如： fastThread ， IBM TDMA ， Samurai …来分析应用程序线程转储。

将线程转储上载到fastThread应用程序时，它将生成根本原因分析报告。此报告中的一节之一是“异常”。在本节中，fastThread应用程序报告所有引发异常或错误的线程。以下是本节的屏幕截图：