Shulou(Shulou.com)06/02 Report--

This article mainly explains the "thread dump thread state and thread definition is what", the article explains the content is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in-depth, together to study and learn "thread dump thread state and thread definition is what" it!

I saw an example of using jstack to view deadlocks over the weekend. Last night I summarized the jstack (View Thread), jmap (View memory), and jstat (performance Analysis) commands. For your reference

1.Jstack

1.1 jstack can get information about java stack and native stack running java programs. You can easily know how the current thread is running. As shown in the following figure

Note: this is the same result as thread dump. But should thread dump use the kill-3 pid command, or use less kill on the server?

1.2 named line format

Jstack [option] pid

Jstack [option] executable core

Jstack [option] [server-id@] remote-hostname-or-IP

The most commonly used one is jstack pid.

1.3 in thread dump, pay attention to the following states

Deadlock, Deadlock (focus)

Wait for resources, Waiting on condition (focus)

Waiting to get the monitor, Waiting on monitor entry (focus)

Blocking, Blocked (focus)

In progress, Runnable

Pause, Suspended

Object waiting, Object.wait () or TIMED_WAITING

Stop, Parked

Here is a detailed example of this kind of analysis. Please refer to the original work.

Http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html

1.4 in thread dump, several threads are defined as follows

Explanation of the name of the thread

The Attach Listener JVM Attach Listener thread is responsible for receiving the external command, executing the command and returning the result to the sender. Usually we use some commands to ask jvm to give us some feedback, such as: java-version, jmap, jstack and so on. If the thread is not initialized when jvm starts, it will be started the first time the user executes the jvm command.

Signal Dispatcher JVM We mentioned earlier that the responsibility of the first Attach Listener thread is to receive external jvm commands. When the command is received successfully, 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 when it first receives an external jvm command.

CompilerThread0 JVM is used to call JITing to compile and load and unload class in real time. Typically, jvm starts multiple threads to handle this part of the work, and the numbers after the thread name are added, for example: CompilerThread1

The Concurrent Mark-Sweep GC Thread JVM concurrent tag clears the garbage collector (commonly known as CMS GC) thread, which is mainly targeted at old-fashioned garbage collection. Ps: to enable the garbage collector, you need to add:-XX:+UseConcMarkSweepGC to the jvm startup parameters

The thread that DestroyJavaVM JVM executes main () invokes the jni_DestroyJavaVM () method in JNI after the main has finished executing to evoke the DestroyJavaVM thread. After the Jboss server starts, JVM calls up the DestroyJavaVM thread, waits, and tells it to uninstall JVM when other threads (java and Native) exit. When a thread exits, it determines whether it is currently the last non-deamon thread in the entire JVM, and if so, tells the DestroyJavaVM thread to uninstall the JVM.

Ps:

Expand a little bit:

1. If the thread determines that it is not the last non-deamon thread when exiting, then call thread- > exit (false) and throw a thread_end event in it, and jvm does not exit.

two。 If the thread exits and determines that it is the last non-deamon thread, call the before_exit () method and throw two events: the event 1:thread_end thread end event and the event 2:VM 's death event.

Then call the thread- > exit (true) method, and then notify the waiting DestroyJavaVM thread to uninstall the JVM when a series of tasks such as removing the thread from the active list, deleting the thread, and so on are completed.

ContainerBackgroundProcessor thread JBOSS it is a daemon thread, initialized when the jboss server is started, the main job is to check periodically whether there is any Session expiration. Clear if it expires.

Reference: http://liudeh-009.iteye.com/blog/1584876

Dispatcher-Thread-3 thread Log4j Log4j has the function of printing logs asynchronously. Appender that needs to print logs asynchronously needs to register in the AsyncAppender object, and AsyncAppender listens to decide when to trigger log printing. If AsyncAppender detects that the Appender under its jurisdiction has the operation of printing logs, it generates a corresponding event for the Appender and saves the event in a buffuer area. The Dispatcher-Thread-3 thread is responsible for determining whether the event cache is full. If it is, it distributes all the event in the cache to the Appender container. After those registered Appender receive their own event, they start to process their own log printing work. The Dispatcher-Thread-3 thread is a daemon thread.

