Anytime I run a debug configuration in Eclipse (a "debugging session"), and I switch over to the Debug Perspective, I always see "Threads" as well as "Daemon Threads" in the call stack view.
Why are some threads daemons and other just POTs (plain-old-threads)? Thanks in advance!
(Note: I'm not asking what daemons are, or what daemon threads are, just how Eclipse determines which threads are daemons.)
Daemon threads in Java are threads that run in the background (mostly created by the JVM) for performing background tasks (like garbage collection). The main difference between a daemon thread and a user thread is that as soon as all user threads finish execution Java terminates itself. JVM doesn't wait for daemon threads to finish their execution.
Note that you can make a thread created by a user thread to be a daemon thread by setDaemon(true) (and it must be called before the thread's start() method is called).
In order for a program to continue running, it must always have at least one live user thread.
Eclipse, like you, can easily check whether a thread isDaemon() or not.
Daemon threads are any thread that has had setDamon(true) called on them. Or any thread that is a child of a daemon thread. I'm guessing eclipse uses isDaemon() to determine which threads are daemons.
The JVM will exit when all non daemon threads have terminated. So daemon threads are used for daemon tasks - i.e. tasks that should not prevent the JVM from exiting.
When a Thread object is created you can call setDaemon(true) on the Thread and that marks it as a daemon.
You can then call isDaemon() on the thread to determine whether that thread has been marked as a daemon.
The eclipse debugger is just reading this flag.
Related
I'm new in Java world so at the moment I'm learning about Threads.
I've read that daemon thread is described as background task, so I thought that it means it's lighter than the normal thread.
I also read next about daemons on Wikipedia:
"A daemon is a type of background process designed to run continually in the background, waiting for event(s) to occur or condition(s) to be met.These processes typically use minimal system resources and perform tasks which require little to no input from the user."
No, the only difference between daemon threads and non-daemon threads in Java is that a non-daemon thread prevents the JVM from terminating, whereas a daemon one doesn't: once all non-daemon threads have completed, the JVM will exit.
I have written a main application which creates two threads viz A and B. Thread A is user thread and thread B is daemon. A finishes the job and hence the JVM exits but Thread B is still running. Since Threads A and B are created in the JVM space, and JVM has exited since all the user threads have completed execution, where Thread B execute ? In which process space does it execute?
A "daemon" thread is intended to provide a general service in the background as long as the program is running, but is not part of the essence of the program. Thus, when all of the non-daemon threads complete, the program is terminated "abruptly", killing all daemon threads in the process.
So as soon as all non-daemon exits, the JVM shuts down all the daemons immediately, without any of the formalities you might have come to expect (Not even Finally). Because you cannot shut daemons down in a nice fashion, they are rarely a good idea.
Non-daemon Executors are generally a better approach, since all the tasks controlled by an Executor can be shut down at once.
Now Coming to your particular scenario.
A finishes the job and hence the JVM exits but Thread B is still
running- This Assumption is wrong B is not running
where Thread B execute ? In which process space does it execute?
B Will be terminated "abruptly" as soon as A is finished so it
not in execution now and hence no question of process space.
Daemon threads are used in background task for example GC or custom use case.
And the purpose of daemon threads is to serve User threads and once there is no user threads running and program exit then no use of daemon threads
This question already has answers here:
How do you kill a Thread in Java?
(17 answers)
Closed 9 years ago.
I have a fair idea about what is Daemon Thread
But I want to know whether we can kill a Daemon Thread or when does a Daemon Thread get killed in Java?
A daemon thread is ended if one of these two conditions becomes true:
The thread returns from the run() method
The virtual machine is terminated
To actively end a (daemon) thread the most common method is to signal the thread the request to have it terminated, the thread should check for this request in regular intervals and end itself once such a request has been made.
Daemon thread is the thread which runs in background. These threads are started by defalt by JVM. Also we can start a daemon thread through a program as well.
When a main program starts, the only non-daemon thread which is started is the main thread, rest (GC ets) are daemon.
These thread get killed automatically when there is no non-daemon thread running as JVM kills itself after that.
The idea abour daemon threads is that when the last non-daemon thread ends the application ends too. Daemon threads cannot keep the JVM running
It seems that daemon threads are always better - because they will be stopped by the VM after application main thread exits. Are there any other reasons to use non-daemon threads besides the cases when it is not possible to interrupt some operation ?
Thanks.
When you are writing a server (e.g. a servlet container), all your main has to do is to bootstrap and start HTTP listener threads, accepting threads, file system scanning threads, RMI threads, etc.
After bootstrap is done, main is no longer needed as everything happens asynchronously. In this case all essential threads are non-daemon as they have to live past the main method.
Even in Swing (desktop programming) the only requirement on main is to initialize the main window (JFrame). The rest happens in Swing listener threads (EDT) and various background threads.
In fact, any thread that should finish naturally (leaving its "run" method) should not be a daemon thread, as you don't want the JVM to terminate while they are doing their job.
This applies to every thread that you launch, and that you expect to terminate naturally.
As a rule of thumb, daemon threads are the exception, not the rule.
The one major difference is in how daemon threads exit; the JVM just stops them.
finally blocks are not executed
stacks are not unwound
You do not want to use daemon threads for things that need to be left in a known state such as file i/o, database transactions, etc.
You use non-daemon thread whenever you are doing something which you don't want to stop because an another thread exits. If the only purpose of a thread is to support other threads, then it makes sense to use a daemon thread.
If you want to exit when the main thread exits you can call System.exit(). Many applications don't keep their main thread and all the work is in threads it starts.
The VM may stop daemon threads in the middle of their executions, and persistent data could be corrupted because of that.
If you need more control of when a thread is safe to die, do not make it a daemon.
"The virtual machine terminates if the last non-daemon thread has finished."
My question is, What happens to the daemon threads spawned by the application? Why does the JVM not wait for them to finish?
The whole purpose of a daemon thread is that it not not keep the JVM alive if it is the only thread running; this is by design. There are many reasons you might wish to do this.
For example, with a Swing application the user may have invoked a long running task on a background daemon thread (as opposed to on the Event Dispatch thread). Prior to the task completing the user attempts to exit the application. At this stage the application developer may have decided that it is better to shut down the application immediately rather than have the shut-down attempt delayed until the long running computation completes, hence why these decided to assign the computation thread daemon status.
Because they're daemon threads. That's what it means. It doesn't mean anything else.