troubleshooting tools in JDK 7--转载
|
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:
2.1 HPROF - Heap ProfilerThe Heap Profiler (HPROF) tool is a simple profiler agent shipped with the JDK release. It is a dynamically linked library that interfaces with the Java VM using the Java Virtual Machine Tools Interface (JVM TI). The tool writes profiling information either to a file or to a socket in ASCII or binary format. This information can be further processed by a profiler front-end tool. 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. In addition to the HPROF library,the JDK release includes the source for HPROF as JVM TI demonstration code. This code is located in the?$JAVA_HOME/demo/jvmti/hprof?directory. The HPROF tool is invoked as follows: $ java -agentlib:hprof ToBeProfiledClass Depending on the type of profiling requested,HPROF instructs the virtual machine to send it the relevant events. The tool then processes the event data into profiling information. For example,the following command obtains the heap allocation profile: $ java -agentlib:hprof=heap=sites ToBeProfiledClass The complete list of options is printed when the HPROF agent is provided with the?help?option,as shown below. $ java -agentlib:hprof=help
HPROF: Heap and CPU Profiling Agent (JVMTI Demonstration Code)
hprof usage: java -agentlib:hprof=[help]|[
By default,heap profiling information (sites and dump) is written out to?java.hprof.txt?(in ASCII) in the current working directory. The output is normally generated when the VM exits,although this can be disabled by setting the “dump on exit” option to “n” (doe=n). In addition,a profile is generated when Ctrl- or Ctrl-Break (depending on platform) is pressed. On Solaris OS and Linux a profile is also generated when a QUIT signal is received (kill -QUIT?pid). If Ctrl- or Ctrl-Break is pressed multiple times,multiple profiles are generated to the one file. The output in most cases will contain IDs for traces,threads,and objects. Each type of ID will typically start with a different number than the other IDs. For example,traces might start with 300000. 2.1.1 Heap Allocation Profiles (heap=sites)The following output is the heap allocation profile generated by running the Java compiler (javac) on a set of input files. Only parts of the profiler output are shown here. $ javac -J-agentlib:hprof=heap=sites Hello.java
SITES BEGIN (ordered by live bytes) Wed Oct 4 13:13:42 2006
percent live alloc'ed stack class
rank self accum bytes objs bytes objs trace name
1 44.13% 44.13% 1117360 13967 1117360 13967 301926 java.util.zip.ZipEntry
2 8.83% 52.95% 223472 13967 223472 13967 301927 com.sun.tools.javac.util.List
3 5.18% 58.13% 131088 1 131088 1 300996 byte[]
4 5.18% 63.31% 131088 1 131088 1 300995 com.sun.tools.javac.util.Name[]
A crucial piece of information in the heap profile is the amount of allocation that occurs in various parts of the program. The SITES record above shows that 44.13% of the total space was allocated for?java.util.zip.ZipEntry?objects. A good way to relate allocation sites to the source code is to record the dynamic stack traces that led to the heap allocation. The following output shows another part of the profiler output. This output illustrates the stack traces referred to by the four allocation sites in output shown above. TRACE 301926:
java.util.zip.ZipEntry.
Each frame in the stack trace contains class name,method name,source file name,and the line number. The user can set the maximum number of frames collected by the HPROF agent. The default limit is four. Stack traces reveal not only which methods performed heap allocation,but also which methods were ultimately responsible for making calls that resulted in memory allocation. 2.1.2 Heap Dump (heap=dump)A heap dump is obtained using the?heap=dump?option. The heap dump is in either ASCII or binary format,depending on the setting of the?format?option. Tools such as?jhat?(see?
The following command produces a dump from executing the?javac?compiler. $ javac -J-agentlib:hprof=heap=dump Hello.java The output is a large file. It consists of the root set as determined by the garbage collector,and an entry for each Java object in the heap that can be reached from the root set. The following is a selection of records from a sample heap dump. HEAP DUMP BEGIN (39793 objects,2628264 bytes) Wed Oct 4 13:54:03 2006 ROOT 50000114 (kind= Each record is a?ROOT,?OBJ,?CLS,or?ARR?to represent a root,an object instance,a class,or an array. The hexadecimal numbers are identifiers assigned by HPROF. These numbers are used to show the references from an object to another object. For example,in the above sample,the?java.lang.Thread instance?50000114 has a reference to its thread group (50008c6c) and other objects. In general,as the output is very large,it is necessary to use a tool to visualize or process the output of a heap dump. One such tool is?jhat. See?
2.1.3 CPU Usage Sampling Profiles (cpu=samples)The HPROF tool can collect CPU usage information by sampling threads. Below is part of the output collected from a run of the?javac?compiler. $ javac -J-agentlib:hprof=cpu=samples Hello.java CPU SAMPLES BEGIN (total = 462) Wed Oct 4 13:33:07 2006 rank self accum count trace method 1 49.57% 49.57% 229 300187 java.util.zip.ZipFile.getNextEntry 2 6.93% 56.49% 32 300190 java.util.zip.ZipEntry.initFields 3 4.76% 61.26% 22 300122 java.lang.ClassLoader.defineClass2 4 2.81% 64.07% 13 300188 java.util.zip.ZipFile.freeEntry 5 1.95% 66.02% 9 300129 java.util.Vector.addElement 6 1.73% 67.75% 8 300124 java.util.zip.ZipFile.getEntry 7 1.52% 69.26% 7 300125 java.lang.ClassLoader.findBootstrapClass 8 0.87% 70.13% 4 300172 com.sun.tools.javac.main.JavaCompiler. The HPROF agent periodically samples the stack of all running threads to record the most frequently active stack traces. The?count?field above indicates how many times a particular stack trace was found to be active. These stack traces correspond to the CPU usage hot spots in the application. 2.1.4 CPU Usage Times Profile (cpu=times)The HPROF tool can collect CPU usage information by injecting code into every method entry and exit,thereby keeping track of exact method call counts and the time spent in each method. This process uses Byte Code Injection (BCI) and runs considerably slower than the?cpu=samples?option. Below is part of the output collected from a run of the?javac?compiler. $ javac -J-agentlib:hprof=cpu=times Hello.java CPU TIME (ms) BEGIN (total = 2082665289) Wed oct 4 13:43:42 2006 rank self accum count trace method 1 3.70% 3.70% 1 311243 com.sun.tools.javac.Main.compile 2 3.64% 7.34% 1 311242 com.sun.tools.javac.main.Main.compile 3 3.64% 10.97% 1 311241 com.sun.tools.javac.main.Main.compile 4 3.11% 14.08% 1 311173 com.sun.tools.javac.main.JavaCompiler.compile 5 2.54% 16.62% 8 306183 com.sun.tools.javac.jvm.ClassReader.listAll 6 2.53% 19.15% 36 306182 com.sun.tools.javac.jvm.ClassReader.list 7 2.03% 21.18% 1 307195 com.sun.tools.javac.comp.Enter.main 8 2.03% 23.21% 1 307194 com.sun.tools.javac.comp.Enter.complete 9 1.68% 24.90% 1 306392 com.sun.tools.javac.comp.Enter.classEnter 10 1.68% 26.58% 1 306388 com.sun.tools.javac.comp.Enter.classEnter ... CPU TIME (ms) END In this output the count represents the true count of the number of times this method was entered,and the percentages represent a measure of thread CPU time spent in those methods. 2.2 Java VisualVMJava VisualVM is one of the tools included in the JDK download (starting with JDK release 7 update 7). This tool is useful to Java application developers to troubleshoot applications and to monitor and improve the applications' performance. With Java VisualVM you can generate and analyze heap dumps,track down memory leaks,perform and monitor garbage collection,and perform lightweight memory and CPU profiling. The tool is also useful for tuning,heap sizing,offline analysis,and post-mortem diagnosis. In addition,you can use existing plug-ins that expand the functionality of Java VisualVM. For example,most of the functionality of the JConsole tool is available via the MBeans tab and the JConsole plug-in wrapper tab. You can choose from a catalog of standard Java VisualVM plug-ins by choosing Plugins from the Tools menu in the main Java VisualVM window. For comprehensive documentation for Java VisualVM,see? Java VisualVM allows you to perform the following troubleshooting activities:
When you start Java VisualVM,the main Application window opens,displaying a list of Java applications running on the local machine,a list of Java applications running on any connected remote machines,a list of any VM core dumps that were taken and saved (with Solaris OS and Linux),and a list of any application snapshots that were taken and saved. Java VisualVM will automatically detect and connect to JMX agents for Java applications that are running on JDK 7 or that have been started with the correct system properties on version 5.0. In order for the tool to detect and connect to the agents on a remote machine,the?jstatd?daemon must be running on the remote machine (see?
2.3 JConsole UtilityAnother useful tool included in the JDK download is the JConsole monitoring tool. This tool is compliant with Java Management Extensions (JMX). The tool uses the built-in JMX instrumentation in the Java Virtual Machine to provide information on the performance and resource consumption of running applications. Although the tool is included in the JDK download,it can also be used to monitor and manage applications deployed with the Java runtime environment. The JConsole tool can attach to any Java application in order to display useful information such as thread usage,memory consumption,and details about class loading,runtime compilation,and the operating system. This output helps with high-level diagnosis on problems such as memory leaks,excessive class loading,and running threads. It can also be useful for tuning and heap sizing. In addition to monitoring,JConsole can be used to dynamically change several parameters in the running system. For example,the setting of the?-verbose:gc?option can be changed so that garbage collection trace output can be dynamically enabled or disabled for a running application. The following list provides an idea of the data that can be monitored using the JConsole tool. Each heading corresponds to a tab pane in the tool.
JConsole can monitor both local applications and remote applications. If you start the tool with an argument specifying a JMX agent to connect to,the tool will automatically start monitoring the specified application. To monitor a local application,execute the command?jconsole?pid,where?pid?is the process ID of the application. To monitor a remote application,execute the command?jconsole?hostname:portnumber,where?hostname?is the name of the host running the application,and?portnumber?is the port number you specified when you enabled the JMX agent. If you execute the?jconsole?command without arguments,the tool will start by displaying the New Connection window,where you specify the local or remote process to be monitored. You can connect to a different host at any time by using the Connection menu. With the JDK 1.5 release,you must start the application to be monitored with the?-Dcom.sun.management.jmxremote?option. With the JDK 7 release,no option is necessary when starting the application to be monitored. As an example of the output of the monitoring tool,the following screen shows a chart of heap memory usage.
A complete tutorial on the JConsole tool is beyond the scope of this document. However,the following documents describe in more detail the monitoring and management capabilities,and how to use JConsole:
2.4?jdb?UtilityThe?jdb?utility is included in the JDK release as the example command-line debugger. The?jdb?utility uses the Java Debug Interface (JDI) to launch or connect to the target VM. The source code for?jdb?is included in?$JAVA_HOME/demo/jpda/examples.jar. The Java Debug Interface (JDI) is a high-level Java API that provides information useful for debuggers and similar systems that need access to the running state of a (usually remote) virtual machine. JDI is a component of the Java Platform Debugger Architecture (JPDA). 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 JDK release also ships with several Serviceability Agent (SA) connectors that allow a Java language debugger to attach to a crash dump or hung process. This can be useful in determining what the application was doing at the time of the crash or hang. These connectors are SACoreAttachingConnector,SADebugServerAttachingConnector,and SAPIDAttachingConnector. These connectors are generally used with enterprise debuggers,such as as NetBeans IDE or commerical IDEs. The following subsections demonstrate how these connectors can be used with the?jdb?command-line debugger. For detailed information about the connectors,see?. The command?jdb -listconnectors?prints a list of the available connectors. The command?jdb -help?prints the command usage. For more information on the?jdb?utility,refer to the manual pages:
2.4.1 Attaching to a ProcessThis 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. The command in the following example instructs?jdb?to use a connector named?sun.jvm.hotspot.jdi.SAPIDAttachingConnector. This is a connector name rather than a class name. The connector takes one argument called?pid,whose value is the process ID of the target process (9302 in this example). $ jdb -connect sun.jvm.hotspot.jdi.SAPIDAttachingConnector:pid=9302 In this example the?threads?command is used to get a list of all threads. Then a specific thread is selected with the?thread 0x7?command,and the?where?command is used to get a thread dump. Next the?up 1?command is used to move up one frame in the stack,and the?where?command is used again to get a thread dump. 2.4.2 Attaching to a Core File on the Same MachineThe SA Core Attaching Connector is used to attach the debugger to a core file. The core file may have been created after a crash (see?
The following command is an example of using this connector: $ jdb -connect sun.jvm.hotspot.jdi.SACoreAttachingConnector: javaExecutable=$JAVA_HOME/bin/java,core=core.20441 This command instructs?jdb?to use a connector named?sun.jvm.hotspot.jdi.SACoreAttachingConnector. The connector takes two arguments called?javaExecutable?and?core. The?javaExecutable?argument indicates the name of the Java binary. The?core?argument is the core file name (the core from the process with PID 20441 in this example). 2.4.3 Attaching to a Core File or a Hung Process from a Different MachineIn order to debug a core file that has been transported from another machine,the OS versions and libraries must match. In this case you can first run a proxy server called the SA Debug Server. Then,on the machine where the debugger is installed,you can use the SA Debug Server Attaching Connector to connect to the debug server. In the example below,there are two machines,machine 1 and machine 2. A core file is available on machine 1 and the debugger is available on machine 2. The SA Debug Server is started on machine 1 as follows. $ jsadebugd $JAVA_HOME/bin/java core.20441 The?jsadebugd?command takes two arguments. The first argument is the name of the executable. In most cases this is?java,but it can be another name (in the case of embedded VMs,for example). The second argument is the name of the core file. In this example the core file was obtained for a process with PID 20441 using the?gcore?utility. On machine 2,the debugger connects to the remote SA Debug Server using the SA Debug Server Attaching Connector,as with the following command: $ jdb -connect sun.jvm.hotspot.jdi.SADebugServerAttachingConnector: debugServerName=machine1 This command instructs?jdb?to use a connector named?sun.jvm.hotspot.jdi.SADebugServerAttachingConnector. The connector has one argument?debugServerName,which is the hostname or IP address of the machine where the SA Debug Server is running. Note that the SA Debug Server can also be used to remotely debug a hung process. In that case it takes a single argument which is the process ID of the process. In addition,if it is required to run multiple debug servers on the same machine,each one must be provided with a unique ID. With the SA Debug Server Attaching Connector,this ID is provided as an additional connector argument. These details are described in the JPDA documentation. 2.5?jhat?UtilityThe?jhat?tool provides a convenient means to browse the object topology in a heap snapshot. This tool was introduced in the JDK 6 release to replace the Heap Analysis Tool (HAT). For more information about the?jhat?utility,see the?. The tool parses a heap dump in binary format,for example,a heap dump produced by?jmap -dump. This utility can help debug unintentional object retention. This term is used to describe an object that is no longer needed but is kept alive due to references through some path from the rootset. This can happen,if an unintentional static reference to an object remains after the object is no longer needed,if an Observer or Listener fails to de-register itself from its subject when it is no longer needed,or if a Thread that refers to an object does not terminate when it should. Unintentional object retention is the Java language equivalent of a memory leak. The tool provides a number of standard queries. For example,the Roots query displays all reference paths from the rootset to a specified object and is particularly useful for finding unnecessary object retention. In addition to the standard queries,you can develop your own custom queries with the Object Query Language (OQL) interface. When you issue the?jhat?command,the utility starts an HTTP server on a specified TCP port. You can then use any browser to connect to the server and execute queries on the specified heap dump. The following example shows how to execute?jhat?to analyze a heap dump file named?snapshot.hprof: $ jhat snapshot.hprof Started HTTP server on port 7000 Reading from java_pid2278.hprof... Dump file created Fri May 19 17:18:38 BST 2006 Snapshot read,resolving... Resolving 6162194 objects... Chasing references,expect 12324 dots................................ Eliminating duplicate references..................................... Snapshot resolved. Server is ready. At this point?jhat?has started a HTTP server on port 7000. Point your browser to?http://localhost:7000?to connect to the?jhat?server. When you are connected to the server,you can execute the standard queries (see the following subsection) or create an OQL query (see?
2.5.1 Standard QueriesThe standard queries are described in these subsections. 2.5.1.1 All Classes QueryThe default page is the All Classes query,which displays all of the classes present in the heap,excluding platform classes. This list is sorted by fully-qualified class name,and broken out by package. Click on the name of a class to go to the Class query. 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. 2.5.1.2 Class QueryThe Class query displays information about a class. This includes its superclass,any subclasses,instance data members,and static data members. From this page you can navigate to any of the classes that are referenced,or you can navigate to an Instances query. 2.5.1.3 Object QueryThe Object query provides information about an object that was on the heap. From here,you can navigate to the class of the object and to the value of any object members of the object. You can also navigate to objects that refer to the current object. Perhaps the most valuable query is at the end: the Roots query (“Reference Chains from Rootset”). Note that the object query also provides a stack backtrace of the point of allocation of the object. 2.5.1.4 Instances QueryThe instances query displays all instances of a given class. The?allInstances?variant includes instances of subclasses of the given class as well. From here,you can navigate back to the source class,or you can navigate to an Object query on one of the instances. 2.5.1.5 Roots QueryThe Roots query displays reference chains from the rootset to a given object. It provides one chain for each member of the rootset from which the given object is reachable. When calculating these chains,the tool does a depth-first search,so that it will provide reference chains of minimal length. There are two kinds of Roots query: one that excludes weak references (Roots),and one that includes them (All Roots). A?weak reference?is a reference object that does not prevent its referent from being made finalizable,finalized,and then reclaimed. If an object is only referred to by a weak reference,it usually isn't considered to be retained,because the garbage collector can collect it as soon as it needs the space. This is probably the most valuable query in?jhat?for debugging unintentional object retention. Once you find an object that is being retained,this query tells you?why?it is being retained. 2.5.1.6 Reachable Objects QueryThis query is accessible from the Object query and shows the transitive closure of all objects reachable from a given object. This list is sorted in decreasing size,and alphabetically within each size. At the end,the total size of all of the reachable objects is given. This can be useful for determining the total runtime footprint of an object in memory,at least in systems with simple object topologies. This query is most valuable when used in conjunction with the?-exclude?command line option. This is useful,if the object being analyzed is an Observable. By default,all of its Observers would be reachable,which would count against the total size. The?-exclude?option allows you to exclude the data members?java.util.Observable.obs?andjava.util.Observable.arr. 2.5.1.7 Instance Counts for All Classes QueryThis 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 section on the All Classes query defines platform classes. 2.5.1.8 All Roots QueryThis query shows all members of the rootset,including weak references. 2.5.1.9 New Instances QueryThe New Instances query is available only if you invoke the?jhat?server with two heap dumps. This query is similar to the Instances query,except that it shows only new instances. An instance is considered new if it is in the second heap dump and there is no object of the same type with the same ID in the baseline heap dump. An object's ID is a 32–bit or 64–bit integer that uniquely identifies the object. 2.5.1.10 Histogram QueriesThe built-in histogram and finalizer histogram queries also provide useful information. 2.5.2 Custom QueriesYou can develop your own custom queries with the built-in Object Query Language (OQL) interface. Click on the Execute OQL Query button on the first page to display the OQL query page,where you can create and execute your custom queries. The OQL Help facility describes the built-in functions,with examples. The syntax of the?select?statement is as follows: select JavaScript-expression-to-select [ from [instanceof] classname identifier [ where JavaScript-boolean-expression-to-filter ] ] The following is an example of a?select?statement: select s from java.lang.String s where s.count >= 100 2.5.3 Heap Analysis HintsTo get useful information from?jhat?often requires some knowledge of the application and in addition some knowledge about the libraries and APIs that it uses. However in general the tool can be used to answer two important questions:
2.5.3.1 What is keeping an object alive?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. As noted earlier,there are two kinds of Roots queries: one that excludes weak references (Roots),and one that includes them (All Roots). A weak reference is a reference object that does not prevent its referent from being made finalizable,it usually is not considered to be retained,because the garbage collector can collect it as soon as it needs the space. The?jhat?tool sorts the rootset reference chains by the type of the root,in the following order:
2.5.3.2 Where was this object allocated?When an object instance is being displayed,the section entitled “Objects allocated from” shows the allocation site in the form of a stack trace. In this way,you can see where the object was created. Note that this allocation site information is available only if the heap dump was created with HPROF using the?heap=all?option. This HPROF option includes both the?heap=dump?option and the?heap=sites?option. If the leak cannot be identified using a single object dump,then another approach is to collect a series of dumps and to focus on the objects created in the interval between each dump. Thejhat?tool provides this capability using the?-baseline?option. The?-baseline?option allows two dumps to be compared if they were produced by HPROF and from the same VM instance. If the same object appears in both dumps it will be excluded from the list of new objects reported. One dump is specified as a baseline and the analysis can focus on the objects that are created in the second dump since the baseline was obtained. The following example show how to specify the baseline: $ jhat -baseline snapshot.hprof#1 snapshot.hprof#2 In the above example,the two dumps are in the file?snapshot.hprof,and they are distinguished by appending?#1?and?#2?to the file name. When?jhat?is started with two heap dumps,the Instance Counts for All Classes query includes an additional column that is the count of the number of new objects for that type. An instance is considered new if it is in the second heap dump and there is no object of the same type with the same ID in the baseline. If you click on a new count,then?jhat?lists the new objects of that type. Then for each instance you can view where it was allocated,which objects these new objects reference,and which other objects reference the new object. In general,the?-baseline?option can be very useful if the objects that need to be identified are created in the interval between the successive dumps. 2.6?jinfo?UtilityThe?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. The utility can also use the?jsadebugd?daemon to query a process or core file on a remote machine. Note that the output takes longer to print in this case. With the?-flag?option,the utility can dynamically set,or change the value of certain Java VM flags for the specified Java process. See?
For more information on the?jinfo?utility,refer to the?. The following is an example of the output from a Java process. $ jinfo 29620 Attaching to process ID 29620,please wait... Debugger attached successfully. Client compiler detected. JVM version is 1.6.0-rc-b100 Java System Properties: If you start the target Java VM with the?-classpath?and?-Xbootclasspath?arguments,the output from?jinfo?provides the settings for?java.class.path?and?sun.boot.class.path. This information might be needed when investigating class loader issues. In addition to obtaining information from a process,the?jinfo?tool can use a core file as input. On Solaris OS,the?gcore?utility can be used to get a core file of the process in the above example. The core file will be named?core.29620?and will be generated in the working directory of the process. The path to the Java executable and the core file must be specified as arguments to the?jinfo?utility,as in the following example: $ jinfo $JAVA_HOME/bin/java core.29620 Sometimes the binary name will not be?java. This occurs when the VM is created using the JNI invocation API. The?jinfo?tool requires the binary from which the core file was generated. 2.7?jmap?UtilityThe?jmap?command-line utility prints memory related statistics for a running VM or core file. The utility can also use the?jsadebugd?daemon to query a process or core file on a remote machine. Note that the output takes longer to print in this case. If?jmap?is used with a process or core file without any command-line options,then it prints the list of shared objects loaded (the output is similar to the?pmap?utility on Solaris OS). For more specific information,you can use the options?-heap,?-histo,or?-permstat. These options are described in the subsections that follow. In addition,the JDK 7 release introduced the?-dump:format=b,file=filename?option,which causes?jmap?to dump the Java heap in binary?HPROF?format to a specified file. This file can then be analyzed with the?jhat?tool. If the?jmap?pid?command does not respond because of a hung process,the?-F?option can be used (on Solaris OS and Linux only) to force the use of the Serviceability Agent. For more information on the?jmap?utility,refer to the?. 2.7.1 Heap Configuration and UsageThe?-heap?option is used to obtain the following Java heap information:
The following example shows output from the?jmap -heap?command. $ jmap -heap 29620 Attaching to process ID 29620,please wait... Debugger attached successfully. Client compiler detected. JVM version is 1.6.0-rc-b100 2.7.2 Heap Histogram of Running ProcessThe?-histo?option can be used to obtain a class-wise histogram of the heap. When the command is executed on a running process,the tool prints the number of objects,memory size in bytes,and fully qualified class name for each class. Internal classes in the HotSpot VM are enclosed in angle brackets. The histogram is useful in understanding how the heap is used. To get the size of an object you must divide the total size by the count of that object type. The following example shows output from the?jmap -histo?command when it is executed on a process. $ jmap -histo 29620 num #instances #bytes class name -------------------------------------- 1: 1414 6013016 [I 2: 793 482888 [B 3: 2502 334928 2.7.3 Heap Histogram of Core FileWhen the?jmap -histo?command is executed on a core file,the tool prints the size,count,and class name for each class. Internal classes in the HotSpot VM are prefixed with an asterisk (*). & jmap -histo /net/koori.sfbay/onestop/jdk/6.0/promoted/all/b100/binaries/ solaris-sparcv9/bin/java core Attaching to core core from executable /net/koori.sfbay/onestop/jdk/6.0/ promoted/all/b100/binaries/solaris-sparcv9/bin/java,please wait... Debugger attached successfully. Server compiler detected. JVM version is 1.6.0-rc-b100 Iterating over heap. This may take a while... Heap traversal took 8.902 seconds. 2.7.4 Getting Information on the Permanent GenerationThe permanent generation is the area of heap that holds all the reflective data of the virtual machine itself,such as class and method objects (also called “method area” in The Java Virtual Machine Specification). 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?
To get further information about the permanent generation,you can use the?-permstat?option to print statistics for the objects in the permanent generation. The following example shows output from the?jmap -permstat?command. $ jmap -permstat 29620 Attaching to process ID 29620,please wait... Debugger attached successfully. Client compiler detected. JVM version is 1.6.0-rc-b100 12674 intern Strings occupying 1082616 bytes. finding class loader instances ..Unknown oop at 0xd0400900 Oop's klass is 0xd0bf8408 Unknown oop at 0xd0401100 Oop's klass is null done. computing per loader stat ..done. please wait.. computing liveness.........................................done. class_loader classes bytes parent_loader alive? type For each class loader object,the following details are printed:
2.8?jps?UtilityThe?jps?utility lists the instrumented HotSpot Virtual Machines for the current user on the target system. The utility is very useful in environments where the VM is embedded,it is started using the JNI Invocation API rather than the?java?launcher. In these environments it is not always easy to recognize the Java processes in the process list. The following example demonstrates the usage of the?jps?utility. $ jps 16217 MyApplication 16342 jps The utility lists the virtual machines for which the user has access rights. This is determined by operating-system-specific access-control mechanisms. On Solaris OS,if a non-root user executes the?jps?utility,the output is a list of the virtual machines that were started with that user's?uid. In addition to listing the process ID,the utility provides options to output the arguments passed to the application's main method,the complete list of VM arguments,and the full package name of the application's main class. The?jps?utility can also list processes on a remote system if the remote system is running the?jstat?daemon (jstatd). If you are running several Java Web Start applications on a system,they tend to look the same,as shown in the following example: $ jps
1271 jps
1269 Main
1190 Main
In this case,use?jps -m?to distinguish them,as follows: $ jps -m
1271 jps -m
1269 Main http://bugster.central.sun.com/bugster.jnlp
1190 Main http://webbugs.sfbay/IncidentManager/incident.jnlp
For more information on the?jps?utility,refer to the?. The utility is included in the JDK download for all operating system platforms supported by Sun. NOTE -?THE HOTSPOT INSTRUMENTATION IS NOT ACCESSIBLE ON WINDOWS 98 OR WINDOWS ME. IN ADDITION,THE INSTRUMENTATION MIGHT NOT BE ACCESSIBLE ON WINDOWS IF THE TEMPORARY DIRECTORY IS ON A FAT32 FILE SYSTEM. 2.9?jrunscript?UtilityThe?jrunscript?utility is a command-line script shell. It supports script execution in both interactive mode and in batch mode. By default,the shell uses JavaScript,but you can specify any other scripting language for which you supply the path to the script engines's JAR file of?.class files. Thanks to the communication between the Java language and the scripting language,the?jrunscript?utility supports an?exploratory programming?style. For more information on the?jrunscript?utility,refer to the?. 2.10?jsadebugd?DaemonThe Serviceability Agent Debug Daemon (jsadebugd) attaches to a Java process or to a core file and acts as a debug server. This utility is currently available only on Solaris OS and Linux. Remote clients such as?jstack,?jmap,and?jinfo?can attach to the server using Java Remote Method Invocation (RMI). For more information on?jsadebugd,refer to the?. 2.11?jstack?UtilityThe?jstack?command-line utility attaches to the specified process or core file and prints the stack traces of all threads that are attached to the virtual machine,including Java threads and VM internal threads,and optionally native stack frames. The utility also performs deadlock detection. The utility can also use the?jsadebugd?daemon to query a process or core file on a remote machine. Note that the output takes longer to print in this case. A stack trace of all threads can be useful in diagnosing a number of issues such as deadlocks or hangs. The JDK 7 release introduced the?-l?option,which instructs the utility to look for ownable synchronizers in the heap and print information about?java.util.concurrent.locks. Without this option,the thread dump includes information only on monitors. Starting with JDK 7,the output from the?jstack?pid?option is the same as that obtained by pressing Ctrl- at the application console (standard input) or by sending the process a QUIT signal. See?
Thread dumps can also be obtained programmatically using the?Thread.getAllStackTraces?method,or in the debugger using the debugger option to print all thread stacks (the?wherecommand in the case of the?jdb?sample debugger). For more information on the?jstack?utility,refer to the?. 2.11.1 Forcing a Stack DumpIf the?jstack?pid?command does not respond because of a hung process,the?-F?option can be used (on Solaris OS and Linux only) to force a stack dump,as in the following example: $ jstack -F 8321 Attaching to process ID 8321,please wait... Debugger attached successfully. Client compiler detected. JVM version is 1.6.0-rc-b100 Deadlock Detection:
Thread t@10: (state = BLOCKED)
Thread t@6: (state = BLOCKED) Thread t@5: (state = BLOCKED)
Thread t@4: (state = BLOCKED)
Found one Java-level deadlock:"Thread1": Found a total of 1 deadlock. ----------------- t@1 ----------------- Frames that are prefixed with '*' are Java frames,while frames that are not prefixed with '*' are native C/C++ frames. The output of the utility can be piped through?c++filt?to demangle C++ mangled symbol names. Because the HotSpot Virtual Machine is developed in the C++ language,the?jstack?utility prints C++ mangled symbol names for the HotSpot internal functions. The?c++filt?utility is delivered with the native?c++?compiler suite:?SUNWspro?on Solaris OS and?gnu?on Linux. 2.12?jstat?UtilityThe?jstat?utility uses the built-in instrumentation in the HotSpot VM to provide information on performance and resource consumption of running applications. The tool can be used when diagnosing performance issues,and in particular issues related to heap sizing and garbage collection. The?jstat?utility does not require the VM to be started with any special options. The built-in instrumentation in the HotSpot VM is enabled by default. The utility is included in the JDK download for all operating system platforms supported by Sun. NOTE -?THE INSTRUMENTATION IS NOT ACCESSIBLE ON WINDOWS 98 OR WINDOWS ME. IN ADDITION,INSTRUMENTATION IS NOT ACCESSIBLE ON WINDOWS NT,2000,OR XP IF A FAT32 FILE SYSTEM IS USED. The following list presents the options for the?jstat?utility.
For a complete description of the?jstat?utility,refer to the?. The documentation includes a number of examples,and a few of those examples are repeated here in this document. The?jstat?utility uses a?vmid?to identify the target process. The documentation describes the syntax of a?vmid?but in the simplest case a?vmid?can be a local virtual machine identifier. In the case of Solaris OS,Linux,and Windows,it can be considered to be the process ID. Note that this is typical but may not always be the case. The?jstat?tool provides data similar to the data provided by the tools?vmstat?and?iostat?on Solaris OS and Linux. For a graphical representation of the data,you can use the?visualgc?tool. See?
2.12.1 Example of?-gcutil?OptionBelow is an example of the?-gcutil?option. The utility attaches to?lvmid?2834,takes nine samples at 250 millisecond intervals,and displays the output. $ jstat -gcutil 2834 250 9 S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 0.00 87.14 46.56 96.82 54 1.197 140 86.559 87.757 0.00 0.00 91.90 46.56 96.82 54 1.197 140 86.559 87.757 0.00 0.00 100.00 46.56 96.82 54 1.197 140 86.559 87.757 0.00 27.12 5.01 54.60 96.82 55 1.215 140 86.559 87.774 0.00 27.12 11.22 54.60 96.82 55 1.215 140 86.559 87.774 0.00 27.12 13.57 54.60 96.82 55 1.215 140 86.559 87.774 0.00 27.12 18.05 54.60 96.82 55 1.215 140 86.559 87.774 0.00 27.12 23.85 54.60 96.82 55 1.215 140 86.559 87.774 0.00 27.12 27.32 54.60 96.82 55 1.215 140 86.559 87.774 The output of this example shows that a young generation collection occurred between the third and fourth samples. The collection took 0.017 seconds and promoted objects from the?edenspace (E) to the?old?space (O),resulting in an increase of old space utilization from 46.56% to 54.60%. 2.12.2 Example of?-gcnew?OptionThe following example illustrates the?-gcnew?option. The utility attaches to?lvmid?2834,takes samples at 250 millisecond intervals,and displays the output. In addition,it uses the?-h3option to display the column header after every 3 lines of data. $ 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 In addition to showing the repeating header string,this example shows that between the fourth and fifth samples,a young generation collection occurred,whose duration was 0.02 seconds. The collection found enough live data that the survivor space 0 utilization (S1U) would have exceeded the desired survivor size (DSS). As a result,objects were promoted to the old generation (not visible in this output),and the tenuring threshold (TT) was lowered from 15 to 1. 2.12.3 Example of?-gcoldcapacity?OptionThe following example illustrates the?-gcoldcapacity?option. The utility attaches to?lvmid?21891 and takes 3 samples at 250 millisecond intervals. The?-t?option is used to generate a time stamp for each sample in the first column. $ jstat -gcoldcapacity -t 21891 250 3
Timestamp OGCMN OGCMX OGC OC YGC FGC FGCT GCT
150.1 1408.0 60544.0 11696.0 11696.0 194 80 2.874 3.799
150.4 1408.0 60544.0 13820.0 13820.0 194 81 2.938 3.863
150.7 1408.0 60544.0 13820.0 13820.0 194 81 2.938 3.863
The Timestamp column reports the elapsed time in seconds since the start of the target Java VM. In addition,the?-gcoldcapacity?output shows the old generation capacity (OGC) and the old space capacity (OC) increasing as the heap expands to meet allocation or promotion demands. The old generation capacity (OGC) has grown from 11696 KB to 13820 KB after the 81st Full GC (FGC). The maximum capacity of the generation (and space) is 60544 KB (OGCMX),so it still has room to expand. 2.13?jstatd?DaemonThe?jstatd?daemon is a Remote Method Invocation (RMI) server application that monitors the creation and termination of instrumented Java HotSpot virtual machines and provides an interface to allow remote monitoring tools to attach to Java VMs running on the local host. For example,this daemon allows the?jps?utility to list processes on a remote system. NOTE -?THE INSTRUMENTATION IS NOT ACCESSIBLE ON WINDOWS 98 OR WINDOWS ME. IN ADDITION,OR XP IF A FAT32 FILE SYSTEM IS USED. For more information about the?jstatd?daemon,including detailed usage examples,refer to the?. 2.14?visualgc?ToolThe?visualgc?tool is related to the?jstat?tool. (See?
The?visualgc?tool is not included in the JDK release but is available as a separate download from the?. The following screen output demonstrates how the GC and heap are visualized. visualgc
2.15 Ctrl-Break HandlerOn Solaris OS or Linux,the combination of pressing the Ctrl key and the backslash () key at the application console (standard input) causes the HotSpot VM to print a thread dump to the application's standard output. On Windows the equivalent key sequence is the Ctrl and Break keys. The general term for these key combinations is the Ctrl-Break handler. On Solaris OS and Linux,a thread dump is printed if the Java process receives a QUIT signal. Therefore,the?kill -QUIT?pid?command causes the process with ID?pid?to print a thread dump to the standard output. The following subsections explain in detail the output from the Ctrl-Break handler: 2.15.1 Thread DumpThe thread dump consists of the thread stack,including thread state,for all Java threads in the virtual machine. The thread dump does not terminate the application: it continues after the thread information is printed. The following example illustrates a thread dump. Full thread dump Java HotSpot(TM) Client VM (1.6.0-rc-b100 mixed mode):
"Thread1" prio=10 tid=0x000d6c00 nid=0xa waiting for monitor entry [0xf37ff000..0xf37ffbc0]
"Low Memory Detector" daemon prio=10 tid=0x000c7800 nid=0x8 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=10 tid=0x000c5400 nid=0x7 waiting on condition [0x00000000..0x00000000] "Signal Dispatcher" daemon prio=10 tid=0x000c4400 nid=0x6 waiting on condition [0x00000000..0x00000000] "Finalizer" daemon prio=10 tid=0x000b2800 nid=0x5 in Object.wait() [0xf3f7f000..0xf3f7f9c0]
"Reference Handler" daemon prio=10 tid=0x000ae000 nid=0x4 in Object.wait() [0xfe57f000..0xfe57f940]
"VM Thread" prio=10 tid=0x000ab000 nid=0x3 runnable "VM Periodic Task Thread" prio=10 tid=0x000c8c00 nid=0x9 waiting on condition The output consists of a header and a stack trace for each thread. Each thread is separated by an empty line. The Java threads (threads that are capable of executing Java language code) are printed first,and these are followed by information on VM internal threads. The header line contains the following information about the thread:
The following table lists the possible thread states that can be printed. 相关内容
|
