Tips About JDK5.0' Tool
http://www.javaperformancetuning.com/news/newtips063.shtmlTips February 2006 About JDK5.0' Tool
http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf
JSE 5.0 Trouble-Shooting and Diagnostic Guide (Page last updated June 2005, Added 2006-02-27, Author Sun, Publisher Sun). Tips:<!--0-->
<!--CTGRY -->
[*]jstack, jinfo, and jmap command line utilities are included in the JDK release for Solaris and Linux only.<!--CTGRY -->
[*]jstack, jinfo, jmap and jdb can obtain info from running JVMs and from core files generated from JVM crashes.<!--CTGRY -->
[*]jstat and jconsole enable the monitoring of many aspects of a running JVM.<!--CTGRY -->
[*]The HPROF profiler is a simple profiler includedin the JDK, capable of presenting CPU usage, heap allocationstatistics, contention profiles, heap dumps, states of all the monitorsand threads. HPROF can be useful when analyzing performance, lockcontention, memory leaks, and other issues.<!--CTGRY -->
[*]The Heap Analysis Tool (HAT) is a useful fordiagnosing unnecessary object retention (or memory leaks). It can beused to browse an object dump, view all reachable objects in the heap,and understand which references are keeping an object alive.<!--CTGRY -->
[*]jinfo prints the system properties and the command line flags that were used to start the VM, e.g. with jinfo <pid|core>.<!--CTGRY -->
[*]jmap prints memory related statistics for arunning VM or core file; by default it prints the list of sharedobjects loaded (the output is similar to the Solaris pmap utility).<!--CTGRY -->
[*]jmap -heap prints GC algorithm specificinformation: the name and details of the GC algorithm in use; the heapconfiguration; and a heap usage summary (total capacity, in-use andavailable free memory for each generation).<!--CTGRY -->
[*]jmap -histo provides a class-wise histogram ofthe heap: for each class, it prints the number of objects, memory sizein bytes, and fully qualified class name.<!--CTGRY -->
[*]If an application loads or generates too manyclasses then it is possible it will abort with an OutOfMemoryError. Thespecific error is: "Exception in thread XXXXjava.lang.OutOfMemoryError: PermGen space".<!--CTGRY -->
[*]jmap -permstat provides details on classloaderstatistics. For each classloader instance six fields are printed: classloader object hexadecimal address; number of classes loaded; totalapproximate number of bytes used class by meta-data; hexadecimaladdress of the parent class loader; GCable (dead indicates classloaderwill be garbage collected); the class name of this class loader.<!--CTGRY -->
[*]jstack prints a stack trace of all threads -similar to using the thread dump handler (i.e. Cntrl-\ or kill -QUIT orThread.getAllStackTraces).<!--CTGRY -->
[*]Thread states in a thread stack dump can be oneof the following: UNINTIALIZED Thread is not created; NEW Thread hasbeen created but it has not started running yet; IN_NATIVE Thread isrunning native code; IN_VM Thread is running VM code; IN_JAVA Thread isrunning (either interpreted or compiled) Java code; BLOCKED Thread isblocked; ..._TRANS If you see any of the states followed by "_TRANS",it means the thread is changing to a different state.<!--CTGRY -->
[*]jstack stack lines have the format <Fullyqualified class name>.<Method name> @bc=<Byte codeindex>, line=<Source line number> (Methodcompiled/interpreted?), e.g. "java.lang.Thread.run() @bci=11, line=595(Interpreted frame)"<!--CTGRY -->
[*]jstack -m will print a (mixed) stack includingnative stack frames in addition to the java stack. (Native frames arethe C/C++ frames associated with VM code, and JNI/native code; you mayneed to pipe the output through the c++filt to demangle C++ mangledsymbol names.)<!--CTGRY -->
[*]jconsole can attach to any application that isstarted with the JMX agent. The -Dcom.sun.management.jmxremote optionis the system property which enables the JMX agent.<!--CTGRY -->
[*]The jconsole Summary panel lists: Uptime: howlong the JVM has been running; Total compile time: the amount of timespent in runtime compilation; Process CPU time: the total amount of CPUtime consumed by the JVM.<!--CTGRY -->
[*]The jconsole Memory panel lists: Current heapsize: Number of Kbytes currently occupied by the heap; Committedmemory: Total amount of memory allocated for use by the heap; Maximumheap size: Maximum number of Kbytes occupied by the heap; Objectspending for finalization: Number of objects pending for finalization;Garbage collector information: Information on GC, including the garbagecollector names, number of collections performed, and total time spentperforming GC.<!--CTGRY -->
[*]The jconsole Threads panel lists: Currentnumber of live daemon threads plus non-daemon threads; Highest numberof live threads since JVM started; Current number of live daemonthreads; Total number of threads started since the JVM started(including daemon, non-daemon, and terminated).<!--CTGRY -->
[*]The jconsole Classes panel lists: Number ofclasses currently loaded into memory; Total number of classes loadedinto memory since the JVM started, including those subsequentlyunloaded; Number of classes unloaded from memory since the JVM started.<!--CTGRY -->
[*]The jconsole Operating System panel lists:Amount of random-access memory (RAM) that the machine has; Amount offree RAM the machine has; Amount of virtual memory guaranteed to beavailable to the running process.<!--CTGRY -->
[*]jps lists accessible JVMs on the local system(and prints other parameters of teh JVM depending on options used);also for remote systems that are running jstatd.<!--CTGRY -->
[*]jstat uses built-in HotSpot VM instrumentationto provide information on performance and resource consumption ofrunning applications, in particular issues related to heap sizing andgarbage collection.<!--CTGRY -->
[*]jstat options prints statistics on: classloaders, the HotSpot compiler, and garbage collected heap stats andcapacities by generations.<!--CTGRY -->
[*]visualgc provides a graphical view of thegarbage collection system. As with jstat it uses the built-ininstrumentation of the HotSpot VM.<!--CTGRY -->
[*]HPROF is a simple dynamically-linked libraryprofiler agent shipped with JDK 5.0. HPROF is capable of presenting CPUusage, heap allocation statistics and monitor contention profiles. Itcan also report complete heap dumps and states of all the monitors andthreads.<!--CTGRY -->
[*]HPROF is invoked with "java -agentlib:hprof<ToBeProfiledClass>"; use "java -agentlib:hprof=help" to get alisting of all the available HPROF options<!--CTGRY -->
[*]For HPROF cpu=samples is the recommended method profiling option; heap=sites is the recommended object memory profiling option.<!--CTGRY -->
[*]HPROF heap dump output is complex; the articlecovers some types of entry but recommends using HAT or other tool (HPhave one too) to visualize the information.<!--CTGRY -->
[*]HAT (available from http://hat.dev.java.net) iscapable of reading HPROF output in order to identify object roots thatmay be causing unintentional object retention.<!--CTGRY -->
[*]The "-XX:OnError=" option enables otheroperating system processes to be run if the JVM terminates on a fatalhotspot error, for example "java -XX:OnError="gcore %p" ..." to createa core dump on Solaris; or "java -XX:OnError="userdump.exe %p"MyApplication on Windows (or configure the Windows system to use DrWatson to automatically create a crash dump).<!--CTGRY -->
[*].<!--CTGRY -->
[*].<!--CTGRY -->
[*]A stack dump is printed to stdout if thectrl-break handler is executed (normally kill -QUIT or cntrl-\ on Unixor cntrl-brk on Windows). The ctrl-break handler also executes adeadlock detection algorithm: If any deadlocks are detected then itprints out additional information on each deadlocked thread.<!--CTGRY -->
[*]A thread header line in a ctrl-break handlerstack dump reads as follows: "<thread name>" prio=<java_priority> tid=<address of the thread structure inmemory> nid=<id of the native thread> <Thread state>[<address range ? this is an estimate of the valid stack region forthe thread.>], e.g."Java2D Disposer" daemon prio=10 tid=0x002007d8nid=0xb in Object.wait() .<!--CTGRY -->
[*]The possible thread states in the output from actrl-break handler stack dump are: allocated; initialized; runnable;waiting for monitor entry; waiting on condition; in Object.wait();sleeping.<!--CTGRY -->
[*]If the ctrl-break handler deadlock detectoridentifies a deadlock, then after the thread dump the information isprinted starting with the line "Found one Java-level deadlock:"<!--CTGRY -->
[*]Information about GCs can be obtained using the options -verbose:gc -XX:+PrintGCDetails and -XX:+PrintGCTimeStamp. <!--CTGRY -->
[*]The -verbose:gc option can be dynamically enabled at runtime using the management API or JVM TI or using the jconsole tool.<!--CTGRY -->
[*]The -Xcheck:jni option makes the VM doadditional validation on the arguments passed to JNI functions. When aninvalid argument is detected, the VM prints a "FATAL ERROR in nativemethod:" message, prints the stack trace of the offending thread, andaborts the VM. (Also possible that the message "Warning: Calling otherJNI functions in the scope of Get/ReleasePrimitiveArrayCritical orGet/ReleaseStringCritical" may be printed).<!--CTGRY -->
[*].<!--CTGRY -->
[*]You can use the java.lang.management package toimplement additional management and monitoring; it covers interfacesfor the following systems: class loading; compilation; garbagecollection; memory manager; runtime; threads.<!--CTGRY -->
[*]The Sun implementation of 5.0 includes platformextensions in the com.sun.management package (seehttp://java.sun.com/j2se/1.5.0/docs/guide/management/extension/index.html).The platform extensions include a management interface to obtaindetailed statistics from garbage collectors and additional memorystatistics from the operating system.<!--CTGRY -->
[*]The java.lang.instument package(http://java.sun.com/j2se/1.5.0/docs/api/index.html) provides servicesthat allow Java programming language agents to instrument programsrunning on the JVM, for both load-time and dynamic instrumentation.<!--CTGRY -->
[*]java.lang.Thread.getAllStackTraces returns a map of stack traces for all live threads. <!--CTGRY -->
[*]java.lang.Thread.getState that returns the thread state; states are defined by the java.lang.Thread.State enumeration. <!--CTGRY -->
[*]OutOfMemoryError are now classified: heap space(increase mx); permgen space (increase perm space size); operatingsystem space (increase RAM/swap); in all cases an alternative is toreduce memory requirements; any OOME could be from unintentional objectretention (an object leak).<!--CTGRY -->
[*]"Exception in thread "main"java.lang.OutOfMemoryError: Java heap space" signifies not enough spaceavailable to create another object; either mx needs increasing or youhave unintentional object retention (an object leak).<!--CTGRY -->
[*]"Exception in thread "main"java.lang.OutOfMemoryError: PermGen space" signifies too many classesloaded or being generated; or the String.intern table is too big.Increase using the -XX:MaxPermSize option.<!--CTGRY -->
[*]"Exception in thread "main"java.lang.OutOfMemoryError: Requested array size exceeds VM limit"signifies not enough space available to create another array; either mxneeds increasing or you have unintentional object retention (an objectleak).<!--CTGRY -->
[*]"Exception in thread "main"java.lang.OutOfMemoryError: request <size> bytes for<reason>. Out of swap space?" signifies either a memory leak ofsome sort, or more likely you ran out of available operating systemmemory.<!--CTGRY -->
[*]"Exception in thread "main"java.lang.OutOfMemoryError: <reason>" followed by "<stacktrace>(Native method)" signifies Note that this is where the topelement in the stack trace is a native method; either a memory leak ofsome sort, or more likely you ran out of available operating systemmemory.<!--CTGRY -->
[*]If you get a crash instead of anOutOfMemoryError, this is likely to be because a JNI level functionused the NULL returned from a malloc call as a valid memory pointer.This indicates either a memory leak of some sort, or more likely youran out of available operating system memory.<!--CTGRY -->
[*]If a class has a finalize method then objectsof that type do not have their space reclaimed at garbage collectiontime. Instead after garbage collection the objects are queued forfinalization which occurs sometime later.<!--CTGRY -->
[*]In the Sun JVM implementation finalizers areexecuted by a daemon thread that services the finalization queue. Ifthe finalizer thread cannot keep up with the finalization queue then itis possible that the java heap will fill up and OutOfMemoryError willbe thrown.<!--CTGRY -->
[*]jconsole can be used to monitor the number ofobjects that are pending finalization. (excessive use of finalizers canbe the cause of OutOfMemoryError). In jconsole the pending finalizationcount is reported in the memory statistics on the "Summary" tab pane.The count is approximate but it can be used to characterize anapplication and understand if it relies a lot on finalization.<!--CTGRY -->
[*]Diagnosing leaks in Java Language code can be adifficult task, it is suggested that you use a profiler. Using HAT youwould use java -agentlib:hprof=file=dump.hprof,format=b<Application><!--CTGRY -->
[*].<!--CTGRY -->
[*]Anyone writing a JNI library would probably bewise to create some kind of localized way to make sure your librarydoesn't leak memory using a simple wrapper approach. .<!--CTGRY -->
[*]libumem can be used to diagnose a native memory leak in Solaris.<!--CTGRY -->
[*]<!--CTGRY -->
[*]To detect the cause of looping, get one or more thread dumps, that is usually sufficient to see where the execution locus is.<!--CTGRY -->
[*]If the VM does not respond to a Ctrl-\ this maysuggest a possible VM bug rather than an issue with application orlibrary code. In this case use jstack with the -m option to get athread stack for all threads.<!--CTGRY -->
[*]In J2SE 5.0 deadlock detection works only withlocks that are obtained using the synchronized keyword. This means thatdeadlocks that arise through the use of the java.util.concurrencypackage are not detected.<!--CTGRY -->
[*].
页:
[1]