Jstack (view threads), Jmap (view memory), and Jstat (profiling) commands

jstack (view thread), jmap (view memory), and jstat (performance analysis) commands
  An article shared by colleagues within the company

On the weekend, I saw an example of using jstack to view deadlocks. Last night summarized the jstack (view thread), jmap (view memory) and jstat (performance analysis) commands. For reference

1. Jstack
1.1 jstack can get information about java stack and native stack running java programs. You can easily know the running status of the current thread. As shown

Note: This is the same result as thread dump. But thread dump uses kill -3 pid command, or it is better to use less kill on the server

1.2 Named line format
jstack [option] pid
jstack [option] executable core
jstack [option] [[email protected]] remote-hostname-or-IP
The most commonly used is jstack pid

1.3 In thread dump, pay attention to the following states
Deadlock, Deadlock (focus on)
Waiting for resources, Waiting on condition (focus on)
• Waiting for monitor entry, Waiting on monitor entry (focus on)
Blocked, Blocked (focus on)
• Running, Runnable
• Suspended
• Object waiting, Object.wait () or TIMED_WAITING
• Stop, Parked
There are detailed examples below to illustrate this analysis, please refer to the original book
http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html

1.4 In thread dump, there are several types of threads defined as follows
Thread name Belong to Explanation
Attach Listener JVM The Attach Listener thread is responsible for receiving external commands, and executes the commands and returns the results to the sender. Usually we will use some commands to ask jvm to give us some feedback information, such as: java -version, jmap, jstack, etc. If the thread is not initialized when the jvm is started, it will be started when the user executes the jvm command for the first time.
Signal Dispatcher JVM Earlier we mentioned that the responsibility of the first Attach Listener thread is to receive external jvm commands. When the command is successfully received, it will be handed over to the signal dispather thread to distribute the processing commands to different modules and return the processing results. The signal dispather thread also initializes the first time it receives an external jvm command.
CompilerThread0 JVM is used to call JITing and compile and unload classes in real time. Usually, the jvm will start multiple threads to handle this part of the work, the number behind the thread name will also be accumulated, for example: CompilerThread1
Concurrent Mark-Sweep GC Thread JVM Concurrent Mark Cleanup garbage collector (also known as CMS GC) thread, this thread is mainly for the old generation of garbage collection. ps: enable the garbage collector, you need to add: -XX: + UseConcMarkSweepGC in the jvm startup parameters
The DestroyJavaVM JVM thread that executes main () calls the jni_DestroyJavaVM () method in JNI after main executes to call up the DestroyJavaVM thread. After the JVM is started on the Jboss server, it will call up the DestroyJavaVM thread and wait for it to wait for other threads (java thread and native thread) to exit and notify it to uninstall the JVM. When the thread exits, it will determine whether it is currently the last non-deamon thread in the entire JVM. If it is, it will notify the DestroyJavaVM thread to uninstall the JVM.
ps:
Expand it:
1. If the thread exits and determines that it is not the last non-deamon thread, then call thread-> exit (false) and throw a thread_end event in it, and the jvm will not exit.
2. If the thread exits and determines that it is the last non-deamon thread, then the before_exit () method is called and two events are thrown: Event 1: thread_end thread end event, and event 2: VM's death event.
    Then call the thread-> exit (true) method, then remove the thread from the active list, delete the thread, etc. After a series of work is completed, notify the waiting DestroyJavaVM thread to perform the uninstall JVM operation.
ContainerBackgroundProcessor thread JBOSS It is a daemon thread. It is initialized when the jboss server is started. The main job is to periodically check whether the Session has expired. If it expires, it is cleared.
Reference: http://liudeh-009.iteye.com/blog/1584876

