Running inside the JVM

Hi,all

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 bottlenecks, so dump a stack out for analysis.  There are a lot of threads in the stack, which requires some experience to troubleshoot, so you have some knowledge of them and can improve the efficiency of troubleshooting. Now the online information is not particularly full, so that many new people in the possession of a stack file, do not know where to look. Below I have put together some of the most common threads that I think are more commonly listed.

Thread	Belongs	Description
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
Concurrentmark-sweepgcthread	Jvm	The concurrency token 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: To enable the garbage collector, you need to add the following JVM startup parameters:-XX:+USECONCMARKSWEEPGC
Destroyjavavm	Jvm	The thread executing main () calls the JNI_DESTROYJAVAVM () method in Jni to invoke the DESTROYJAVAVM thread after main finishes executing. After the JBoss server is started, the JVM evokes the DESTROYJAVAVM thread, waits, waits for other threads (Java threads and native threads) to notify it to unload the JVM when it exits. When a thread exits, it will determine whether it is currently the last non-deamon thread in the entire JVM, and if so, notifies the DESTROYJAVAVM thread to unload the JVM. PS: Extension: 1. If the thread exits with the judgment that it is not the last non-Deamon thread, call Thread->exit (false) and throw the Thread_end event in it, and the JVM does not exit. 2. If the thread exits with the last non-Deamon thread, call the Before_exit () method and throw two events: Event 1:thread_end thread End event, event 2:VM death event. Then call the Thread->exit (True) method, then remove the thread from the active list, remove the thread, and so on, and then notify the waiting DESTROYJAVAVM thread to perform the unload JVM operation.
Containerbackground Processor	Jboss	It is a daemon thread that initializes the JBoss server when it is started, and the main task is to check periodically for any session expiration. Expired. Reference: http://liudeh-009.iteye.com/blog/1584876
Configclientnotifier	Configserver	Configserver server When there is a configuration change, the latest configuration is pushed to a data queue in the Configserver client, Configclientnotifier thread is used to periodically check if there is data in the data queue, and if there is data, The data is distributed to the components subscribing to the data to do business logic, such as: Tair and HSF data are subscribed to the Configserver data source, when the Configclientnotifier thread discovery data is updated, it triggers the data Distribute data to the appropriate subscribers by sending specific signal identifiers.
Configclientworker-default	Configserver	This includes proactively sending data to the server (primarily data that is subscribed and published) and the data that the receiving server pushes (primarily the value of the subscription data).
Dispatcher-thread-3	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, and is primarily used to call the Finalize () method of the object before garbage collection; about Finalizer threads: 1) Call the Finalize () method only when you start a garbage collection , so not all object's Finalize () methods are executed; 2) The thread is also a daemon thread, so if there are no other non-daemon threads in the virtual machine, the JVM exits, regardless of whether or not the Finalize () method is executed by the thread; 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 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.
Felixdispatchqueue	Sofa	The thread will invoke the thread at sofa startup, which is used to distribute the OSGi event into declarative services to publish, locate, bind to the target service.   In fact, the service and reference of our interface configuration involve the work of publishing, finding and binding services. The main job of declarative services is to easily monitor and manage the dependencies and status of the service. OSGi uses the event policy to invoke services in declarative services.
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: In a scenario where spring and quartz are used together, the spring IOC container is initialized to create and initialize the quartz thread pool (treadpool) 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. After the thread pool receives the Runnable, a thread from the thread pools starts Runnable, reflection calls the Run method in Jobrunshell, and after the Run method executes, Treadpool recycles the thread to the idle thread.
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 Insttoolcachescheduler_ The Quartzschedulerthread thread gives it the dispatch task (that is, Jobrunshell).
Java.util.concurrent. Threadpoolexecutor$worker	Jvm
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 internal classes that have remote connection requirements need to implement the Managedconnectionfactory interface, such as the Xamanagedconnectionfactory object that needs to do a JDBC connection, to implement the interface. It then wraps the Xamanagedconnectionfactory object, along with other information, into the Internalmanagedconnectionpool object, and then   Internalmanagedconnectionpool to the Poolfiller object inside the queue to manage. The JCA Poolfiller thread periodically determines whether there are Internalmanagedconnectionpool objects in the queue that need to be created and managed, and if so, invokes the Filltomin method of the object, triggering 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 Transportlistener: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 Memorydetector	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).
Surrogatelockerthread (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.      Suppose 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 placed in the corresponding Referencequeue queue (the queue is a linked 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 give a task to the timer object and tell it the execution 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 regular 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 in the console at 23483 for the GC case, which is printed 250 milliseconds at a time and prints 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), which is a singleton object (the most primitive thread) that produces or triggers all other threads, 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.

If a classmate found that there is something wrong or not all the place, but also trouble message to add a correction, thank you (^_^).

Because Java threads are still more, there is time to continue to organize, interested students can also go to do further in-depth understanding.

Running inside the JVM