Should all these default threads be Running? And do they keep my JVM alive?

Question

I have a question regarding the threads that my application spawns during execution and on their status.

I have a Swing application and I noticed a couple of strange behaviours in some test scenarios, using Java VisualVM. Running my program for 30+minutes doing nothing (just started and leaving it there running) I noticed the following.

First of all, in the the Threads tab I see a lot of alive threads.

Reading (among other things) Default threads like, DestroyJavaVM, Reference Handler, Signal Dispatcher and What are these threads which are spwaned when a Java application begins its execution? I understand most of these threads have a very good reason to be there. (I am still trying to figure out the "RMI TCP" ones)
I have doubts however on their state. Is it normal that the first six of them have been in Running state 100% of time?

Also, could any of these threads explain a heap consumption like the following?

I noticed that a lot of instances of HashMap$Entry and TreeMap$Entry are referenced and created by libraries originating from sun.rmi.* and I thought it could be related to the "RMI TCP" threads...

Last but not least, if I try to dispose() my main JFrame, the frame itself will desappear, but the application will still be running....could those threads be the reason (or part of it)??

Thank you everybody.

Answer 1

I am still trying to figure out the "RMI TCP" ones

These threads are used to accept and handle JMX connections via RMI. You are using one right now when looking at JVisualVM. Have you noticed your IP in the worker thread name?

I have doubts however on their state. Is it normal that the first six of them have been in Running state 100% of time?

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

• NEW - A thread that has not yet started is in this state.

• RUNNABLE - A thread executing in the Java virtual machine is in this state.

• BLOCKED - A thread that is blocked waiting for a monitor lock is in this state.

• WAITING - A thread that is waiting indefinitely for another thread to perform a particular action is in this state.

• TIMED_WAITING - A thread that is waiting for another thread to perform an action for up to a specified waiting time is in this state.

• TERMINATED - A thread that has exited is in this state.

As you can see this list does not mention about waiting for I/O like sockets. Threads performing this task are still marked as runnable. Clearly waiting for data does not consume any CPU. Also the thread accepting connections is runnable, while it does nothing. It will be woken up when the client tries to establish a new connection.

Also, could any of these threads explain a heap consumption like the following?

Your heap consumption is normal and healthy. The saw-tooth shape is caused by garbage collection removing no longer needed objects. JVM also figures out that your heap consumption is pretty constant so it keeps reducing the max heap size as it thinks you don't need that much (orange graph).

Last but not least, if I try to dispose() my main JFrame, the frame itself will desappear, but the application will still be running....could those threads be the reason (or part of it)??

That's because you are only closing a JFrame, but not the whole application. The Swing EDT (event dispatching thread) is still running. 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 fine, if threads and memory consumption is taken into account. Don't worry!

See also

• Why a sawtooth shaped graph?
• System.exit(0) vs JFrame.EXIT_ON_CLOSE