Dispatcher-Thread-3 thread Log4j Log4j has the function of printing logs asynchronously. Appenders that need to print logs asynchronously need to be registered in the AsyncAppender object. AsyncAppender listens to determine when to trigger the log printing operation. AsyncAppender generates a corresponding event for the Appender if it monitors that the Appender within its jurisdiction is printing logs, and saves the event in a buffuer area. The Dispatcher-Thread-3 thread is responsible for determining whether the event buffer area is full. If it is full, all events in the buffer area are distributed to the Appender container. After the registered Appender receives its own event, Start processing your own log printing job. The Dispatcher-Thread-3 thread is a daemon thread.
Finalizer thread JVM This thread is also created after the main thread, and its priority is 10. It is mainly used to call the finalize () method of the object before garbage collection; a few points about the Finalizer thread:
1) The finalize () method will only be called when a round of garbage collection begins; therefore not all objects' finalize () method will be executed;
2) This thread is also a daemon thread, so if there are no other non-daemon threads in the virtual machine, regardless of whether the thread has finished executing the finalize () method, the JVM will also exit;
3) The JVM will wrap the lost reference object into a Finalizer object (Reference implementation) during garbage collection, and put it into the ReferenceQueue, which will be processed by the Finalizer thread; Finally, the reference of the Finalizer object will be set to null, which will be collected by the garbage collector Recycling
4) Why does the JVM use a single thread to execute the finalize () method? If the JVM's garbage collection thread does it by itself, it is likely that the GC thread is stopped or uncontrollable due to misoperation in the finalize () method, which is a disaster for the GC thread;
Gang worker # 0 JVM JVM is used as a thread for the new generation of garbage collection (monir gc). The # number is followed by the thread number, for example: Gang worker # 1
GC Daemon JVM The GC Daemon thread is used by the JVM to provide remote distributed GC for RMI. The GC Daemon thread will actively call the System.gc () method to perform Full GC on the server. The original intention was that when the RMI server returned an object to its client (the caller of the remote method), it tracked the use of the remote object in the client. When there are no more references to the remote object on the client, or if the "lease" of the reference expires and is not updated, the server will garbage collect the remote object.
However, we now add -XX: + DisableExplicitGC configuration to the jvm startup parameters, so this thread is only for soy sauce.
The IdleRemover JBOSS Jboss connection pool has a minimum value. This thread will be called by Jboss every time. It is used to check and destroy idle and invalid connections in the connection pool until the number of remaining connections is less than or equal to its minimum value.
The Java2D Disposer JVM thread mainly serves the various components of awt. Before talking about the main job responsibilities of this thread, you need to introduce what the Disposer class does. Disposer provides an addRecord method. If you want to do some aftercare work before an object is destroyed, then you can call the Disposer # addRecord method, pass this object together with a custom DisposerRecord interface implementation class, and pass it in for registration.
          The Disposer class will evoke the "Java2D Disposer" thread. The thread will scan whether these registered objects are to be recycled, and if so, call the dispose method in the DisposerRecord implementation class corresponding to the object.
          Disposer is actually not limited to awt application scenarios, just that many components in awt need to access many operating system resources, so when these components are recycled, they need to release these resources first.
InsttoolCacheScheduler_
QuartzSchedulerThread Quartz InsttoolCacheScheduler_QuartzSchedulerThread is Quartz's main thread, which is mainly responsible for obtaining the trigger to be triggered at the next time point in real time, and then execute the job associated with the trigger.
         The principle is roughly as follows:
         In the scenario where Spring and Quartz are used together, the Spring IOC container will create and initialize the Quartz thread pool (TreadPool) when it is initialized, and start it. When starting, each thread in the thread pool is in a waiting state, waiting for the outside world to allocate Runnable (the thread holding the job object).
         Then the Quartz main thread (InsttoolCacheScheduler_QuartzSchedulerThread) is initialized and started, and the thread will be in a waiting state since it is started. After waiting for the outside to give a work signal, the run method of the main thread actually starts to work. Run will get the next job to be triggered in JobStore. After getting it, it will wait until the actual trigger time of the job, and then package the job into a JobRunShell object (this object implements the Runnable interface, in fact, it is seen in the TreadPool above Wait for the Runnable assigned to him by the outside world), and then hand the newly created JobRunShell to the thread pool, which is responsible for executing the job.
After the thread pool receives the Runnable, it starts the Runnable from a thread in the thread pool and reflects the run method in JobRunShell. After the execution of the run method is completed, TreadPool recycles the thread to the idle thread.
InsttoolCacheScheduler_Worker-2 Quartz InsttoolCacheScheduler_Worker-2 thread is a simple implementation of ThreadPool thread, which is mainly responsible for allocating thread resources to execute
InsttoolCacheScheduler_QuartzSchedulerThread thread to its scheduled task (that is, JobRunShell).
JBossLifeThread Jboss Jboss main thread started successfully. After the application is deployed, the JBossLifeThread thread is instantiated and started. After the JBossLifeThread thread is successfully started, it is in a waiting state to keep the Jboss Java process alive. The income is more popular, that is, after the execution of the Jboss startup process is completed, why is it not over? It is because this thread holds the master.牛 b 吧 ～～
JBoss System Threads (1) -1 Jboss This thread is a socket service, the default port number is: 1099. Mainly used to receive external naming service (Jboss JNDI) requests.
JCA PoolFiller Jboss This thread mainly provides JBoss internal connection pool hosting. Briefly introduce the working principle:
    All classes within Jboss that have remote connection requirements need to implement the ManagedConnectionFactory interface, such as JDBC connection.
