Should all of these threads execute by default? And do they keep my JVM?

Question

I have a question about threads that run by my application at runtime and their status.

I have a Swing application and I noticed a couple of weird behaviors in some test cases using Java VisualVM. Having started my program for 30 minutes, doing nothing (I just started and left it there), I noticed the following.

First of all, on the Threads tab, I see a lot of live streams.

Reading (among other things) Default threads, such as DestroyJavaVM, a link handler, a signal manager, and What are these threads allocated when a Java application starts execution? I understand that most of these threads have a very good reason. (I'm still trying to figure out "RMI TCP")

I have doubts, however, in their condition. Is it normal that the first six of them were Running 100% of the time?

Also, can any of these threads explain heap consumption as follows?

I noticed that many instances of HashMap $ Entry and TreeMap $ Entry are referenced and created by libraries originating from sun.rmi. * and I thought this could be due to RMI TCP streams ...

And last but not least, if I try to delete () my main JFrame, the frame itself will disappear, but the application will still run .... could these threads be the reason (or part)?

Thanks to everyone.

Answer 1

I'm still trying to figure out what is "RMI TCP"

These streams are used to receive and process JMX connections through RMI. You are using it right now, looking at JVisualVM. Did you notice your IP address in the workflow name?

I have doubts, however, in their condition. Is it normal that the first six of them were able to start 100% of the time?

Just because a thread is running does not mean that it is running and consuming CPU time. Quoting Thread.State :

• NEW - a thread that is not already running is in this state.

• RUNNABLE . In this state, a thread running in the Java virtual machine is running.

• BLOCKED . In this state, a thread is blocked waiting for the monitor to lock.

• WAITING . In this state, a thread that expects an indefinite period for another thread to perform a specific action.

• TIMED_WAITING - a thread waiting for another thread to complete an action before the specified timeout is in this state.

• TERMINATION . A stream is in this state.

As you can see, this list does not mention waiting for sockets like I / O. Topics that complete this task are still marked as runnable. Obviously, waiting for data does not consume the processor. Also, the connection that receives the stream starts while it does nothing. It will be woken up when the client tries to establish a new connection.

Also, can any of these threads explain the heap consumption, for example the following:

Your heap intake is normal and healthy. The shape of the saw blade is determined by the collection of debris, which does not require any more items. The JVM also finds out that your heap consumption is pretty constant, so it reduces the maximum heap size because it thinks you don't need that much (orange graph).

And last but not least, if I try to delete () my main JFrame, the frame itself will disappear, but the application will still run .... could these threads be the reason (or part)?

This is because you are closing JFrame , but not the whole application. Swing EDT ( event dispatch flow ) is still working. But this has nothing to do with it. Just use:

 jFrame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE ); 

on your main frame.

TL DR

Your application is completely excellent considering the consumption of threads and memory. Do not worry!

see also

• Why is sawtooth graphite?
• System.exit (0) vs JFrame.EXIT_ON_CLOSE