Troubleshooting tools in JDK 7 — reprint
This chapter describes in detail the troubleshooting tools that are available in JDK 7. In addition,the chapter lists operating-system-specific tools that may be used in conjunction with these troubleshooting tools. Finally,the chapter explains how you can develop new tools using the APIs provided with JDK 7.
The chapter contains the following sections:
The HPROF tool is capable of presenting cpu usage,heap allocation statistics,and monitor contention profiles. In addition,it can report complete heap dumps and states of all the monitors and threads in the Java virtual machine. In terms of diagnosing problems,HPROF is useful when analyzing performance,lock contention,memory leaks,and other issues.
2.1. 4 cpu Usage Times Profile (cpu=times)
For comprehensive documentation for Java VisualVM,see
In JDI a connector is the means by which the debugger connects to the target virtual machine. The JDK release has Traditionally shipped with connectors that launch and establish a debugging session with a target VM,as well as connectors that are used for remote debugging (using TCP/IP or shared memory transports).
This example uses the SA PID Attaching Connector to attach to a process. The target process is not started with any special options,that is,the -agentlib:jdwp option is not required. When this connector attaches to a process it does so in read-only mode: the debugger can examine threads and the running application but it cannot change anything. The process is frozen while the debugger is attached.
For more information about the jhat utility,see the .
The second variant of this query includes the platform classes. Platform classes include classes whose fully-qualified names start with prefixes such as java, sun., javax. swing., orchar[. The list of prefixes is in a system resource file called resources/platform_names.txt. You can override this list by replacing it in the JAR file,or by arranging for your replacement to occur first on the classpath when jhat is invoked.
This query shows the count of instances for every class in the system,excluding platform classes. It is sorted in descending order,by instance count. A good way to spot a problem with unintentional object retention is to run a program for a long time with a variety of input,then request a heap dump. Looking at the instance counts for all classes,you may recognize a number of classes because there are more instances than you expect. Then you can analyze them to determine why they are being retained (possibly using the Roots query). A variant of this query includes platform classes.
The Syntax of the select statement is as follows:
When viewing an object instance,you can check the objects listed in the section entitled “References to this object” to see which objects directly reference this object. More importantly you use a Roots query to determine the reference chains from the root set to the given object. These reference chains show a path from a root object to this object. With these chains you can quickly see how an object is reachable from the root set.
The jinfo command-line utility gets configuration information from a running Java process or crash dump and prints the system properties or the command-line flags that were used to start the virtual machine.
For more information on the jmap utility,refer to the .
$ jmap -histo 29620 num #instances #bytes class name -------------------------------------- 1: 1414 6013016 [I 2: 793 482888 [B 3: 2502 3349284: 280 274976 5: 324 227152 [D 6: 2 502 200896 7: 2094 187496 [C 8: 280 172248 9: 3767 139000 [Ljava.lang.Object; 10: 260 122416 11: 3304 112864 12: 160 72960 java2d.Tools$3 13: 192 61440 14: 219 55640 [F 15: 2114 50736 java.lang.String 16: 2079 49896 java.util.HashMap$Entry 17: 528 48344 [S 18: 1940 46560 java.util.Hashtable$Entry 19: 481 46176 java.lang.Class 20: 92 43424 javax.swing.plaf. Metal. MetalScrollButton ... more lines removed here to reduce output... 1118: 1 8 java.util.Hashtable$EmptyIterator 1119: 1 8 sun.java2d.pipe .solidTextRenderer Total 61297 10152040
Configuring the size of the permanent generation can be important for applications that dynamically generate and load a very large number of classes (for example,Java Server Pages/web containers). If an application loads “too many” classes,then it is possible it will abort with an OutOfMemoryError. The specific error is Exception in thread XXXX java. lang.OutOfMemoryError: PermGen space. See
For more information on the jps utility,refer to the .
For more information on the jrunscript utility,refer to the .
For more information on jsadebugd,refer to the .
For more information on the jstack utility,refer to the .
For a complete description of the jstat utility,refer to the .
$ jstat -gcnew -h3 2834 250 S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT 192.0 192.0 0.0 0.0 15 15 96.0 1984.0 942.0 218 1.999 192.0 192.0 0.0 0.0 15 15 96.0 1984.0 1024.8 218 1.999 192.0 192.0 0.0 0.0 15 15 96.0 1984.0 1068.1 218 1.999 S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT 192.0 192.0 0.0 0.0 15 15 96.0 1984.0 1109.0 218 1.999 192.0 192.0 0.0 103.2 1 15 96.0 1984.0 0.0 219 2.019 192.0 192.0 0.0 103.2 1 15 96.0 1984.0 71.6 219 2.019 S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT 192.0 192.0 0.0 103.2 1 15 96.0 1984.0 73.7 219 2.019 192.0 192.0 0.0 103.2 1 15 96.0 1984.0 78.0 219 2.019 192.0 192.0 0.0 103.2 1 15 96.0 1984.0 116.1 219 2.019
2.13 jstatd Daemon
The visualgc tool is related to the jstat tool. (See
2.15. 2 Deadlock Detection
In addition to the thread stacks,the Ctrl-Break handler executes a deadlock detection algorithm. If any deadlocks are detected,it prints additional information after the thread dump on each deadlocked thread.
Found one Java-level deadlock: ============================= "Thread2": waiting to lock monitor 0x000af330 (object 0xf819a938,a java.lang.String),which is held by "Thread1" "Thread1": waiting to lock monitor 0x000af398 (object 0xf819a970,which is held by "Thread2"Java stack information for the threads listed above:
"Thread2":
at Deadlock$DeadlockMakerThread.run(Deadlock.java:32)
- waiting to lock <0xf819a938> (a java.lang.String)
- locked <0xf819a970> (a java.lang.String)
"Thread1":
at Deadlock$DeadlockMakerThread.run(Deadlock.java:32)- waiting to lock <0xf819a970> (a java.lang.String)
- locked <0xf819a938> (a java.lang.String)
Found 1 deadlock.
If the Java VM flag -XX:+PrintConcurrentLocks is set,Ctrl-Break will also print the list of concurrent locks owned by each thread.
2.15. 3 Heap Summary
Starting with JDK 7,the Ctrl-Break handler also prints a heap summary. This output shows the different generations (areas of the heap),with the size,the amount used,and the address range. The address range is especially useful if you are also examining the process with tools such as pmap.
Heap def new generation total 1152K,used 435K [0x22960000,0x22a90000,0x22e40000 ) eden space 1088K,40% used [0x22960000,0x229ccd40,0x22a70000) from space 64K,0% used [0x22a70000,0x22a70000,0x22a80000) to space 64K,0% used [0x22a80000,0x22a80000,0x22a90000) tenured generation total 13728K,used 6971K [0x22e40000,0x23ba8000,0x269600 00) the space 13728K,50% used [0x22e40000,0x2350ecb0,0x2350ee00,0x23ba8000) compacting perm gen total 12288K,used 1417K [0x26960000,0x27560000,0x2a9600 00) the space 12288K,11% used [0x26960000,0x26ac24f8,0x26ac2600,0x27560000) ro space 8192K,62% used [0x2a960000,0x2ae5ba98,0x2ae5bc00,0x2b160000) rw space 12288K,52% used [0x2b160000,0x2b79e410,0x2b79e600,0x2bd60000)
If the Java VM flag -XX:+PrintClassHistogram is set,then the Ctrl-Break handler will produce a heap histogram.
2.16 Operating-System-Specific Tools
This section lists a number of operating-system-specific tools that are useful for troubleshooting or monitoring purposes. A brief description is provided for each tool. For further details,refer to the operating system documentation (or man pages in the case of Solaris OS and Linux).
2.16. 1 Solaris Operating System
The following tools are provided by the Solaris Operating System. See also
2.16. 2 Linux Operating System
The following tools are provided by the Linux Operating System.