We Keep Coding

VisualVM - Thread States

Can someone please explain me the difference between Sleeping, Wait, Park, and Monitor thread states in VisualVM.
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.

I found a very nice diagram which pretty much describes all you need/want to know.
New
The thread is in new state if you create an instance of Thread class but before the invocation of start() method.
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.
Running
The thread is in running state if the thread scheduler has selected it.
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)
Non-Runnable (Blocked)
This is the state when the thread is still alive, but is currently not eligible to run.
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).

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

what does the lock id mean in java thread dump

I usually observed the lock id (as following) in the thread dump:
"Thread-pool-Bill" - Thread t#42
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
- locked <79f0aad8> (a java.net.SocksSocketImpl)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
In locked <79f0aad8> (a java.net.SocksSocketImpl), what does 79f0aad8 mean? It doesn't seem to be an object address nor object id cause I couldn't find it from heap dump. So what it is?

its address of internal lock construct(monitor object) for hotspot JVM.
code for your reference
oop o = _locked_monitors->at(i);
instanceKlass* ik = instanceKlass::cast(o->klass());
st->print_cr("\t- locked <" INTPTR_FORMAT "> (a %s)", (address)o, ik->external_name());

You can consider it an opaque identifier. The key is that other pieces of code may be waiting on that particular lock, which will also show up in the thread dump. So you can use it to match up waits and locks between threads. It may also show up in the JVMs thread dump deadlock detection outputs - but I'm not sure.
The entry appears in the stack trace from either a synchronised method, or explicit synchronised block, and is related to the object synchronized on.

Its the hashcode/id of the object on which the Thread owns the lock. Since your thread is RUNNABLE so some other thread may or may not be waiting on it. If another thread is waiting for this lock then your Thread dump would have another entry somewhere else showing a BLOCKED or WAITING Thread which is waiting for lock on the same id i.e 79f0aad8
But since you say you cannot find this String (79f0aad8) anywhere else in your file so either:
you have multiple thread dump files or
the thread Thread t#42 wasn't blocking any other thread when the thread dump was taken.

Thread in RUNNABLE state but stack trace shows it is processing?

After taking Thread Dump for a Java Application, several thread snapshots are presented as follows:
Thread t#384
java.lang.Thread.State: RUNNABLE
at xmlpdf.text.Word.allocateArrays(Word.java:205)
at xmlpdf.text.Word.calculateWidth(Word.java:237)
at xmlpdf.text.TextFormatter.format(TextFormatter.java:167)
at xmlpdf.text.TextFormatter.formatToWidthImpl(TextFormatter.java:116)
at xmlpdf.text.TextBlock.formatToWidthImpl(TextBlock.java:71)
at xmlpdf.tables.TextCell.formatToWidthImpl(TextCell.java:45)
at xmlpdf.tables.Cell.formatToWidth(Cell.java:349)
at xmlpdf.tables.Row.assignCellWidths(Row.java:97)
at xmlpdf.tables.Table.layout(Table.java:354)
at xmlpdf.tables.Table.formatRowsToWidth(Table.java:329)
at xmlpdf.tables.Table.formatToWidthImpl(Table.java:373)
at xmlpdf.Block.formatToWidth(Block.java:57)
at xmlpdf.renderer.Page.formatWidthAndHeight(Page.java:200)
at xmlpdf.renderer.Page.addBlockWhichIsNotFooterWholePagesOnly(Page.java:1026)
.....
several same threads (identified by Thread Name) are in exactly same state.
F.Y.I. Examining via JMX also shows these threads are running for 4 hours.
Question:
How can a thread be in a RUNNABLE state and yet the Stack Trace of it shows it is doing something?
I thought RUNNABLE always means thread is just available to process any new task instead of processing the task.

Thread.State.RUNNABLE API: A thread in the runnable state is executing in the Java virtual machine but it may be waiting for other resources from the operating system such as processor

Analyzing thread dump of a java process

