How is a Java application equipped?

Question

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

Answer 1

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.

Answer 2

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:

1. Attach Listener
2. Finalizer
3. Reference Handler
4. Signal Dispatcher

Sometimes one of these as well:

5. Monitor Ctrl-Break
6. 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.

Answer 3

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.

Answer 4

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 .

Answer 5

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 :

1. has a main and nothing else
2. main with a few other methods and objects
3. main with a class that makes its own thread
4. main that initializes a swing UI
5. 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.

Answer 6

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.

Answer 7

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