Develop Reference

How JVM collect ThreadDump underhood

Please explain how JVM collect ThreadDump underhood.
I don't understand how it collectons stack traces of threads that are off-CPU (wait disk IO,Network,non-voluntary context switches).
For example, linux perf collect info only about on-CPU threads(which use CPU-cycles)

I'll take HotSpot JVM as an example.
The JVM maintains the list of all Java threads: for each thread it has a corresponding VM structure. A thread can be in one of the following states depending on its execution context (HotSpot knows the current state of each thread, because it's responsible for switching states):
in_Java - a thread is executing Java code, either in the interpreter or in a JIT-compiled method;
in_vm - a thread is inside a VM runtime function;
in_native - a thread is running a native method in JNI context;
there are also transitional states, but let's skip them for simplicity.
An off-cpu thread can have only
in_native state: all socket I/O, disk I/O, and otherwise blocking operations are performed only in native code;
in_vm state, when a thread is blocked on a VM mutex.
Whenever the JVM calls a native method or acquires a contended mutex, it stores the last Java frame pointer into the Thread structure.
Now the crucial part: HotSpot JVM obtains a thread dump only at a safepoint.
When you ask for a thread dump, the JVM requests a stop-the-world pause. All threads in in_Java state are stopped at the nearest safepoint, where the JVM knows how to walk the stack.
Threads in in_native state are not stopped, but they don't need to. HotSpot knows their last Java frame, because the pointer is stored in a Thread structure. Knowing the top Java frame, the JVM can find its caller, then the caller of the caller, and so on.
What important here is that the Java part of the stack is "frozen", no matter what the native method does. The top part of the stack (native) can change back and forth, while the bottom part (Java) remains immutable. It cannot change, since the JVM checks for a pending safepoint operation on every switch from in_native to in_Java: if a native method returns, and the VM is currently running a stop-the-world operation, current thread blocks until the operation ends.
So, getting a thread dump involves
Stopping all in_Java and in_vm threads at a safepoint;
Walking through the global list of threads maintained by the JVM;
If a thread is running native method, its top Java frame is stored in a thread structure; if a thread is running Java code, its top frame corresponds to the currently executing Java method.
Each frame has a link to the previous frame, so given the top frame, the JVM can construct the whole stack trace to the bottom.

The Internal Java Memory Model for Thread Stacks

I was reading article about Internal Java Memory Model.
There is one point I want to ask about :
Each thread running in the Java virtual machine has its own thread stack. The thread stack contains information about what methods the thread has called to reach the current point of execution.
Why each thread needs to save information about what methods has been executed(!) ? If it's related to context-switching then (if I'm not wrong) thread must save the information about method which is currently being executed.
What is actual need for save already executed method's information?

This is referring to the currently active methods. Note that there can be several methods in a thread active at the same time (A calls B calls C, ...). The stack does not contain information about methods that have already completed.

I think rephrasing this paragraph makes it clearer and easier to understand:
Each thread running in the Java virtual machine allocates some memory for its call stack. The call stack contains information about what methods the thread has called to reach the current point of execution.

Static method behavior in multi-threaded environment in java

class Clstest{
public static String testStaticMethod(String inFileStr) {
// section 0
// section 1
// do something with inFileStr
// section 2
// section 3
return inFileStr;
}
}
Let's assume there are five threads are each executing a call to Clstest.testStaticMethod("arg-n") at the same time.
Thread 1 calls Clstest.testStaticMethod("arg-1").
When thread 1 is in the section 1, thread 2 calls Clstest.testStaticMethod("arg-2").
Then what will happen to Thread 1? Will it go to sleep state?
When Thread 1 got the chance will it resume the execution from section 1 where it was paused?
How it happens when there's one Clstest.testStaticMethod and same Clstest.testStaticMethod is shared between all five threads?
Is there any possibility to interchange the inFileStr sent by multiple threads?

Hans Passant's answer is good. But I thought I would try and explain at a slightly more simple level for anybody who comes across this and is newish to Java. Here goes..
Memory in java is split up into two kinds - the heap and the stacks. The heap is where all the objects live and the stacks are where the threads do their work. Each thread has its own stack and can't access each others stacks. Each thread also has a pointer into the code which points to the bit of code they're currently running.
When a thread starts running a new method it saves the arguments and local variables in that method on its own stack. Some of these values might be pointers to objects on the heap. If two threads are running the same method at the same time they will both have their code pointers pointing at that method and have their own copies of arguments and local variables on their stacks. They will only interfere with each other if the things on their stacks point to the same objects on the heap. In which case all sorts of things might happen. But as Hans points out, Strings are immutable (cannot be changed) so we're safe if this is the only object being "shared".
So many threads can be running the same method. They might not be running at the same time - it depends how many cores you have on your machine as the JVM maps Java threads to OS threads, which are scheduled onto hardware threads. You therefore have little control over the way these threads interleave without using complex synchronisation mechanisms.
Note that sleeping is something a thread does to itself.