XAManagedConnectioThe nFactory object implements this interface. Then pack the XAManagedConnectionFactory object and other information into the InternalManagedConnectionPool object, and then hand over the InternalManagedConnectionPool to the queue in the PoolFiller object for management. The JCA PoolFiller thread will periodically determine whether there is an InternalManagedConnectionPool object that needs to be created and managed in the queue, and if so, call the fillToMin method of the object to trigger it to create the corresponding remote connection and maintain this connection to its corresponding connection Go inside the pool.
JDWP Event Helper Thread JVM
JDWP is a communication and interaction protocol, which defines the format for transferring information between the debugger and the debugged program. It defines the request commands, response data and error codes in detail and completely, ensuring the smooth communication between the JVMTI and JDI at the front end and the back end. This thread is mainly responsible for mapping JDI events into JVMTI signals to achieve the purpose of operating the JVM during debugging.


JDWP Transport Listener: dt_socket JVM This thread is a Java Debugger listener thread that is responsible for accepting client debug requests. Usually we are used to set its listening port to 8787.
Low Memory Detector JVM This thread is responsible for detecting available memory. If the available memory is found to be low, allocate new memory space.
process reaper JVM This thread is responsible for performing an OS command line operation.
Reference Handler JVM The JVM creates the Reference Handler thread after the main thread is created. Its highest priority is 10, which is mainly used to deal with the garbage collection problem of the reference object itself (soft reference, weak reference, virtual reference).
Surrogate Locker Thread (CMS) JVM This thread is mainly used in conjunction with the CMS garbage collector, it is a daemon thread, which is mainly responsible for processing GC process, Java layer Reference (referring to soft references, weak references, etc.) and jvm internal Object state synchronization at the level. Here is a brief introduction to their implementation: WeakHashMap is used as an example here, and some key points are listed first (we will string all these key points later):
1. We know that HashMap uses Entry [] array to store data, WeakHashMap is no exception, there is an Entry [] array inside.
2. The Entry of WeakHashMap is special, and its inheritance architecture is Entry-> WeakReference-> Reference.
3. There is a global lock object in Reference: Lock, which is also called pending_lock. Note: It is a static object.
4. There is a static variable in Reference: pending.
5. There is a static internal class in Reference: the thread of ReferenceHandler, which is initialized and started in the static block. After the startup is completed, it is in the wait state, and it waits in a Lock synchronization lock module.
6. In addition, WeakHashMap also instantiates a ReferenceQueue queue. The role of this queue will be mentioned later.
7. The key points above have been introduced. Let's string them together.
     Suppose that the WeakHashMap object already contains references to many objects. When the JVM is performing CMS GC, it will create a ConcurrentMarkSweepThread (CMST) thread to perform GC. When the ConcurrentMarkSweepThread thread is created, it will also create a SurrogateLockerThread (SLT) thread and start it. After the SLT is started, it is in the waiting phase. When CMST starts GC, it will send a message to SLT to let it acquire the global lock of the Java Reference object: Lock. After the CMS GC is completed, the JVM will put the WeakReference container object of all the recovered objects in the WeakHashMap into the pending property of the Reference (after each GC, the pending property will basically not be null), and then notify SLT releases and notifies the global lock: Lock. At this time, the run method of the ReferenceHandler thread is activated, so that it leaves the wait state and starts to work. The ReferenceHandler thread will move all WeakReference objects in the pending to their respective queues. For example, the current WeakReference belongs to a WeakHashMap object, then it will be put into the corresponding ReferenceQueue queue (the queue is a linked list structure). When we next get, put data or call the size method from the WeakHashMap object, WeakHashMap will come out of the WeakReference in the ReferenceQueue queue and compare it with the Entry [] data. If the same is found, it means that the Entry The saved object has been deleted by GC, then delete the Entry object in Entry [].