I have Java EE based application running on tomcat and I am seeing that all of a sudden the application hangs after running for couple of hours.
I collected the thread dump from the application just before it hangs and put it in TDA for analysis:
TDA (Thread Dump Analyzer) gives the following message for the above monitor:
A lot of threads are waiting for this monitor to become available again.
This might indicate a congestion. You also should analyze other locks
blocked by threads waiting for this monitor as there might be much more
threads waiting for it.
And here is the stacktrace of the thread highlighted above:
"MY_THREAD" prio=10 tid=0x00007f97f1918800 nid=0x776a
waiting for monitor entry [0x00007f9819560000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.Hashtable.get(Hashtable.java:356)
- locked <0x0000000680038b68> (a java.util.Properties)
at java.util.Properties.getProperty(Properties.java:951)
at java.lang.System.getProperty(System.java:709)
at com.MyClass.myMethod(MyClass.java:344)
I want to know what does the "waiting for monitor entry" state means? And also would appreciate any pointers to help me debug this issue.

One of your threads acquired a monitor object (an exclusive lock on a object). That means the thread is executing synchronized code and for whatever reason stuck there, possibly waiting for other threads. But the other threads cannot continue their execution because they encountered a synchronized block and asked for a lock (monitor object), however they cannot get it until it is released by other thread. So... probably deadlock.

Please look for this string from the whole thread dump
- locked <0x00007f9819560000>
If you can find it, the thread is deadlock with thread "tid=0x00007f97f1918800"

Monitor = synchronized. You have lots of threads trying to get the lock on the same object.
Maybe you should switch from using a Hashtable and use a HashMap

This means that your thread is trying to set a lock (on the Hashtable), but some other thread is already accessing it and has set a lock. So it's waiting for the lock to release. Check what your other threads are doing. Especially thread with tid="0x00007f9819560000"

Should thread blocked by java NIO Selector.select() be considered waiting or running

The documentation of selectorObj.select() method states
This method performs a blocking
selection operation. It returns only
after at least one channel is
selected, this selector's wakeup
method is invoked, or the current
thread is interrupted, whichever comes
first.
I understand the documentation
The thread that is blocked by select method, shouldn't be waiting? When I run profiler I see the thread is in run mode instead of wait state.
Although, I accept that, it is not mentioned that the thread should be in wait state, but my assumption is that till the signal dispatcher thread provides some input regarding any activity on channel registered with selector; the thread should be in wait state.
Please provide me some help as to why my assumption could be wrong.

When the thread is blocked in an I/O call, it is still running as far as Java thread is concerned.
Most profilers simply show thread state, which is defined as,
NEW A thread that has not yet started is in this state.
RUNNABLE A thread executing in the
Java virtual machine is in this
state.
BLOCKED A thread that is blocked
waiting for a monitor lock is in this
state.
WAITING A thread that is waiting
indefinitely for another thread to
perform a particular action is in
this state.
TIMED_WAITING A thread that is
waiting for another thread to perform
an action for up to a specified
waiting time is in this state.
TERMINATED A thread that has exited
is in this state.
As you can see, thread's WAITING/BLOCKED state has nothing to do with I/O.

Normally the select operation invokes the poll(...) system function.
select() provides the kernel with a list of file descriptors that it needs to monitor for read/write/error conditions as well as a timeout value. The kernel registers the process/thread with the associated channel's select function and puts the process/thread to sleep. Once the associated channel is ready or a timer has been expired, the kernel wakes up the registered process/thread. Note that this thread is the kernel thread and not the java application thread.
I do not see a reason for the thread doing select to be in WAIT state (Unless the implementation of the Selector returned by the Selector provider explicitly did a wait in the select() function).

It depends on the profiler. JProfiler shows the time when the selector thread is blocked on Selector.select() as "Network I/O". So, the best way to interpret the blocked Selector.select() as "Waiting for data".
Hope this helps.
Regards,
Slava Imeshev
Cacheonix In-Memory Data Grid