Will it go to sleep state?
No, running a thread does not affect other threads as long as they don't intentionally synchronize with each other. If you have more than one processor core, all recent machines do, those threads are likely to execute at the exact same time. That gets to be bit less likely when you start 5 threads since your machine might not have enough cores. The operating system is forced to choose between them, giving them each some time to run. The job of the thread scheduler. A thread will then not be in a "sleep" state, it is simply paused and waiting for the thread scheduler to give it a chance to run. It will resume where it was interrupted by the scheduler.
Is there any possibility to interchange the inFileStr sent by multiple threads?
There is no such possibility, threads have their own stack so any method argument and local variable will be unique for each thread. Using a string furthermore guarantees that these threads cannot interfere with each other since strings are immutable.
There's no such guarantee if the argument is a reference to another kind of mutable object. Or if the method itself uses variables that are static or references to objects on the heap. Synchronization is required when a thread modifies the object and another thread reads it. The lock keyword in the C# language is the boilerplate way to implement such required synchronization. The fact that the method is static does not mean such synchronization is never required. Just less likely since you don't have to worry about threads accessing the same object (sharing this).

start a new thread in catch

I have a class (class A for example) implements Runnable. In run method I have a try catch.I want to start a new thread in catch like this
new Thread(new A()).start();
Is this a true manner to handle exceptions?
I mean maybe its a dangerous way because the heap will get full very soon; in other words garbage collector will not garbage this object because another object has been just created in it.

I mean maybe its a dangerous way because the heap will get full very soon; in other words garbage collector will not garbage this object because another object has been just created in it.
It is not dangerous for that reason. If we assume that new Thread(new A()).start(); is the last thing that the original thread does before it exits, then by the time we need to GC the original thread will have exited, and hence its stack contents won't be reachable. The only thread that will still be reachable will be the one that it still alive.
However, it is dangerous if the new thread is liable to repeat the computation and then throw the same exception again, and again, and again ... So if you do write code like this, it is a good idea for the application to keep a track of how often the thread is being re-launched, and pull the plug if it happens too often.
The other problem with the code as written is that the code that launched the original thread sees it die, but doesn't hear about the new thread. That is problematic if your want to initiate shutdown by interrupting the worker threads.
If you put those two problems (and others) together, it is better for the code that launched the original thread to be responsible for relaunching.

Thread is new parallel light weight process. As soon as its run method completed it will be eligible for GC. I don't think it effects GC life cycle of the object from where it started.
Only one new thing in your case is, handling exceptions with thread. Without knowing more details about why you want this, its hard to tell is it safe/good practice.

This is not a very good way of handling exceptions within a thread. Why would the newly created thread of the same type not have the same exception?
What you should do is have some form of thread manager up a level from the thread that will monitor for, handle, and if necessary recreate new threads when old ones fail.
This will allow you to add more ways to handle the error, and will look a lot neater if you try and debug the threads. instead of having all these hanging threads (cause the parent was cleaned by GC) you'll know all threads have spawned from the same location.
What you are proposing will not clutter the heap because threads will be GC'd when they have finished running.

If you didn't store any references to the thread that you'd created - it will be cleaned by GC when terminated. In your case I think it's pretty safe to start a new thread inside run() method.
Just be sure you are not creating inner classes or storing this thread instance - it can cause memory leak, of course.
Good luck

Java Threads vs Pthreads

I was asked this question in an interview today.
"When we create a thread with pthread_create() (POSIX Threads), the thread starts on its own. Why do we need to explicitly call start() in Java. What is the reason that Java doesnt start the thread when we create an instance of it."
I was blank and interviewer was short of time and eventually he couldn't explain the reason to me.

In Java not starting the thread right away leads to a better API. You can set properties on the thread (daemon, priority) without having to set all the properties in the constructor.
If the thread started right away, it would need a constructor,
public Thread(Runnable target, String name, ThreadGroup threadGroup, int priority, boolean daemon, ContextClassLoader contextClassLoader, long stackSize)
To allow setting all these parameters before the thread started. The daemon property can't be set after the thread has started.
I'm guessing that the POSIX API takes a struct with all the thread properties in the call to pthread_create(), so it makes sense to start the thread right away.

The reasons are a lot. But I'll give you a few:
The thread, itself, might start executing before returning the instance.
The context classloader MUST be set properly before running the thread (look at the previous point)
Extra configuration like priority should be set before starting the thread
pthreads uses a pointer to the initialized structure(s), since the java.lang.Thread cannot be properly initialized in the end of the c-tor, see points above; straight call to the native pthread_create to actually execute the code makes no sense
I hope you get the idea.