We Keep Coding

Give program time to shutdown threads but with System.exit backup plan?

Sometimes the system process of a java application doesn't fully shutdown. This is mainly because one or more threads didn't die.
One can call:
System.exit(0);
But this kills all threads.
I want all my threads to shutdown correctly so i don't plan on using System.exit. But sometimes due to circumstances one or more threads don't die correctly. This causes the application to not fully shutdown and linger in the background sometimes even locking up resources.
My first thought was writing an ExitWatcher which starts when program stops and calls system.exit after 10 seconds if the program is still alive. I quickly found out that the ExitWatcher now prevents the program from shutting down ;-)
How do you give a java program time to shutdown correctly (ie close all threads correctly) but at the same time have a backup plan that calls System.exit if shutdown takes too long?

You can use daemon threads when you don't want a thread to prevent a program from exiting (so using setDaemon(true) on your ExitWatcher thread would solve your immediate problem). However I doubt you really need or want an ExitWatcher, as situations like that are usually relatively easily prevented with proper design.
Proper shutdown procedures include interrupting threads that are active (and designing them so they behave nicely when interrupted), using daemon threads where necessary, shutting down connections properly etc. Using a mechanism like your ExitWatcher is more of a hackish approach, as it indicates your program doesn't always behave nicely at shutdown.

How is a Java application equipped?

I read below from the book < Core Java vol. 1 >:
Every Java application starts with a main method that runs in the main
thread. In a Swing program, the main thread is short-lived. It
schedules the construction of the user interface in the event dispatch
thread and then exits...Other threads, such as the thread that posts
events into the event queue, are running behind the scenes, but those
threads are invisible to the application programmer.
It gives me a feeling that each Java program is accommodated by the JVM with a standard set of threads. And I think they include:
A main thread
A event dispatch thread
I guess such threads are just like other resources such as heap space, stack that JVM granted to each Java application. And customer should do different work properly in different threads. Such as do Swing-related things only in the event dispatch thread.
Am I correct on this? Where can I find some authoritative reference? The JVM spec seems not have this.
And if I never use the event dispatch thread, such as in a console application, can I disable it to save some CPU cycle?
Add 1
Below link explains the detail about how Swing framework employs threads.
Concurrency in Swing
http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html

It appears that this is implementation-defined, but HotSpot has the following:
VM thread
This thread waits for operations to appear that require the JVM to reach a safe-point. The reason these operations have to happen on a separate thread is because they all require the JVM to be at a safe point where modifications to the heap can not occur. The type of operations performed by this thread are "stop-the-world" garbage collections, thread stack dumps, thread suspension and biased locking revocation.
Periodic task thread
This thread is responsible for timer events (i.e. interrupts) that are used to schedule execution of periodic operations
GC threads
These threads support the different types of garbage collection activities that occur in the JVM
Compiler threads
These threads compile byte code to native code at runtime
Signal dispatcher thread
This thread receives signals sent to the JVM process and handle them inside the JVM by calling the appropriate JVM methods.
In addition to any threads that your code spawns.
EDIT in response to the bounty (you're right, some guy's blog is pretty shaky support, although it was the best place I could find everything summarized) --- OpenJDK's description of their runtime system (intended to be a copy of HotSpot) describes the same thing:
People are often surprised to discover that even executing a simple “Hello World” program can result in the creation of a dozen or more threads in the system. These arise from a combination of internal VM threads, and library related threads (such as reference handler and finalizer threads). The main kinds of VM threads are as follows:
VM thread: This singleton instance of VMThread is responsible for executing VM operations...
Periodic task thread: This singleton instance of WatcherThread simulates timer interrupts for executing periodic operations within the VM
GC threads: These threads, of different types, support parallel and concurrent garbage collection
Compiler threads: These threads perform runtime compilation of bytecode to native code
Signal dispatcher thread: This thread waits for process directed signals and dispatches them to a Java level signal handling method
I can't find any references from Oracle to confirm that their implementation is the same, but these slides from a presentation by Paul Hohenesee at Sun mentions:
Thread types
Java, aka mutator
One VM thread: GC, deoptimization, etc.
Compiler
Watcher, timer
Low memory monitor
Garbage collector, parallel collectors
Given that this presentation must be at least 6 years old, the implementation may have changed slightly, but the components are more or less the same.

Here is a simple way to print the active threads:
import java.util.Set;
public class ListThreads
{
public static void main(String[] args) throws InterruptedException
{
Set<Thread> threadSet = Thread.getAllStackTraces().keySet();
for (Thread thread : threadSet)
System.out.println(thread.getName());
}
}
Apart from your main thread, you will see a couple of other threads:
Attach Listener
Finalizer
Reference Handler
Signal Dispatcher
Sometimes one of these as well:
Monitor Ctrl-Break
DestroyJavaVM
These threads are "daemon threads", which means that they do not stop your java process from exiting, even if they are not finished. So, your "main" thread is the only non-daemon thread.
The Swing event dispatcher thread, is not one of them, and will not be started by default. It will only start once you start using Swing components.
All of these threads are crucial. Just accept their presence. They are good for you.

