I am debugging a live environment and I have taken some thread dumps. I see that lot of thread are "waiting on condition"; but how can I know what that condition is?
The below is the snippet of real thread dump stack:
"Uploader-pool-job-create-ca2d264a-51b3-4fa3-8113-
f0f0aca47add-StreamThread-10-0_14" #140 daemon prio=5 os_prio=0
tid=0x00007f006002b800 nid=0x18b waiting on condition
[0x00007f004d9e1000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000002c20d4320> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Other:
"Uploader-pool-job-create-ca2d264a-51b3-4fa3-8113-
f0f0aca47add-StreamThread-3-0_16" #138 daemon prio=5 os_prio=0
tid=0x00000000025da000 nid=0x189 waiting on condition
[0x00007f004dbe3000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000002c20d6690> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
In these threads it is saying "waiting on condition"; but I can't decipher what that condition is on which the thread is waiting on?
--> In general, are there any guidelines how to understand thread dumps.
The state "waiting on condition" means that the thread is waiting on an internal VM condition variable. These are not Java objects and so there is no means to identify them.
In between, we have also put the main thread to sleep by using TimeUnit. sleep() method. So the main thread can wait for some time and in the meantime, T1 will resume and complete its execution.
Java doc formally defines WAITING state as: “A thread that is waiting indefinitely for another thread to perform a particular action is in this state.”
The thread, "Thread-6", is blocked waiting to lock <0x650efdf0>. The thread, "QueueRequestScheduled", holds this lock and itself is blocked "waiting on condition". However there is no indication what this condition is.
Alternatively, the thread that makes a condition (potentially) true can use a special broadcast version of the signal operation to awaken all waiting threads at once. Each thread will then recheck the condition and if appropriate wait again, without the need for explicit cascading.
This is typical for event synchronization: a thread waiting for an event, namely, the fact that it has acquired mutex ownership. There are two ways in which this can happen:
The state "waiting on condition" means that the thread is waiting on an internal VM condition variable. These are not Java objects and so there is no means to identify them. The thread has entered the VM for something (could be classloading, compilation, deoptimization, ...) , to find out more I'd need to see a C stack trace for the thread.
It's all there in the stack trace - ScheduledThreadPoolExecutor
is awaiting on the available
condition:
private final Condition available;
. . .
available.awaitNanos(delay); // ScheduledThreadPoolExecutor.java:1093
In other words, the thread in the pool is idle and waiting for more work.
In general, the stack trace shows exactly the Java file name and line number where the thread of execution is currently at (usually when a thread is waiting, the deepest few levels would be too low-level, so just continue up the chain to find the most meaningful level).
Seems to me like they are waiting to acquire a lock. The condition in this case would be: waiting for the timeout to finish to attempt to acquire the lock.
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000002c20d4320> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With