The Finalizer thread JVM, which is also created after the mainthread, has a priority of 10 and is mainly used to call the object's finalize () method before garbage collection; a few points about Finalizer threads:

1) the finalize () method is called only when a round of garbage collection is started; therefore, not all objects' finalize () methods are executed.

2) the thread is also a daemon thread, so if there are no other non-finalize threads in the virtual machine, JVM will exit regardless of whether the thread has finished executing the daemon () method or not

3) during garbage collection, JVM wraps the objects that have lost references into Finalizer objects (the implementation of Reference) and puts them into ReferenceQueue, which are processed by the Finalizer thread. Finally, the reference of the Finalizer object is set to null, which is collected by the garbage collector.

4) Why would JVM use a single thread to execute the finalize () method? If the garbage collection thread of JVM does it by itself, it is very likely that the GC thread will stop or become 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 new generation garbage collection (monir gc). # is followed by a thread number, for example: Gang worker#1

The GC Daemon JVM GC Daemon thread is used by JVM to provide remote distributed GC for RMI. The System.gc () method is actively called in the GC Daemon thread to Full GC the server. The original intention is that when the RMI server returns an object to its client (the caller of the remote method), it tracks 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 referenced "lease" expires and is not updated, the server will garbage collect the remote object.

However, we now have the-XX:+DisableExplicitGC configuration added to the jvm startup parameters, so this thread is just a piece of cake.

The IdleRemover JBOSS Jboss connection pool has a minimum value, and the thread is evoked by Jboss every once in a while 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 the awt. Before we talk about the main job responsibilities of this thread, we need to talk about what the Disposer class does. Disposer provides an addRecord method. If you want to do some clean-up work before an object is destroyed, you can call the Disposer#addRecord method to pass in the object and a custom DisposerRecord interface implementation class to register.

The Disposer class calls the "Java2D Disposer" thread, which scans the registered objects for collection, and if so, calls the dispose method in the corresponding DisposerRecord implementation class for the object.

In fact, Disposer is not limited to awt application scenarios, but many components in awt need to access a lot of operating system resources, so when these components are reclaimed, they need to be released first.

InsttoolCacheScheduler_

QuartzSchedulerThread Quartz InsttoolCacheScheduler_QuartzSchedulerThread is the main thread of Quartz, which is mainly responsible for real-time obtaining the trigger to be triggered at the next point in time, and then executing the job associated with the trigger.

The principle is roughly as follows:

In a scenario where Spring and Quartz are used together, the Spring IOC container initializes and creates a Quartz thread pool (TreadPool) and starts it. At startup, each thread in the thread pool is waiting, waiting for the outside world to assign him a Runnable (the thread that holds the job object).

The main thread (InsttoolCacheScheduler_QuartzSchedulerThread) of the Quartz is then initialized and started, which will be in a waiting state since startup. After waiting for a work signal from the outside world, the run method of the main thread actually starts to work. Run will get the next job to be triggered in JobStore, wait until the actual trigger time of the job, and then package the job into a JobRunShell object (which implements the Runnable interface, which is actually waiting for the Runnable assigned by the outside world in the above TreadPool), and then gives the newly created JobRunShell to the thread pool, which is responsible for executing the job.

After receiving the Runnable in the thread pool, a thread in the thread pool starts the Runnable and reflects the call to the run method in the JobRunShell. After the execution of the run method is completed, the TreadPool reclaims 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

The scheduling task (that is, JobRunShell) assigned to it by the InsttoolCacheScheduler_QuartzSchedulerThread thread.

The JBossLifeThread Jboss Jboss main thread starts successfully, and after the application is deployed, the JBossLifeThread thread is instantiated, and after the start,JBossLifeThread thread starts successfully, it waits to keep the Jboss Java process alive. The result is a bit more common, that is, after the Jboss startup process is completed, why is it not finished? It is because of this thread that hold hosts it. Cow bar ~ ~

