VisualVM - Thread States
Asked Answered
F

2

100

Can someone please explain me the difference between Sleeping, Wait, Park, and Monitor thread states in VisualVM.

enter image description here

This is what I have found:

Running: thread is still running.
Sleeping: thread is sleeping (method yield() was called on the thread object)
Wait: thread was blocked by a mutex or a barrier, and is waiting for another thread to release the lock
Park: parked threads are suspended until they are given a permit. Unparking a thread is usually done by calling method unpark() on the thread object
Monitor: threads are waiting on a condition to become true to resume execution

What I am unable to understand is the state Park, what actually suspends the thread? How do I detect in the code what has made the thread suspend its execution?

Can someone please guide me in this regard.

Thanks.

Falcongentle answered 10/12, 2014 at 16:35 Comment(0)
G
62

I found a very nice diagram which pretty much describes all you need/want to know.

enter image description here

  1. New

The thread is in new state if you create an instance of Thread class but before the invocation of start() method.

  1. Runnable

The thread is in runnable state after invocation of start() method, but the thread scheduler has not selected it to be the running thread.

  1. Running

The thread is in running state if the thread scheduler has selected it.

  1. Timed waiting

Timed waiting is a thread state for a thread waiting with a specified waiting time. A thread is in the timed waiting state due to calling one of the following methods with a specified positive waiting time:

  • Thread.sleep(sleeptime)
  • Object.wait(timeout)
  • Thread.join(timeout)
  • LockSupport.parkNanos(timeout)
  • LockSupport.parkUntil(timeout)
  1. Non-Runnable (Blocked)

This is the state when the thread is still alive, but is currently not eligible to run.

  1. Terminated

A thread is in terminated or dead state when its run() method exits.

Hopefully this answers your question :).

Parking:

Disables the current thread for thread scheduling purposes unless the permit is available.

Threads are being parked or suspended if you like to call it this way because it does not have a permission to execute. Once permission is granted the thread will be unparked and execute.

Permits of LockSupport are associated with threads (i.e. permit is given to a particular thread) and doesn't accumulate (i.e. there can be only one permit per thread, when thread consumes the permit, it disappears).

Gaselier answered 10/12, 2014 at 16:50 Comment(3)
Thanks for your response. I also went through this but somehow my question still remained unanswered. Could you please go through my question again; I have updated it. Am specially looking for an answer w.r.t. the park state.Falcongentle
thanks again for the update. So in the state of park, is the thread waiting for it to get scheduled or is it waiting on some condition?Falcongentle
@AliShahAhmed Thread is waiting for permission (condition) to execute - if this condition is not met for certain period timeout is reached and thread terminated - PS. Sorry for delay answering hahaGaselier
G
60

VisualVM maps the Java thread state (as described in @Maciej's answer) to the state presented in its UI as follows:

BLOCKED -> Monitor
RUNNABLE -> Running
WAITING/TIMED_WAITING -> Sleeping/Park/Wait (see below)
TERMINATED/NEW -> Zombie

Sleeping and Park are specific cases of (timed) waiting:

Sleeping: specifically waiting in Thread.sleep().  
Park:     specifically waiting in sun.misc.Unsafe.park() (presumably via LockSupport).

(The mapping is performed in ThreadMXBeanDataManager.java.)

A brief (and non-authoritative) discussion of Java thread state can be found here.

EDITED TO ADD:

It's also worth noting that threads blocking in calls to native methods appear in the JVM as RUNNABLE, and hence are reported by VisualVM as Running (and as consuming 100% CPU).

Glaciology answered 6/4, 2016 at 11:1 Comment(3)
This should be the correct answer. The question was about JVisualVM thread states not the JVM thread states.Wilsey
Can you add the reference where you found the information about the threads blocking in calls to native methods?Meekins
Does this mean it is impossible to tell by the thread state diagram in VisualVM whether thread was actually doing something or waiting on I/O to happen?Kumar

© 2022 - 2024 — McMap. All rights reserved.