How is the Java application equipped?

Question

I read below from the book <Core Java vol. 1>:

Each Java application starts with a main method that starts basically a thread. In Swing, the main thread is short-lived. It plans to create a user interface for dispatching thread events , and then exits ... Other threads , such as a thread that sends event messages to the event queue, are run behind the scenes, but those threads are invisible to the application programmer.

It seems to me that every Java program is supported by a JVM with a standard set of threads . And I think they include:

• Main stream
• Sending event stream

I think such threads are similar to other resources, such as heap space, the stack that the JVM provided to every Java application. And the client must work correctly in different threads. Such as Swing related stuff, only in the event dispatch thread.

Am I right about this? Where can I find an authoritative link? The JVM specification does not seem to have this.

And if I never use the event dispatch thread, for example, in a console application, can I disable it to save some processor cycle?

Add 1

The link below explains the details of how the Swing environment uses threads.

Concurrency in Swing http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html

Answer 1

It seems like this is defined by the implementation, but HotSpot has the following :

VM thread

This thread expects operations that require the JVM to reach a safe point. The reason these operations must be performed in a separate thread is because they all require the JVM to be at a safe point where heap change cannot occur. The type of operations performed by this thread is garbage collection "stop-world", dumps of stacks of threads, suspension of threads and the lock offset.

Periodic task

This thread is responsible for timer events (i.e. interrupts) that are used to schedule periodic operations

GC Streams

These threads support the various types of garbage collection that occur in the JVM

Compiler threads

These threads compile bytecode into native code at runtime.

Sending a signal manager

This thread receives signals sent to the JVM process and processes them inside the JVM, invoking the appropriate JVM methods.

In addition to any threads that your code generates.

EDIT in response to generosity (you're right, some guy’s blog is rather shaky, although this was the best place I could find everything generalized) --- OpenJDK description their runtime system (designed to copy HotSpot) describes the same thing :

People are often surprised to find that even executing a simple Hello World program can lead to the creation of a dozen or more threads in the system. They arise from a combination of internal VM threads and library-related threads (such as a link handler and finalizer threads). The main types of VM threads:

• VM thread: this singleton instance of VMThread is responsible for performing VM operations ...

• Intermittent task: this singleton WatcherThread instance simulates timer interrupts to perform periodic operations in the VM

• GC threads: these different types of threads support parallel and parallel garbage collection

• Compiler Streams: These streams compile during bytecode execution into native code

• Signal Manager Stream: This stream waits for signals to be processed and sends them to the Java Level Signal Processing Method

I cannot find references to Oracle to confirm that their implementation is the same, but these slides from a presentation by Paul Hohenesee at the Sun mentions:

Stream types

• Java, aka mutator

• One VM thread: GC, deoptimization, etc.

• Compiler

• Observer timer

• Low memory monitor

• Garbage collector, parallel collectors

Given that this presentation should be at least 6 years old, the implementation may change slightly, but the components are more or less the same.

Answer 2

1) Each swing application is a java application.

But,

2) Not every java application is a swing application.

This means that every Java application is equipped with a main thread JVM.

In addition , for each swing application to be provided with an event dispatcher thread due to the swing specification ( Java Swing API and Developer's Guide ).

If you do not import the APIs you need, there is no need to get a headache about stopping unnecessary running threads.

Answer 3

Here is a simple way to print 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()); } } 

In addition to the main thread, you will see several other threads :

• Attach Listener
• Finalizer
• Link handler
• Signal Manager

Sometimes one of them:

5. Ctrl-Break Monitoring
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 yet. So, your "main" thread is the only non-demon.

Swing event dispatcher thread is not one of them and will not be launched by default. It will only start after using Swing components.

All of these flows are critical. Just accept their presence. They are good for you .

Answer 4

This is actually a JVM implementation issue not prescribed by the JVM specification. You can assume that each JVM provides your application with at least 1 thread, the main thread. The subject of event dispatch is Swing.

See also javadoc javadoc topic.

Answer 5

In addition to other answers: why not try some programs with several utilities for printing streams. There is an API for listing the main and sub-thread groups (virtually all). Do this using an application that:

• has the main thing and nothing more
• main with several other methods and objects
• main with a class that creates its own thread
• main, which initializes the swing user interface
• web application with simple jsp test page

Code to see all topics fooobar.com/questions/36821 / ... (there are other ways, but it's good to get understanding and work fine in most of the applications that I tried, there is also fooobar.com/questions/36821 / ... )

FYI web application can run swing ui - albeit only for use, if it does it only for the administrator and in sigleton, since the user interface will be displayed on the server. If this makes the user interface for each user of the application, it will quickly run out of memory and will annoy everyone who logs on to the server (provided that the server has a user interface / desktop). So the web application + swing is not included, although it is possible.

Answer 6

I think such threads are similar to other resources, such as heap space, the stack that the JVM provided to every Java application. And the client must work correctly in different threads. Such as Swing related stuff, only in the event dispatch thread.

The common JVM threads mentioned by @Patrick are generated (JVM) during initialization at runtime before the user program starts execution and completes maintenance / housekeeping tasks in the JVM.

Customer customer threads generated from application code cannot directly control system-level threads. Swing-related threads will begin when Swing-related code is not executed for all types of Java programs.

Am I right about this? Where can I find an authoritative link? The JVM specification does not seem to have this.

In addition to the links mentioned by @Patrick, check out the following link:

Runtimeoverview

And if I never use the event dispatch thread, for example, in a console application, can I disable it to save some processor cycle?

An event dispatch theme is created if the Swing application is running. You can control threads created by the user application, not JVM runtime threads.

Answer 7

And if I never use the event dispatch thread, for example, in a console application, can I turn it off to save some CPU cycle?

Ans: No event dispatch is triggered unless your Java application is a swinging application. Thus, you can safely assume that your java does not use the event dispatch stream

Transition to topics: Each thread is a process, the program that you write can be divided into many processes. A process can be defined as an executable program. Threads are mainly used for parallel programming (do not confuse with parallel programming). Also, threads can be defined by software or hardware (a “dynamic” processor). The topics you are talking about here are software threads, and you never care about hardware related threads. If the processor you are using is multi-core, then different threads can run on different cores or on the same one based on the Tomasulo Algorithm