JBoss System Threads (1)-1 Jboss this thread is a socket service and the default port number is: 1099. It is mainly used to receive external naming service (Jboss JNDI) requests.

JCA PoolFiller Jboss this thread mainly provides hosting for connection pooling within the JBoss. A brief introduction to how it works:

All classes within Jboss that need to connect remotely need to implement ManagedConnectionFactory interfaces, such as those that need to be connected with JDBC

XAManagedConnectionFactory object, the interface is implemented. Then wrap the XAManagedConnectionFactory object and other information into the InternalManagedConnectionPool object, and then give the InternalManagedConnectionPool to the queue in the PoolFiller object for management. The JCA PoolFiller thread periodically determines whether there are InternalManagedConnectionPool objects in the queue that need to be created and managed, and if so, calls the object's fillToMin method, triggers it to create the corresponding remote connection, and maintains the connection in its corresponding connection pool.

JDWP Event Helper Thread JVM

JDWP is a communication and interaction protocol that defines the format of information transferred between the debugger and the program being debugged. It defines request command, response data and error code in detail, which ensures smooth communication between front-end and back-end JVMTI and JDI. This thread is mainly responsible for mapping JDI events to JVMTI signals to achieve the purpose of operating JVM during debugging.

JDWP Transport Listener: dt_socket JVM this thread is a Java Debugger listener thread that accepts debug requests from the client. Usually we are used to setting its listening port to 8787.

The thread Low Memory Detector JVM is responsible for detecting available memory and allocating new memory space if it is found to be low.

Process reaper JVM this thread is responsible for performing an OS command line operation.

After Reference Handler JVM JVM creates the main thread, it creates the Reference Handler thread with the highest priority of 10, which is mainly used to deal with garbage collection of the reference object itself (soft reference, weak reference, virtual reference).

Surrogate Locker Thread (CMS) JVM, which is mainly used with CMS garbage collector, is a daemon thread, which is mainly responsible for synchronizing the Reference (soft reference, weak reference, etc.) of the Java layer with the object state at the internal level of jvm during the GC process. Here's a little introduction to their implementation: take WeakHashMap as an example to list some key points first (we'll string them all together later):

1. We know that HashMap uses an Entry [] array to store data, and WeakHashMap is no exception. There is an internal Entry [] array.

2. WeakHashMap's Entry is special, and its inheritance architecture is Entry- > WeakReference- > Reference.

3. Reference has a global lock object: Lock, which is also known as pending_lock. Note: it is a static object.

4. There is a static variable in Reference: pending.

5. There is a static inner class in Reference: the thread of ReferenceHandler, which is initialized and started in the static block. After startup, it is in the wait state, and it waits in a Lock synchronization lock module.

6. In addition, a ReferenceQueue queue is instantiated in WeakHashMap, and the role of this queue will be mentioned later.

7. This is the end of the above key points, let's string them together.

Suppose that many references to objects are already stored in the WeakHashMap object. When JVM carries out CMS GC, it will create a ConcurrentMarkSweepThread (CMST) thread to create a GC,ConcurrentMarkSweepThread thread and start it. After SLT starts, it is in the waiting phase. When CMST starts GC, it sends a message to SLT to acquire the global lock of the Java layer Reference object: Lock. Until the CMS GC is complete, JVM places the WeakReference container objects to which all the recycled objects in the WeakHashMap belong to the pending property of the Reference (after each GC, the pending property is basically not null), and then notifies SLT to release and the notify global lock: Lock. At this point, the run method of the ReferenceHandler thread is activated to get it out of the wait state and get to work. The thread ReferenceHandler will move all WeakReference objects in the pending to their respective queues. For example, if the current WeakReference belongs to a WeakHashMap object, it will be placed in the corresponding ReferenceQueue queue (the queue is a linked list structure). The next time we get or put data from the WeakHashMap object or call the size method, WeakHashMap will compare the WeakReference in the ReferenceQueue queue according to poll with the Entry [] data. If it is the same, it means that the object saved by this Entry has been dropped by GC, so remove the Entry object in the Entry [].

