IBM User Guide for Java V7 on Windows > Troubleshooting and support > Using diagnostic tools > Using Javadump > Interpreting a Javadump > Threads and stack trace (THREADS)
Blocked thread information
For threads that are in parked, waiting, or blocked states, the Javadump THREADS section contains information about the resource that the thread is waiting for. The information might also include the thread that currently owns that resource. Use this information to solve problems with blocked threads.
Information about the state of a thread can be found in the THREADS section of the Javadump output. Look for the line that begins with 3XMTHREADINFO. The following states apply:
To find out which resource is holding the thread in parked, waiting, or blocked state, look for the line that begins 3XMTHREADBLOCK. This line might also indicate which thread owns that resource.
- state:P
- Parked threads
- state:B
- Blocked threads
- state:CW
- Waiting threads
The 3XMTHREADBLOCK section is not produced for threads that are blocked or waiting on a JVM System Monitor, or threads that are in Thread.sleep().
Threads enter the parked state through the java.util.concurrent API. Threads enter the blocked state through the Java™ synchronization operations.
The locks that are used by blocked and waiting threads are shown in the LOCKS section of the Javadump output, along with the thread that is owning the resource and causing the block. Locks that are being waited on might not have an owner. The waiting thread remains in waiting state until it is notified, or until the timeout expires. Where a thread is waiting on an unowned lock the lock is shown as Owned by: <unowned>.
Parked threads are listed as parked on the blocker object that was passed to the underlying java.util.concurrent.locks.LockSupport.park() method, if such an object was supplied. If a blocker object was not supplied, threads are listed as Parked on: <unknown>.
If the object that was passed to the park() method extends the java.util.concurrent.locks.AbstractOwnableSynchronizer class, and uses the methods of that class to keep track of the owning thread, then information about the owning thread is shown. If the object does not use the AbstractOwnableSynchronizer class, the owning thread is listed as <unknown>. The AbstractOwnableSynchronizer class is used to provide diagnostic data, and is extended by other classes in the java.util.concurrent.locks package. If you develop custom locking code with the java.util.concurrent package then you can extend and use the AbstractOwnableSynchronizer class to provide information in Java dumps to help you diagnose problems with your locking code.
Example: a blocked thread
The following sample output from the THREADS section of a Javadump shows a thread, Thread-5, that is in the blocked state, state:B. The thread is waiting for the resource java/lang/String@0x4D8C90F8, which is currently owned by thread main.
3XMTHREADINFO "Thread-5" J9VMThread:0x4F6E4100, j9thread_t:0x501C0A28, java/lang/Thread:0x4D8C9520, state:B, prio=5 3XMTHREADINFO1 (native thread ID:0x664, native priority:0x5, native policy:UNKNOWN) 3XMTHREADBLOCK Blocked on: java/lang/String@0x4D8C90F8 Owned by: "main" (J9VMThread:0x00129100, java/ lang/Thread:0x00DD4798)The LOCKS section of the Javadump shows the following, corresponding output about the block:1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors): 2LKMONINUSE sys_mon_t:0x501C18A8 infl_mon_t: 0x501C18E4: 3LKMONOBJECT java/lang/String@0x4D8C90F8: Flat locked by "main" (0x00129100), entry count 1 3LKWAITERQ Waiting to enter: 3LKWAITER "Thread-5" (0x4F6E4100)Look for information about the blocking thread, main, elsewhere in the THREADS section of the Javadump, to understand what that thread was doing when the Javadump was taken.
Example: a waiting thread
The following sample output from the THREADS section of a Javadump shows a thread, Thread-5, that is in the waiting state, state:CW. The thread is waiting to be notified on java/lang/String@0x68E63E60, which is currently owned by thread main:
3XMTHREADINFO "Thread-5" J9VMThread:0x00503D00, j9thread_t:0x00AE45C8, java/lang/Thread:0x68E04F90, state:CW, prio=5 3XMTHREADINFO1 (native thread ID:0xC0C, native priority:0x5, native policy:UNKNOWN) 3XMTHREADBLOCK Waiting on: java/ lang/String@0x68E63E60 Owned by: "main" (J9VMThread:0x6B3F9A00, java/lang/Thread:0x68E64178)The LOCKS section of the Javadump shows the corresponding output about the monitor being waited on:
1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors): 2LKMONINUSE sys_mon_t:0x00A0ADB8 infl_mon_t: 0x00A0ADF4: 3LKMONOBJECT java/lang/String@0x68E63E60: owner "main" (0x6B3F9A00), entry count 1 3LKNOTIFYQ Waiting to be notified: 3LKWAITNOTIFY "Thread-5" (0x00503D00)
Example: a parked thread that uses the AbstractOwnableSynchronizer class
The following sample output shows a thread, Thread-5, in the parked state, state:P. The thread is waiting to enter a java.util.concurrent.locks.ReentrantLock lock that uses the AbstractOwnableSynchronizer class:
3XMTHREADINFO "Thread-5" J9VMThread:0x4F970200, j9thread_t:0x501C0A28, java/lang/Thread:0x4D9AD640, state:P, prio=5 3XMTHREADINFO1 (native thread ID:0x157C, native priority:0x5, native policy:UNKNOWN) 3XMTHREADBLOCK Parked on: java/util/concurrent/locks/ReentrantLock$NonfairSync@0x4D9ACCF0 Owned by: "main" (J9VMThread:0x00129100, java/lang/Thread:0x4D943CA8)This example shows both the reference to the J9VMThread thread and the java/lang/Thread thread that currently own the lock. However in some cases the J9VMThread thread is null:3XMTHREADINFO "Thread-6" J9VMThread:0x4F608D00, j9thread_t:0x501C0A28, java/lang/Thread:0x4D92AE78, state:P, prio=5 3XMTHREADINFO1 (native thread ID:0x8E4, native priority:0x5, native policy:UNKNOWN) 3XMTHREADBLOCK Parked on: java/util/concurrent/locks/ReentrantLock$FairSync@0x4D92A960 Owned by: "Thread-5" (J9VMThread: <null>, java/lang/Thread:0x4D92AA58)In this example, the thread that is holding the lock, Thread-5, ended without using the unlock() method to release the lock. Thread Thread-6 is now deadlocked. The THREADS section of the Javadump will not contain another thread with a java/lang/Thread reference of 0x4D92AA58. (The name Thread-5 could be reused by another thread, because there is no requirement for threads to have unique names.)
Example: a parked thread that is waiting to enter a user-written lock that does not use the AbstractOwnableSynchronizer class
Because the lock does not use the AbstractOwnableSynchronizer class, no information is known about the thread that owns the resource:
3XMTHREADINFO "Thread-5" J9VMThread:0x4FBA5400, j9thread_t:0x501C0A28, java/lang/Thread:0x4D918570, state:P, prio=5 3XMTHREADINFO1 (native thread ID:0x1A8, native priority:0x5, native policy:UNKNOWN) 3XMTHREADBLOCK Parked on: SimpleLock@0x4D917798 Owned by: <unknown>
Example: a parked thread that called the LockSupport.park method without supplying a blocker object
Because a blocker object was not passed to the park() method, no information is known about the locked resource:
3XMTHREADINFO "Thread-5" J9VMThread:0x4F993300, j9thread_t:0x501C0A28, java/lang/Thread:0x4D849028, state:P, prio=5 3XMTHREADINFO1 (native thread ID:0x1534, native priority:0x5, native policy:UNKNOWN) 3XMTHREADBLOCK Parked on: <unknown> Owned by: <unknown>The last two examples provide little or no information about the cause of the block. If you want more information, you can write your own locking code by following the guidelines in the API documentation for the java.util.concurrent.locks.LockSupport and java.util.concurrent.locks.AbstractOwnableSynchronizer classes. By using these classes, your locks can provide details to monitoring and diagnostic tools, which helps you to determine which threads are waiting and which threads are holding locks.
Parent: Threads and stack trace (THREADS)
Error 404 - Not Found Error 404 - Not Found
The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.