taskObjectTimerFactory JVM As the name suggests, this thread is used to perform tasks. When we give a Timer object and tell it the execution time, after the cycle time, Timer will put the task into the task queue and notify the taskObjectTimerFactory thread to process the task. The taskObjectTimerFactory thread will remove the task with the status of canceled from the task. Removed from the queue. If the task is of a non-repetitive execution type, it will be removed from the task queue after the task is executed. If the task needs to be repeatedly executed, the time point of its next execution is calculated.
VM Periodic Task Thread JVM This thread is the thread for JVM periodic task scheduling. It is created by WatcherThread and is a singleton object. This thread is used more frequently in the JVM, such as: regular memory monitoring, JVM health monitoring, and we often need to execute some jstat commands to check the status of gc, as follows:
jstat -gcutil 23483 250 7 This command tells jvm to print the gc condition with PID: 23483 in the console, print once every 250 milliseconds, and print 7 times in total.
VM Thread JVM This thread is more cattle b. It is the thread mother in the jvm. According to the comments in the hotspot source code (vmThread.hpp), it is a singleton object (the most primitive thread) that will generate or trigger all other Thread, this single VM thread will be used by other threads to do some VM operations (such as cleaning garbage, etc.).
         There is a VMOperationQueue queue in the VMThread structure. All VM thread operations (vm_operation) will be saved in this queue. VMThread itself is a thread, and its thread is responsible for executing a self-polling loop function (for details, please refer to: Void VMThread :: loop () in VMThread.cpp, the loop function takes the operation object (VM_Operation) that needs to be executed from the VMOperationQueue queue according to priority, and calls the VM_Operation-> evaluate function to perform the operation of the operation type itself logic.
       ps: The VM operation type is defined in the vm_operations.hpp file, and a few are listed: ThreadStop, ThreadDump, PrintThreads, GenCollectFull, GenCollectFullConcurrent, CMS_Initial_Mark, CMS_Final_Remark .... Interested students can check the source file by themselves.
(Transported from http://blog.csdn.net/a43350860/article/details/8134234 Thanks to the original author)

2. Jmap
2.1 Get the details of memory allocation for running java programs. For example, the number of instances, size, etc.

2.2 Named line format
jmap [option] pid
jmap [option] executable core
jmap [option] [[email protected]] remote-hostname-or-IP

-dump: [live,] format = b, file = <filename> Use hprof binary form to output the heap content of jvm to a file =. The live sub-option is optional, if the live option is specified, then only live objects are output to file.
-finalizerinfo Print information about objects waiting to be recovered.
-heap Print the summary information of heap, the algorithm used by GC, the configuration of heap and the usage of wise heap.
-histo [: live] Print the number of instances of each class, memory usage, class full name information. The prefix of the internal class name of the VM will be prefixed with "*". If the live sub-parameter is added, only the number of live objects will be counted .
-permstat prints the long-term information of classload and jvm heap. Contains the name, liveness, address, parent classloader and the number of loaded classes of each classloader. In addition, the number of internal strings and the number of occupied memory will also be printed.
-F Forced. Use the -dump or -histo parameter when there is no corresponding pid. In this mode, the live subparameter is invalid.
-h | -help print auxiliary information
-J Pass parameters to jvm started by jmap.

2.3 Examples of use
jmap -histo pid (view example)


jmap -dump: format = b, file = heap.bin pid (export memory, it is said to have an impact on performance, use with caution)
(format = b means through binary, but I ca n’t find a text file to export, I know it if I know it)
Dump all the memory structure into a binary file, and the memory structure can be analyzed through IBM's HeapAnalyzer and Eclipse's MemoryAnalyzer.
This is the memory structure of our daily that I checked out with HeapAnalyzer. It has listed possible problems. (I am not familiar with this tool, just for your reference)
The following is the memory structure diagram I use eclipse MemoryAnalyzer to view
The above is analyzed by eclipse analysis memory leak. This feature point is very much. Can learn slowly

3. Jstatce's current capacity
OU: the used size of the old space
P — Perm space area used space percentage
OC: the current capacity of Perm space
OU: used size of Perm space
YGC — The number of times Young GC occurred from application launch to sampling
YGCT – Time (in seconds) Young GC takes from application launch to sampling
FGC — The number of times Full GC occurred from application startup to sampling
FGCT – the time (in seconds) used by Full GC from application launch to sampling
GCT — the total time (in seconds) for garbage collection from application startup to sampling, its value is equal to YGC + FGC
There are many parameters of this tool, it is said that it can basically cover all functions of jprofile and other charging tools. Multi-use is very helpful for system tuning
Note 1: When we use this command daily, we must use the -F parameter. Because none of our users are the ones who initiated the command
Note 2: None of these daily commands seem to be configured in environment variables. This is what I saw in my application machine. Need to execute under the jdk directory. Sudo is of course necessary
jstack (view thread), jmap (view memory), and jstat (performance analysis) commands

3.1 This is a more practical command, you can observe the classloader, compiler, gc related information. Can monitor resources and performance from time to time

3.2 Command format
-class: Statistics on class loader behavior information
-compile: statistical compilation behavior information
-gc: statistics heap information when jdk gc
-gccapacity: statistics of the corresponding heap capacity of different generations (not sure how to translate well, including the new generation area, the elderly area, the permanent area)
-gccause: statistics on the situation of gc, (same as -gcutil) and the events that caused gc
-gcnew: when counting gc, the situation of the new generation
-gcnewcapacity: when counting gc, the new generation heap capacity
-gcold: When counting gc, the situation in the elderly area
-gcoldcapacity: when counting gc, the heap capacity of the elderly area
-gcpermcapacity: When counting gc, the heap capacity in the permanent area
-gcutil: heap statistics when counting gc

3.3 Output parameter content
S0 — Survivor space 0 on Heap
S0C: S0 current capacity
S0U: the used size of S0
S1 — Survivor space 1 on Heap
S1C: the current capacity of S1
S1U: the size that S1 has used
E — The percentage of used space in the Eden space area on Heap
EC: the current capacity of Eden space
EU: used size of Eden space
O — the percentage of used space in the Old space area on Heap
OC: Old spa