TaskObjectTimerFactory JVM as its name implies, this thread is used to perform tasks. When we give a task to the Timer object and tell it the execution time and cycle time, Timer will queue the task and notify the taskObjectTimerFactory thread to process the task. The taskObjectTimerFactory thread will remove the task with a canceled status from the task queue. If the task is of a non-repeating type, remove it from the task queue after it is executed, if the task needs to be repeated The point in time for its next execution is calculated.

VM Periodic Task Thread JVM this thread is the periodic task scheduling thread of JVM, which is created by WatcherThread and is a singleton object. This thread is frequently used in JVM, such as regular memory monitoring, JVM health monitoring, and we often need to execute some commands such as jstat to check gc, as follows:

The command jstat-gcutil 23483 2507 tells jvm to print a gc with a PID of 23483 on the console, once at intervals of 250ms for a total of seven times.

VM Thread JVM this thread is more awesome b, is the thread matrix in jvm, according to the comments in the hotspot source code (vmThread.hpp), it is a singleton object (the most original thread) will generate or trigger all other threads, this single VM thread will be used by other threads to do some VM operations (such as garbage cleaning, etc.).

There is a VMOperationQueue queue in the structure of VMThread, and all VM thread operations (vm_operation) are saved in this queue. VMThread itself is a thread, and its thread is responsible for executing a self-polled loop function (see void VMThread::loop () in VMThread.cpp). The loop function fetches the current operation objects (VM_Operation) from the VMOperationQueue queue according to priority. And call the VM_Operation- > evaluate function to execute the business logic of the operation type itself.

Ps:VM operation types are defined in the vm_operations.hpp file, enumerating several: ThreadStop, ThreadDump, PrintThreads, GenCollectFull, GenCollectFullConcurrent, CMS_Initial_Mark, CMS_Final_Remark... .. Students who are interested can check the source files by themselves.

(transported from http://blog.csdn.net/a43350860/article/details/8134234 thanks to the original author)

2.Jmap

2.1get the details of the memory allocation for running the java program. For example, the number of instances, size, etc.

2.2 named line format

Jmap [option] pid

Jmap [option] executable core

Jmap [option] [server-id@] remote-hostname-or-IP

-dump: [live,] format=b,file= uses hprof binary form to output the heap content of jvm to file =. The live suboption is optional. If you specify the live option, only live objects are output to the file.

-finalizerinfo prints information about objects waiting to be reclaimed.

Heap prints the summary information of heap, the algorithm used by GC, the configuration of heap and the use of wise heap.

-histo [: live] prints the number of instances, memory usage, and class full name information for each class. The inner class name of VM begins with the prefix "*". If the live sub-parameter is added, only the number of live objects is counted.

-permstat prints information about classload and jvm heap persistent layers. Contains the name, liveliness, address, parent classloader and number of class loaded for each classloader. In addition, the number of internal String and the amount of memory will also be printed out.

-F compulsion. Use the-dump or-histo parameter when there is no corresponding pid. In this mode, the live child parameter is invalid.

-h |-help print auxiliary information

-J passes parameters to the jvm started by jmap.

2.3 use examples

Jmap-histo pid (view instance)

Here is how I use eclipse's MemoryAnalyzer to view the memory structure diagram.

Example 2 (5 consecutive times)

This tool has so many parameters that it is said to basically cover all the functions of charging tools such as jprofile. Multi-use is very helpful for system tuning.

Note 1: when we use such a command in daily, we always use the-F parameter. Because none of our users are users who start the command.

Note none of the commands in 2:daily seem to be configured in the environment variables, which I saw in my own application machine. It needs to be executed under the jdk directory. Of course, Sudo is a must.

Thank you for your reading, the above is the "thread dump thread state and thread definition is what" the content, after the study of this article, I believe you have a deeper understanding of the thread dump thread state and thread definition of this problem, the specific use of the need for practice to verify. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.