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应用程序报告所有引发异常或错误的线程。 以下是本节的屏幕截图：

您可能会注意到，本节报告了所有在堆栈跟踪中具有“异常”或“错误”的线程。 如果本节中报告了任何线程，则应考虑调查那些线程堆栈跟踪以确定问题的根源。

翻译自: https://www.javacodegeeks.com/2020/06/look-for-exceptions-errors-in-thread-dumps.html

jmc线程转储