Java Jstack Dump Thread Introduction explanation

The recent pumping time to organize some of the threads that are generated during the JVM's operation is mainly based on the files generated by our system jstack.  Some time ago because of system code problems, resulting in performance to the ceiling, so dump a stack out for analysis.  See stack actually also need certain experience, after all, it inside many threads can't all have problem, so, need to have certain understanding to them. Now there are few people on the market to do this piece of tidying up, so, many newcomers to get a stack file, but also confused. Below I put together some of the personal thought of the more important threads listed, for your reference. If you find something that is wrong or can be supplemented, ask your friends to fill it with a willingness to share.

Thread Name	Belongs	Explanatory notes
Attach Listener	Jvm	The Attach Listener thread is responsible for receiving external commands and executing the command and returning the result to the sender. Usually we use some commands to ask the JVM to give us some feedback, such as Java-version, Jmap, Jstack, and so on. If the thread is not initialized when the JVM is started, it will be started when the user first executes the JVM command.
Signal Dispatcher	Jvm	Earlier we mentioned that the first attach listener thread is responsible for receiving external JVM commands, and when the command is received successfully, it is handed to the signal Dispather thread to distribute the commands to various modules and return the processing results. The signal Dispather thread is also initialized when the external JVM command is received for the first time.
CompilerThread0	Jvm	Used to invoke jiting to compile the loading class in real time. Typically, the JVM initiates multiple threads to handle this part of the work, and the number following the name of the thread is incremented, for example: CompilerThread1
concurrent mark-sweep GC Thread	JVM	concurrency tag clears the garbage collector (which is usually referred to as the CMS GC) thread, which is primarily intended for garbage collection in the old age. PS: Enable the garbage collector, you need to add:-xx:+useconcmarksweepgc  in the JVM startup parameters;
DESTROYJAVAVM	JVM	ps: 1. If the thread exits with the judgment that it is not the last non-Deamon thread, call thread- >exit (False), and in which the Thread_end event is thrown, the JVM does not exit. 2. If the thread exits when judging itself as the last non-Deamon thread, then call the Before_exit () method, throw two events:  event 1:thread_end thread End event, Event 2:VM the death event.     then calls the Thread->exit (True) method, then removes the thread from the active list, deletes the thread, and so on, after a series of work execution finishes, The DESTROYJAVAVM thread that is waiting is notified to perform an unload JVM operation.
Containerbackgroundprocessor Threads	Jboss	It is a daemon thread that initializes the JBoss server when it is started, and the main task is to check that the session expires. Expired. Reference: http://liudeh-009.iteye.com/blog/1584876
Dispatcher-thread-3 Threads	Log4j	Log4j has the function of the asynchronous print log, the appender that need to print the log asynchronously need to register to Asyncappender object, by the Asyncappender to listen, decide when to trigger the log printing operation.  Asyncappender If the supervisor hears that appender in its jurisdiction has a print log operation, it generates a corresponding event for the Appender and saves the event in a Buffuer region. The dispatcher-thread-3 thread is responsible for determining whether the event buffer is full, and if it is full, distribute all the event in the buffer to the Appender container, and those registered Appender receive their event, You start to process your own log printing work. The dispatcher-thread-3 thread is a daemon thread.
Finalizer Threads	Jvm	This thread is also created after the main thread, with a priority of 10, which is primarily used to call the Finalize () method of the object before garbage collection; about Finalizer threads: 1) The Finalize () method is only started when a round of garbage collection is started, so not all of the object's Finalize () methods will be executed; 2) This thread is also a daemon thread, so the JVM exits if there are no other non-daemon threads in the virtual machine, whether or not the thread has completed the Finalize () method; 3) at garbage collection, the JVM wraps the object that is lost as a finalizer object (the implementation of the reference) and puts it in Referencequeue, which is handled by the finalizer thread, and finally the reference to the finalizer object is set to null. Collected by the garbage collector; 4) Why does the JVM have to use a single thread to execute the Finalize () method? If the JVM's garbage collection thread is doing it itself, it is likely that the GC thread will be stopped or not controlled due to a mistake in the Finalize () method, which is a disaster for GC threads;
Gang worker#0	Jvm	A thread used by the JVM to do a generation of garbage collection (Monir GC). #号后面是线程编号, for example: Gang worker#1
GC Daemon	Jvm	GC Daemon threads are used by the JVM to provide remote distributed GC for RMI, and the GC Daemon thread will actively invoke the System.GC () method to perform full GC on the server. The 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 remote objects on the client, or if the reference "lease" expires and there is no update, the server will garbage reclaim the remote object. However, we now have the-XX:+DISABLEEXPLICITGC configuration on the JVM boot parameters, so this thread is only soy sauce.
Idleremover	Jboss	The JBoss connection pool has a minimum value, which is awakened by JBoss every once in a while to check and destroy idle and invalid connections in the connection pool until the remaining number of connections is less than or equal to its minimum value.
java2d disposer	Jvm	This thread mainly serves the various components of AWT. Before talking about the main job responsibilities of this thread, we need to introduce the Disposer class. Disposer provides a AddRecord method. If you want to do some cleanup before an object is destroyed, you can call the Disposer#addrecord method, pass the object and a custom Disposerrecord interface implementation class, and enter it to register. The Disposer class invokes the "java2d disposer" thread, which scans the registered objects for recycling and, if so, calls the Dispose method within the Disposerrecord implementation class for that object. Disposer is actually not limited to the AWT application scenario, but many of the components in AWT need access to many operating system resources, so these components need to be released before they are recycled.
Insttoolcachescheduler_quartzschedulerthread	Quartz	insttoolcachescheduler_ Quartzschedulerthread is the main thread of quartz, which is responsible for getting the trigger to be triggered at the next point in time, and then executing the trigger-associated job.   the          principle is as follows:   The quartz thread pool (treadpool) is created and initialized when the Spring IOC container is initialized with the         spring and quartz scenarios. and start it. Each thread in the thread pool is waiting when it starts, waiting for the outside world to assign runnable (the thread holding the Job object).          The quartz's main thread (insttoolcachescheduler_quartzschedulerthread) is then initialized and started, and the thread is in a wait state since it was started. After waiting for the signal to be given to the outside world, the Run method of the main thread actually begins to work. Run will get jobstore the next job to be triggered, will wait until the job's true trigger time, and then wrap the job as a Jobrunshell object (the object implements the Runnable interface, In fact, it is the top treadpool waiting for the outside assigned to his runnable), and then the newly created Jobrunshell to the thread pool, the thread pool is responsible for the execution of the job.
Insttoolcachescheduler_worker-2	Quartz	The insttoolcachescheduler_worker-2 thread is a simple implementation of the threadpool thread, which is primarily responsible for allocating thread resources to execute The Insttoolcachescheduler_quartzschedulerthread thread gives it the dispatch task (that is, Jobrunshell).
Jbosslifethread	Jboss	The JBoss main thread starts successfully, the Jbosslifethread thread is instantiated after the application is deployed, and the start,jbosslifethread thread is waiting after it is successfully started to keep the JBoss Java process alive. The more popular point is that after the JBoss startup process has been executed, why is it not over? It is because there is this thread that hold the master. Cow B Bar ~ ~
JBoss System Threads (1)-1	Jboss	The thread is a socket service with the default port number: 1099. Primarily used to receive external naming service (Jboss JNDI) requests.
jca poolfiller	jboss	this thread is primarily hosting a connection pool for JBoss internal.   A brief introduction to how it works:     JBoss internally, all classes that have remote connection requirements need to implement the Managedconnectionfactory interface, For example, the xamanagedconnectionfactory object that needs to be a JDBC connection implements the interface. It then wraps the Xamanagedconnectionfactory object, along with other information, into the Internalmanagedconnectionpool object, The Internalmanagedconnectionpool is then handed over to the queue within the Poolfiller object for management.    JCA Poolfiller Threads periodically determine if there is a Internalmanagedconnectionpool object in the queue that needs to be created and managed, and if so, call the Filltomin method of that object. Trigger it to create the appropriate remote connection and maintain the connection to its corresponding connection pool.
JDWP Event Helper Thread	Jvm	JDWP is a communication interaction protocol that defines the format in which information is passed between the debugger and the program being debugged.  It defines the request command, the response data and the error code in detail, ensuring that the JVMTI and JDI of the front and back end are communicated smoothly. The thread is primarily responsible for mapping the JDI event into a JVMTI signal for the purpose of manipulating the JVM during debugging.
JDWP Transport Listener:dt_socket	Jvm	This thread is a Java Debugger listener thread responsible for handling the client's debug requests. Usually we are accustomed to setting its listening port to 8787.
Low Memory Detector	Jvm	This thread is responsible for detecting the memory that can be used and allocating new memory space if the available memory is found to be low.
Process Reaper	Jvm	The 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, with the highest precedence of 10, which is primarily used to handle garbage collection issues that refer to the object itself (soft, weak, and virtual).
Surrogate Locker Thread (CMS)	Jvm	This thread is primarily used in conjunction with the CMS garbage collector, which is a daemon thread that is primarily responsible for handling GC processes where the Java layer's reference (referred to as soft references, weak references, and so on) is synchronized with the state of the object at the internal level of the JVM. Here's a little introduction to their implementation: Here's an example of Weakhashmap, with some key points listed first (we'll all string together these key points later): 1. We know that HashMap uses entry[] arrays to store data, Weakhashmap is no exception, and there is a entry[] array inside. 2. The entry of Weakhashmap is very special, 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. Reference has a static variable: pending. 5. Reference has a static inner class: The Referencehandler thread, which is initialized and started in the static block, waits in the wait state after the boot is complete, waiting in a lock synchronization lock module. 6. In addition, Weakhashmap inside also instantiated a referencequeue queue, the role of this queue, will be mentioned later. 7. The above key points are complete, and we'll string them up below.      assumes that a reference to many objects has been saved inside the Weakhashmap object. When the JVM is doing a CMS GC, it creates a concurrentmarksweepthread (CMST) thread to perform the GC, The Concurrentmarksweepthread thread is created at the same time that it creates a surrogatelockerthread (abbreviated SLT) thread and starts it, after SLT is started, in the wait phase. When Cmst starts the GC, a message is sent to SLT to get the global lock for the Java Layer Reference object: lock. Until the CMS GC is complete, the JVM will place the WeakReference container object belonging to all the reclaimed objects in Weakhashmap into the pending attribute of reference (after each GC is complete, The pending property is essentially not null), and then notifies SLT to release and notify the global lock: lock. At this point, the Run method of the Referencehandler thread is activated, leaving it out of the wait state and starting to work. Referencehandler This thread will move all WeakReference objects in the pending into their respective queues, such as the current weakreference belongs to a Weakhashmap object, Then it will be put into the corresponding Referencequeue queue (the queue is the list structure). The next time we get from the Weakhashmap object, put data, or call the size method, Weakhashmap will referencequeue in the queue WeakReference poll out and entry[] Data is compared, if found the same, it means that the entry saved objects have been GC off, then entry[] within the entry object removed.
Taskobjecttimerfactory	Jvm	As the name implies, this thread is used to perform the task. When we put a thought to the timer object and tell it the execution time, cycle time, the timer will put the task into the task queue, and notify the taskobjecttimerfactory thread to handle the task, The taskobjecttimerfactory thread removes a task that has a status of canceled from the task queue, and if the task is a non-repeating type of execution, it is removed from the task queue after the task has been executed, and if the task needs to be repeated, it calculates the point in time for the next execution.
VM periodic Task Thread	Jvm	This thread is a thread that is scheduled by the JVM's recurring task, which is created by Watcherthread and is a singleton object. This thread is used more frequently within the JVM, such as periodic memory monitoring, JVM health monitoring, and we often need to execute some JSTAT commands to view the GC, as follows: Jstat-gcutil 23483 250 7 This command tells the JVM to print the PID at the console: 23483 for the GC case, which is printed at intervals of 250 milliseconds and printed 7 times altogether.
VM Thread	Jvm	This thread compares cow B, which is the thread matrix inside the JVM, According to the note in the Hotspot source code (VMTHREAD.HPP), it is a singleton object (the most primitive thread) that produces or triggers all other threads, and this single VM thread is used by other threads to do some VM operations (such as cleaning up garbage, etc.). In the Vmthread structure there is a vmoperationqueue queue, all VM threading Operations (vm_operation) are saved in this queue, vmthread itself is a thread, its thread is responsible for executing a self-polling loop function ( Refer to: VMThread.cpp void Vmthread::loop ()), the loop function takes precedence from the Vmoperationqueue queue to take out the Action object (vm_operation) that is currently required, and calls the VM The _operation->evaluate function executes the business logic of the operation type itself. The PS:VM operation type is defined in the Vm_operations.hpp file and is listed in several ways: Threadstop, Threaddump, Printthreads, Gencollectfull, Gencollectfullconcurrent, Cms_initial_mark, Cms_final_remark ..... Interested students, you can go to view the source files.

There are some threads, and next time you have a second.

http://blog.csdn.net/a43350860/article/details/8134234

Java Jstack Dump Thread Introduction explanation