Java Thread: According to sun there are only four stages in thread life cycle - java

According to sun microsystems thread has only four stages:
1. New
2. Runnable
3. Non-Runnable (Blocked)
4. Terminated
According to them there is no running state.
Why is it so?
What is the state when thread running?

As per Java docs these are the states defined
NEW : when an object of thread (lets call it T) is created.
Runnable : when T is started and it participates in consuming the CPU cycles. It is the running state.
BLOCKED : when T is blocked on a monitor of a lock (T may be blocked to enter a synchronized block or method as some other thread is executing that block or method )
WAITING : Thread is waiting (will not be picked by thread scheduler to consume CPU cycle). Until it is notified or interrupted it remains in this state.
TIMED_WAITING : Similar to WAITING state but for a defined time period. Once time period is over it gets out of this state
TERMINATED : the thread execution is over (end of run method).
https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.State.html

https://docs.oracle.com/javase/9/docs/api/java/lang/Thread.State.html
According to the documentation (you read it, didn't you? :)) RUNNABLE means "A thread executing in the Java virtual machine is in this state."
So it seems to be just the choice of words in the enumeration that is confusing you.

Better see the doc:
public static final Thread.State RUNNABLE
Thread state for a runnable
thread. 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.

Related

Why three “blocking” thread states in Java but only one in C#? [closed]

In Java, there are three distinct "blocking" thread states: BLOCKED, WAITING, and TIMED_WAITING. (the manual)
In C#, there is only one "blocking" state: WaitSleepJoin. (the manual)
Why? I can only guess Java's and C#'s respective implementations differ. I don't really see any practical reason why there should be three. Is there any? (I first learned C#'s lock block, Monitor.pulseAll() etc., and spent one and half gnarly hour debugging with Java today, because I assumed Java's synchronized block, Object#notifyAll(), etc. I know how they behave differently now, but I don't understand WHY.)
In java we use the WAITING and TIMED_WAITING on a synchronized object. If a thread is being in the WAITING state, another thread has to wake it up using notify()
TIMED_WAITING is the same as WAITING, but it will continue automatically when the specified time parameter is exceeded.
A thread is in BLOCKED state when the thread wants to run, but it can't run due another thread that is running on the same synchronized object.
So as we can see TIMED_WAITING is just the same as WAITING, but will stop waiting after a specified time.
But why did java seperate BLOCKED and WAITING? This is because they are different as mentioned above. BLOCKED means a thread is runnable but it cannot run, due another thread which is running. And the WAITING state is just waiting to be called for a notify()
Why C# has just one state is just a design decision. All java methods indicates that the thread is not in a runnable state, and C# just decided to combine these three states in a single variant: WaitSleepJoin

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 have used google and the very first page that came up had a very nice diagram which pretty much describes all you need/want to know. Next time its worth trying google for these type of questions.
1) New
The thread is in new state if you create an instance of Thread class but before the invocation of start() method.
2) 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.
3) Running
The thread is in running state if the thread scheduler has selected it.
4) 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)
5) Non-Runnable (Blocked)
This is the state when the thread is still alive, but is currently not eligible to run.
6) 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 is the Thread.State of a thread after Thread.yield()?

What is the Thread.State of a thread after Thread.yield() ? Is it a Thread.State.WAITING? Thanks.
No, the thread will still be in the RUNNABLE state. Note that RUNNABLE signifies that a thread is available to be run and may be either currently running or waiting its turn. Thread.STATE does not distinguish between a thread that is currently executing and a thread that is ready to run, they are both RUNNABLE.
A thread will only enter the WAITING state when either wait(), join() or LockSupport.park() has been called.
By calling Thread.yield() method the currently running thread is voluntarily giving up its slice of CPU time. This thread then goes from running back into a ready state.

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

After taking Thread Dump on a Java Application, several Threads are seen in following state:
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)
.....
Repeated Thread Dumps, show these same Threads(identified by Thread Name) in exactly same state. 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 for it shows it is doing something (in this case something on xmlpdf class...)?
I thought RUNNABLE always meant, Thread is available to process any new 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

evaluation of a java thread dump

