If a thread appears to be always in the RUNNABLE state, then the -m option can be used to print the native frames and provide a further hint about what the thread is doing. It might be necessary to execute jstack a number of times to get a better idea of which threads are looping. This is the most likely state for threads that are busy and possibly looping. When reviewing the output of the jstack utility, focus initially on the threads that are in the RUNNABLE state. The jstack utility should also be used if the thread dump does not provide any evidence that a Java thread is looping. See The jstack Utility for more about the output of this utility. If the application console is not available (for example, the process is running in the background, or the VM output is directed to an unknown location), then the jstack utility can be used to get the stack thread. In some cases, it might be necessary to get a sequence of thread dumps in order to determine which threads appear to be continuously busy. See Thread Dump, for more information about the format of the thread dump, as well as a table of the possible thread states in the thread dump. If a thread dump can be obtained, then a good place to start is the thread stacks of the threads that are in the RUNNABLE state. If the Java process is started with the -XX:+PrintClassHistogram command-line option, then the Control+Break handler will produce a heap histogram. The output might be directed to a file, depending on how the process was started. In this case, the thread dump is printed to the standard output of the target process. On Oracle Solaris and Linux operating systems the thread dump can also be obtained by sending a SIGQUIT to the process (command kill -QUIT pid). If the application console (standard input/output) is available, then press the Control+\ key combination (on Oracle Solaris or Linux) or the Control+Break key combination (on Windows) to cause the HotSpot VM to print a thread dump, including thread state. This chapter contains the following sections: On the Oracle Solaris operating system, for example, the command prstat -L -p pid can be used to report the statistics for all lightweight processes (LWPs) in the target process and therefore will identify the threads that are consuming a lot of CPU cycles. If the process appears to be busy and is consuming all available CPU cycles, then it is likely that the issue is a looping thread rather than a deadlock. You can do this using a native operating system (OS) utility. The initial step when you diagnose a hang is to find out if the VM process is idle or consuming all available CPU cycles.
For example, a bug in a VM process that causes one or more threads to go into an infinite loop can consume all available CPU cycles. Sometimes an apparent hang turns out to be, in fact, a loop. A hang can be due to a bug in the Java HotSpot VM.
A hang can occur for many reasons, but often stems from a deadlock in an application code, API code, or library code. Problems can occur that involve hanging or looping processes.
This chapter provides information and guidance about some specific procedures for troubleshooting hanging or looping processes.
0 kommentar(er)
