Java multithreading: deadlock and java Multithreading
On the weekend, I saw an example of using jstack to view deadlocks. 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 obtain information about java stack and native stack running java programs. You can easily learn the running status of the current thread. As shown in
Note: This is the same result as thread dump. But does thread dump use the kill-3 pid command, or is it better to use fewer kill commands on the server?
1.2 name row format
Jstack [option] pid
Jstack [option] executable core
Jstack [option] [server-id @] remote-hostname-or-IP
Jstack pid is the most common one.
1.3 pay attention to the following statuses in thread dump:
Deadlock and Deadlock (important)
Waiting for resources, Waiting on condition (important)
• Waiting for obtaining the monitor, Waiting on monitor entry (important)
Blocking and Blocked (important)
• Running, Runnable
• Paused, suincluded
• The Object is waiting. The Object. wait () or TIMED_WAITING
• Stop, Parked
The following is a detailed example of this analysis. You can refer to the original article.
Http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html
Description of thread name
The Attach Listener JVM Attach Listener thread is responsible for receiving external commands and executing the commands and returning the results to the sender. We usually use some commands to ask jvm to give us some feedback, such as java-version, jmap, and jstack. If the thread is not initialized when jvm is started, it will be started when the user executes the jvm command for the first time.
Signal DispatcherJVM we mentioned earlier that the responsibility of the first Attach Listener thread is to receive external jvm commands. After the command is successfully received, it will be handed over to the signal dispather thread for distribution to different modules for processing commands, and return the processing result. The signal dispather thread initializes an external jvm command for the first time.
CompilerThread0JVM is used to call JITing and compile and load classes in real time. Generally, the jvm starts multiple threads to process this part of work, and the numbers after the thread name are also accumulated, for example: CompilerThread1
Concurrent Mark-Sweep GC ThreadJVM Concurrent Mark clearing the Garbage Collector (cms gc) thread. This thread is mainly used for garbage collection in the old age. Ps: To enable the Garbage Collector, add-XX: + UseConcMarkSweepGC to the jvm startup parameters.
After the DestroyJavaVMJVM executes main (), the thread calls jni_DestroyJavaVM () in JNI to invoke the DestroyJavaVM thread. After the Jboss server is started, the JVM will invoke the DestroyJavaVM thread and be in the waiting state. When other threads (java thread and native thread) Exit, it will be notified to uninstall the JVM. When the thread exits, it determines whether it is the last non-deamon thread in the entire JVM. If yes, it notifies the DestroyJavaVM thread to uninstall the JVM.
Ps:
Extension:
1. If the thread is not the last non-deamon thread when exiting, call thread-> exit (false) and throw the thread_end event. The jvm does not exit.
2. if the thread determines that it is the last non-deamon thread when exiting, call the before_exit () method and throw two events: Event 1: thread_end thread end event and event 2: VM death event.
Call the thread-> exit (true) method, and then unload the thread from the active list, delete the thread, and so on. After a series of jobs are completed, the waiting DestroyJavaVM thread is notified to execute the JVM uninstall operation.
The ContainerBackgroundProcessor thread JBOSS is a daemon thread. It is initialized when the jboss server is started. The main task is to regularly check whether a Session has expired. If it expires, it is cleared.
Reference: http://liudeh-009.iteye.com/blog/1584876
Dispatcher-Thread-3The thread Log4j Log4j has the function of Asynchronously printing logs. The Appender that needs to print logs asynchronously needs to be registered in the AsyncAppender object. The AsyncAppender monitors the logs and determines when to trigger the log printing operation. AsyncAppender if it monitors that Appender under its jurisdiction has a log printing operation, it generates an event for this Appender and stores the event in a buffer region. The Dispatcher-Thread-3 Thread is responsible for determining whether the event cache zone is full. If it is full, all events in the cache zone are distributed to the Appender container, after the registered Appender receives its own event, it starts to process its own log printing. The Dispatcher-Thread-3 Thread is a daemon Thread.
Finalizer threadThe JVM thread is also created after the main thread, with a priority of 10. It is mainly used to call the finalize () method of the object before garbage collection; several points about the Finalizer thread:
1) The finalize () method is called only when a round of garbage collection is started. Therefore, not all object finalize () methods are executed;
2) This thread is also a daemon thread. Therefore, if there are no other non-daemon threads in the virtual machine, the JVM will exit regardless of whether the thread has completed the finalize () method;
3) During garbage collection, JVM will package the unreferenced objects into Finalizer objects (implementation of Reference) and put them into ReferenceQueue, which will be handled by the Finalizer thread; finally, the reference of the Finalizer object is set to null, which is collected by the garbage collector;
4) Why should the JVM use a single thread to execute the finalize () method? If the JVM garbage collection thread does it by itself, it is likely that the GC thread is stopped or uncontrollable due to misoperations in the finalize () method, which is a disaster for the GC thread;
Gang worker #0 JVMA thread used for the collection of new generation garbage collection (monir gc. # Is followed by the thread number, for example: Gang worker #1
GC Daemon jvm gc DaemonThe thread is used by 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 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 referenced "lease" expires and is not updated, the server recycles the remote objects.
However, now we have added the-XX: + DisableExplicitGC configuration to the jvm startup parameters. Therefore, this thread only contains soy sauce.
IdleRemover JBOSSThe Jboss connection pool has a minimum value. Every time this thread is invoked by Jboss, it is used to check and destroy idle and invalid connections in the connection pool until the remaining connections are less than or equal to its minimum value.
Java2D Disposer JVMThis thread mainly serves various components of awt. Before talking about the main responsibilities of this thread, we need to first introduce what the Disposer class is doing. Disposer provides an addRecord method. If you want to do some aftercare before an object is destroyed, you can call the Disposer # addRecord method to implement the object and a custom DisposerRecord interface, import them together for registration.
The Disposer class will invoke the "Java2D Disposer" thread, which will scan the registered objects for collection. If yes, call the dispose method in the implementation class of the DisposerRecord corresponding to this object.
Disposer is not limited to awt application scenarios, but many components in awt need to access many operating system resources. Therefore, when these components are recycled, they need to be released first.
InsttoolCacheScheduler _
QuartzSchedulerThreadQuartzInsttoolCacheScheduler_QuartzSchedulerThread is the main thread of Quartz. It is mainly responsible for obtaining the trigger to be triggered at the next time point in real time, and then executing the job associated with the trigger.
.The principle is roughly as follows:
When Spring and Quartz are used in combination, the Spring IOC container will create and initialize the Quartz thread pool (TreadPool) during initialization and start it. At the beginning, every thread in the thread pool is in the waiting state, waiting for the outside world to allocate Runnable to it (the thread holding the job object ).
Then initialize and start the Quartz main thread (InsttoolCacheScheduler_QuartzSchedulerThread). After the thread is started, it will be in the waiting state. The run method of the main thread will start to work after the outside world gives a working signal. Run will get the job to be triggered next time in JobStore. After the job is obtained, it will wait until the real trigger time of the job, then, wrap the job into a JobRunShell object (this object implements the Runnable interface, which is actually the Runnable that the above TreadPool is waiting for the outside to allocate to it ), then, the newly created JobRunShell is handed over to the thread pool for job execution.
After the thread pool receives the Runnable, it starts Runnable from a thread in the thread pool and calls the run method in JobRunShell. After the run method is completed, treadPool recycles this thread to the idle thread InsttoolCacheScheduler_Worker-2 Quartz InsttoolCacheScheduler_Worker-2 thread is a simple implementation of ThreadPool thread, it is mainly responsible for allocating thread resources to execute
The scheduling task (JobRunShell) assigned by the InsttoolCacheScheduler_QuartzSchedulerThread to it ).
The main JBossLifeThreadJboss Jboss thread is successfully started. After the application is deployed, the JBossLifeThread thread is instantiated and started. After the JBossLifeThread thread is successfully started, it is waiting to keep the Jboss Java process alive. Why is the Jboss startup process not completed after execution? This is because the thread holds the master. Niu B ~~
JBoss System Threads (1)-1 JbossThis thread is a socket service. The default port number is 1099. It is mainly used to receive external naming service (Jboss JNDI) requests.
JCA PoolFillerJbossThis thread mainly provides connection pool hosting for JBoss. Briefly introduce the working principle:
All classes in Jboss that require remote connection must implement the ManagedConnectionFactory interface. For example
The XAManagedConnectionFactory object implements this interface. Then, the XAManagedConnectionFactory object and other information are packaged into the InternalManagedConnectionPool object, and the InternalManagedConnectionPool is handed over to the queue in the PoolFiller object for management. The JCA PoolFiller thread regularly checks whether an InternalManagedConnectionPool object needs to be created and managed in the queue. If yes, the fillToMin method of the object is called to trigger it to create a remote connection, and maintain the connection to the corresponding connection pool.
JDWP Event Helper ThreadJVM
JDWP is a communication interaction protocol that defines the format of information transmitted between the debugger and the program to be debugged. It defines request commands, response data, and error code in detail, ensuring smooth communication between the frontend and backend JVMTI and JDI. This thread is mainly responsible for ing JDI events into JVMTI signals for JVM operations during debugging.
JDWP Transport Listener: dt_socketJVM: This thread is a listener thread of Java Debugger and is responsible for accepting debug requests from the client. We usually use to set its listening port to 8787.
Low Memory DetectorJVMThis thread is responsible for detecting available memory. If the available memory is found to be low, allocate new memory space.
Process reaperJVMThis thread is responsible for executing an OS command line operation.
Reference HandlerJVMThe JVM creates a Reference Handler thread after the main thread is created. The thread has the highest priority, which is 10. It is mainly used to process the garbage collection problem of the referenced object itself (soft Reference, weak Reference, and virtual Reference ).