I got a thread dump of one of my processes. It has a bunch of these threads. I guess they are keeping a bunch of memory so I am getting OOM.
"Thread-8264" prio=6 tid=0x4c94ac00 nid=0xf3c runnable [0x4fe7f000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.Inflater.inflateBytes(Native Method)
at java.util.zip.Inflater.inflate(Inflater.java:223)
- locked <0x0c9bc640> (a java.util.zip.Inflater)
at org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:235)
at com.my.ZipExtractorCommonsCompress.extract(ZipExtractorCommonsCompress.java:48)
at com.my.CustomThreadedExtractorWrapper$ExtractionThread.run(CustomThreadedExtractorWrapper.java:151)
Locked ownable synchronizers:
- None
"Thread-8241" prio=6 tid=0x4c94a400 nid=0xb8c runnable [0x4faef000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.Inflater.inflateBytes(Native Method)
at java.util.zip.Inflater.inflate(Inflater.java:223)
- locked <0x0c36b808> (a java.util.zip.Inflater)
at org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:235)
at com.my.ZipExtractorCommonsCompress.extract(ZipExtractorCommonsCompress.java:48)
at com.my.CustomThreadedExtractorWrapper$ExtractionThread.run(CustomThreadedExtractorWrapper.java:151)
Locked ownable synchronizers:
- None
I am trying to find out how it arrived to this situation. CustomThreadedExtractorWrapper is a wrapper class that fires a thread to do some work (ExtractionThread, which uses ZipExtractorCommonsCompress to extract zip contents from a compressed stream). If the task is taking too long, ExtractionThread.interrupt() is called to cancel the operation.
I can see in my logs that the cancellation happened 25 times. And I see 21 of these threads in my dump. My questions:
What is the status of these threads? Alive and running? Blocked somehow?
They did not die with .interrupt() apparently? Is there a sure way to really kill a thread?
What does really mean 'locked ' in the stack trace?
Line 223 in Inflater.java is:
public synchronized int inflate(byte[] b, int off, int len) {
...
//return is line 223
return inflateBytes(b, off, len);
}
"locked" means that they own a monitor; namely, the method is synchronized, and the thread dump shows the address of the instance on which synchronization is performed.
You can try to kill a thread with Thread.stop(), but the thread may resist, and it is inherently unsafe, deprecated, and very bad. Do not do it. Besides, I am not sure it works when the thread is in a native method, as is the case here.
Thread.interrupt() nudges the target thread. The thread will notice it the next time it either looks at the interrupt flag explicitly, or performs some potentially blocking operation (I/O, or wait()). The thread may catch the exception and ignore it.
Your threads are "runnable": they are not blocked. Inflater.inflate() is not a blocking function anyway; it performs in-memory computations only. There may be a bug in the native implementation (Inflater.inflateBytes(), but that's not very probable because this relies on Zlib, which is a very stable piece of code). More plausibly, one of the callers (e.g. your ZipExtractorCommonsCompress class) is stuck in a loop in which it asks the Zip extractor to process zero more bytes, and does not understand that it should wait for some more data before trying again.
All these threads are in runnable state
interrupt will not a kill a thread... it is just a flag to indicate whether the thread is interrupted, methods sleep , wait and all will throw InteruptedException on thread interrupt. If you want to stop the thread on interuption check for the method and isInterupted() and finish all the work in that thread
locked indicates that one particular object is locked by that thread
If possible I would recommend you try to use the jvisualvm (its in the bin folder of the JDK install). It can connect to any local java process and provide you with thread information and memory information (usage, allocated objects, etc). The interface is much easier to interpret than the console dumps. For your questions:
The definitions of Thread.State are in the API:
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.
So the two threads in your trace above are alive (note runnable means that they can run, not necessarily that they are running, i.e. the OS scheduler may have them paused while another thread is executing).
Possible ways to "kill" a thread:
Have an uncaught exception
call Thread's stop()
Have the thread complete execution normally (i.e. exit from run()).
For your third question, I am not sure, but I believe that is a reference to an internal lock that the thread is holding.
Is there a sure way to really kill a thread?
No, there is not.
As you have observed Thread.interrupt() advises a thread to stop, but it may not notice, or it may decide to pay no attention.
The only other alternative is Thread.stop(), and that is deprecated because it can seriously destabilize an application. Specifically, Thread.stop() causes all of the threads locks to be released, without any guarantee that the state guarded by the locks is in a fit state to be visible. At the same time, the unexpected exception means that the methods that were interrupted by the stop() don't get a chance to (for example) notify() other threads that are waiting. Finally, it is possible for a thread to catch (and not rethrow) the ThreadDeath exception object, causing the stop() to not stop the thread at all.
In short calling Thread.stop() is a really, really bad idea.

Resources