Reprinted from: http://hellojava.info/?p=517
Alibi Xuan
Troubleshooting In addition to the most important solutions and logical derivation capabilities, tools are an integral part of the tool, a good tool can be more effective, even in some cases, because there is no corresponding tool and can not continue to go on, This article is about some of the tools that are commonly used when troubleshooting Java problems (PS: This article is worth collecting, it's easy to forget). Log related Tools
Check the problem will be very dependent on the log, so the relevant tools to look at the log is very important, usually master the Tail,find,fgrep,awk of the common tools of the method can be, speaking of this must say the key anomalies and information log output is how important (see too many abnormal random processing, For example, it is typical to apply their own Servletcontextlistener implementation, a lot of listener implementations will be thrown out runtimeexception, and then directly lead to Tomcat exit, And Tomcat this time will not output this abnormal information, this time to check the reason is really frustrating, although there are ways to do so.
The standardization of the log is also very important, the standardization of the log on the one hand, such as I want to check all kinds of system problems of people, not standard words can not be found anywhere; On the other hand, for distributed systems, if standardized is very easy to do the log tracing, the problem location will be a great help. CPU-related tools
When you encounter some CPU-related problems, the tools that you usually need to use are:
Top (-h)
Top can observe the CPU's indicator condition in real time, especially the indicator condition of each core, can be more effective to help solve the problem, and-H will help to see what thread caused the CPU consumption, which can help to solve some simple CPU-consuming problems.
Sar
SAR helps to view historical indicator data, in addition to CPU, other memory, disk, network and other indicators can be viewed, after all, most of the time the problem occurs in the past, so the history is very important.
Jstack
Jstack can be used to see what threads are doing in the Java process, which is usually not a response to the application, very slow and so on, the scene is not small help, jstack by default only see the Java stack, and jstack-m can see the Java stack and native stack of threads, But if the Java method is compiled, it is not visible (however, most of the frequently accessed Java methods are actually compiled).
Pstack
Pstack can be used to see the native stack of Java processes.
Perf
Some simple CPU consumption problems rely on Top-h + jstack usually can solve, complex words need to rely on perf this super weapon.
Cat/proc/interrupts
This is because for distributed applications, frequent network access caused by network interrupt processing consumption is also a key, and this time network card multi-queue and balance is very important, so if the CPU SI indicator is not low, then look at interrupts is necessary. Memory-related tools
When you encounter some memory-related problems, you usually need the tools:
Jstat
Jstat-gcutil or-GC and so on can help you see the GC in real time, but I'm more used to looking at GC log.
Jmap
Jmap-dump can help you when you need to dump memory to see what's in memory, and jmap-histo:live can help you when you need to enforce FGC (a GC that is bound to be fragmented in a CMS GC), and it helps you (obviously, Do not do it casually).
Gcore
Compared to jmap-dump, in fact, I prefer gcore, because the feeling is faster, but because some JDK version looks and gcore with not so good, so that time still need to use jmap-dump.
Mat
With memory dump, no analysis tools and eggs, mat is a very good tool, there is nothing to say.
Btrace
A few of the problems can be seen directly after Mat, and most will need to use btrace to dynamic tracking, Btrace is definitely the super artifact in Java, for a simple example, if you want to check the next running Java application, where to create an array size > 1000 ArrayList, what do you want to do, in the case of Btrace, that is the second seconds to fix things,:)
Gperf
Memory consumption in the Java heap with some of the above tools basically can be done, but the heap is sad, now it seems that only gperf is more useful, or from experience, direct Bytebuffer, deflater/inflater These are frequently asked questions.
In addition to the above tools, the same memory information record is also very important, like the log, so like the GC log must be opened, to ensure that after the problem can be checked to check the GC log to control whether GC is problematic, so like-xx:+printgcdetails-xx:+ PRINTGCDATESTAMPS-XLOGGC: Such parameters must be standard for startup parameters.
ClassLoader Related Tools
As a Java programmer, do not encounter classloader problem that basic is not possible, in the troubleshooting of such problems, it is best to do or-xx:+traceclassloading, or if you know what kind of words, My suggestion is to put all the loaded lib directory jar with JAR-TVF *.jar such a way to view the conflict class directly, or else will call Btrace artifact to track classloader.defineclass and so on. Other tools
Jinfo
Java has n more startup parameters, n more default values, and any document is not necessarily accurate, only with jinfo-flags see the only reliable, even you can see Jinfo-flag, you will find more fun.
Dmesg
Your Java process is suddenly gone? Maybe you can try DMESG first.
Systemtap
Some of these problems are not enough to be detected at the Java level, and the Systemtap artifact can come in handy when you need to trace the OS-level function calls at the bottom.
Gdb
More advanced players, with core dump, can use GDB to troubleshoot some of the more bizarre problems.
I have few problems with the IO type, so although I know some tools, I don't write them here.
Write these for the time being, although most of the tools can be used temporarily, but first know which tools are the most important, and then it is recommended that you can play with these tools, so that when it is really necessary to use a little bit of an impression.
Java Troubleshooting Toolbox [reprint]