VisualVM - Thread States

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).


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).