A deadlock is a situation where two or more threads are blocked while waiting to obtain locks that some of the other threads in the deadlock are holding. Deadlocks can occur when multiple threads need the same locks, at the same time, but obtain them in different order. For instance, if thread 1 locks A, and tries to lock B, and thread 2 has already locked B, and tries to lock A, a deadlock arises. Thread 1 can never get B, and thread 2 can never get A. In addition, neither of them will ever know. They will remain blocked on each of their objects, A and B, forever.

Deadlock Detection
The most common way of detecting whether your application is deadlocked is by analyzing thread dumps of the Java Virtual Machine while its in the state of appearing hung. A thread dump is a snapshot of the virtual machine's current state, including stack traces for each Java thread.

The thread dump outputs the state of each thread, which may be one of the following:

• NEW: This state represents a new thread that is not yet started.
• RUNNABLE: This state represents a thread that is executing in the underlying JVM. Here executing in the JVM doesn't mean that the thread is always executing in the OS as well - it may wait for a resource from the operating system like the processor while being in this state.
• BLOCKED: This state represents a thread that has been blocked and is waiting for a moniotor to enter/re-enter a synchronized block/method. A thread gets into this state after calling the Object.wait method.
• WAITING: This state represnts a thread in the waiting state. This wait is over only when some other thread performs some appropriate action. A thread can get into this state either by calling - Object.wait (without timeout), Thread.join (without timeout), or LockSupport.park methods.
• TIMED_WAITING: This state represents a thread that is required to wait at max for a specified time limit. A thread can get into this state by calling any of these methods: Thread.sleep, Object.wait (with timeout specified), Thread.join (with timeout specified), LockSupport.parkNanos, and LockSupport.parkUntil
• TERMINATED: This state reprents a thread that has completed its execution either by returning from the run() method after completing the execution OR by throwing an exception that propagated from the run() method and hence caused the termination of the thread.

A thread that appears as "java.lang.Thread.State: BLOCKED (on object monitor)" in the stacktrace indicates that it's waiting to enter a synchronized block and acquire a Java monitor. Alternatively, the code may call an Object.wait method every time the lock is not acquired, causing the threads to appear as "java.lang.Thread.State: WAITING" in the stacktrace.

A deadlock is detected if a complete circle of such thrads can be seen in the thread dump where two or more threads are blocked/waiting, with each blocked/waiting thread waiting to acquire a lock on an object that has been locked by another blocked/waiting thread.

Example :

"Thread-1" prio=6 tid=0x02a99c00 nid=0xee0 waiting for monitor entr...
java.lang.Thread.State: BLOCKED (on object monitor)
at SimpleDeadLock$Thread2.run(SimpleDeadLock.java:37)
- waiting to lock <0x229bd238> (a java.lang.Object)
- locked <0x229bd240> (a java.lang.Object)

"Thread-0" prio=6 tid=0x02a99000 nid=0xefc waiting for monitor entr...
java.lang.Thread.State: BLOCKED (on object monitor)
at SimpleDeadLock$Thread1.run(SimpleDeadLock.java:24)
- waiting to lock <0x229bd240> (a java.lang.Object)
- locked <0x229bd238> (a java.lang.Object)

In the above thread dump, it can be seen that "Thread-0" and "Thread-1" are in a "BLOCKED" state. "Thread-0" holds a lock on object "0x229bd238" and is waiting to acquire a lock on object "0x229bd240", while at the same time "Thread-1" holds a lock on object "0x229bd240" and is waiting to acquire a lock on object "0x229bd238". Since each of the threads has acquired a lock on an object that the other thread needs in order to complete its operation, they will wait in the same state infinitely, causing the application to hang.

Acquiring Thread Dumps
A thread dump of a running JVM may be taken in various ways, a few of the methods are listed below:

• by sending a SIGQUIT signal to the JVM

kill -3 pid > threadDumpFilename 2>&1

• by using WebLogic scripting tool
  export JAVA_HOME=<java home>
export WL_HOME=<WebLogic home>
cd WL_HOME/server/bin
. ./setWLSEnv.sh
java WebLogic.WLST
connect("username","password","t3://<url>:<port>")
cd ('Servers')
cd ('<server name>')
threadDump()

• by using WebLogic.Admin utility (deprecated)
  export JAVA_HOME=<java home>
export WL_HOME=<WebLogic home>
cd WL_HOME/server/bin
. ./setWLSEnv.sh

java WebLogic.Admin <url>:<port> -username <username> -password <password> THREAD_DUMP



• by using WebLogic admin console

Login to AdminConsole->Server -> Monitoring -> Threads

• by using Jrockit command line utility (Jrockit JVM)
  export JAVA_HOME=<java home>
export WL_HOME=<WebLogic home>
cd WL_HOME/server/bin
. ./ setWLSEnv.sh

jrcmd <pid> print_threads

· by using the Jstack utility (HotSpot JVM)
export JAVA_HOME=<java home>
export WL_HOME=<WebLogic home>
cd WL_HOME/server/bin
. ./setWLSEnv.sh

jstack <pid>