1) Every swing application is a java application.
But,
2) Not every java application is a swing application.
That said every java application is provided with a main thread by the JVM.
In addition to that every swing application is provided with an event dispatcher thread, due to the swing specification (Java Swing APIs and Developer Guide).
Aslong you don't import APIs you don't require, it won't be necessary to get a headache about stopping unnecessarily started threads.

This is actually a JVM implementation concern, not prescribed by the JVM spec. You can asume that each JVM provides your application with at least 1 thread, the main thread. The Event dispatch thread is Swing specific.
See also the Thread javadoc javadoc .

In addition to other answers : why not try some programs with the a few utilities to print the threads. There is API to enumerate the main and sub thread groups (in effect all). Do this with an app that :
has a main and nothing else
main with a few other methods and objects
main with a class that makes its own thread
main that initializes a swing UI
web app that has a simple jsp test page
Code to see all threads https://stackoverflow.com/a/1323480/1643558 (there are other ways but this one is good to get a understanding and will work fine in most apps I have tried, there is also https://stackoverflow.com/a/3018672/1643558)
FYI a web app could launch a swing ui - though only of use if it does it just for the admin and in a sigleton, as the UI would show on the server. If it made the UI for every user of the app it would quickly run out of memory and be annoying for anyone logged on to the server (assuming the server has UI/ desktop). So not included web app + swing though its possible.

I guess such threads are just like other resources such as heap space, stack that JVM granted to each Java application. And customer should do different work properly in different threads. Such as do Swing-related things only in the event dispatch thread.
The common JVM threads as mentioned by #Patrick are spawned (by the JVM) during runtime initialization before the user program starts execution and perform maintenance/housekeeping jobs in the JVM.
The customer i.e. user threads, spawned from within application code, cannot directly control System level threads. Swing-related threads would start when Swing-related code is executed not for all types of java programs.
Am I correct on this? Where can I find some authoritative reference? The JVM spec seems not have this.
Apart from the links mentioned by #Patrick check the following link:
RuntimeOverview
And if I never use the event dispatch thread, such as in a console application, can I disable it to save some CPU cycle?
The event dispatch thread is created in case a Swing application is executed. You could only control threads created by user application, not the JVM runtime threads.

And if I never use the event dispatch thread, such as in a console application, can I disable it to save some CPU cycle?
Ans: Event dispatch thread isn't initiated unless your java Application is a swing application. So you can safely assume that your java isn't using event dispatch thread
Coming to threads:
Each thread is a process, a program you write can be divided into many processes.
Process can be defined as a program in execution.
Threads are mainly used for parallel programming (Don't confuse with concurrent programming). Also threads can be software defined or Hardware("dynamic" by the processor). The threads which you speak about here are software defined threads and you never care about hardware defined threads. If the processor you use is multi core then different threads may run on different cores or on the same one based on Tomasulo's Algorithm

Why are my threads NOT exiting when the Test Suite finishes?

I have created an automated test suite which has a thread pool running simultaneously in the background of all test cases in order to obtain given system and performance metrics. Each thread is using a JSch connection to execute its shell commands and they are receiving [JSchException: Channel not opened exceptions].
The key problem is that the test suite continues to run forever, because the threads are not exiting even when all test cases have ended. But I'm not sure why...
When I checked the thread dump, I found that the threads do not exit because they are in a BLOCKED status.
Does anybody have an explanation for this? Or some help in resolving this issue?

I guess you mean the shutdownNow() method of ExecutorService. This is the documentation (I formatted the relevant parts in bold):
Attempts to stop all actively executing tasks, halts the processing of waiting tasks, and returns a list of the tasks that were awaiting execution.
This method does not wait for actively executing tasks to terminate. Use awaitTermination to do that.
There are no guarantees beyond best-effort attempts to stop processing actively executing tasks. For example, typical implementations will cancel via Thread.interrupt(), so any task that fails to respond to interrupts may never terminate.
Thread interruption is a cooperative process, your threads must be implemented so that they respond to interruption.
EDIT
1) About Thread.currentThread.interrupt() see this question: Why invoke Thread.currentThread.interrupt() when catch any InterruptException?
So you need to do this only if you have other methods/thread groups watching the interrupted status. In your case, probably not, but it does not hurt.
2) It seems that in "ShellUtils.executeCommand" you are running external programs. This could be the source of the problem if this method does not react to thread interruptions.

Java wait for all threads before terminating

I am trying to test an application with Jmeter. The application uses a proprietary library that creates multiple threads. In JMeter I have created a AbstractJavaSamplerClient, which does not seem to wait for all the other threads that might be generated in the application. Instead it just runs its own default method and closes leaving the other threads running in the background - since I am connecting to a server in the application, I can see through the server logs that it is still connected. Since I don't have the references to the other threads as they are instantiated through the proprietary library, I can't use the common solutions of wait() or join().How can I get the main thread to wait for all the threads (none of which I have references too)?

Put all work with the library in a separate thread in a specially created thread group. The library will create new threads in that thread group and its descendants. List all threads of that group recursively with group.enumerate(new Thread[group.activeCount()*2],true). Then you can join() them all.

You can start with
Thread.getAllStackTraces().keySet();
which will give you a set of all running threads. This will include those you are interested in and all the other threads, including those internal to the JVM.
Hopefully you'll be able to filter out the ones you are interested in by name, and then you can join() them.

Why need use non-daemon threads in java?

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.