2

A scheduler starts a java application, which ends without any problem most of the time.

Sometimes however, the java.exe process doesn't end. As far we can see, the java application itself has ended, but the java.exe process not. There is not solution but to kill it.

The Process Explorer shows only one thread (in sense of the OS, not of java) for this process. It hat the state "Wait:WrKeyedEvent" and following stack

ntoskrnl.exe!KeWaitForMultipleObjects+0x0a
ntoskrnl.exe!ExfReleasePushLock+0x8ec
ntoskrnl.exe!_misaligned_access+0x331
ntdll.dll!ZwReleaseKeyedEvent+0xa
ntdll.dll!RtlFindMostSignificatBit+0xa0
ntdll.dll!RtlProcessFlsData+0xdc
ntdll.dll!LdrShutdownProcess+0xa9
ntdll.dll!RtlExitUserProcess+0x90
msvcrt.dll!wcstoui64+0x2fa
jvm.dll!JVM_Clone
jvm.dll!JVM_Clone
jvm.dll!JVM_Clone
jvm.dll!JVM_Clone
jvm.dll!JVM_Clone
jvm.dll!JVM_FindSignal
msvcrt.dll!srand
msvcrt.dll!ftime64_s
kernel32.dll!BaseThreadInitThunk
ntdll.dll!RtlUserThreadStart

Has somebody an idea, why java.exe does not end?

Screenshot of the process explorer:

Edit about the response "one no-deamon thread is still running"

The problem is not a remaining thread in the Java application. An Java application has several running (Java-)threads, even if only one of it is a no-deamon one.

This is also true for a ShutdownHook. See this example:

/** Main class */
public class TestShutdown
{
    public static void main (final String[] args) throws FileNotFoundException
    {
        Runtime.getRuntime().addShutdownHook(new HookThread());
    }

}

/** The hook Thread */
final class HookThread extends Thread
{

    public HookThread()
    {
        super(HookThread.class.getName();
    }

    @Override
    public void run()
    {
        try
        {
            sleep(5000l);
        } catch (final InterruptedException ex) { throw new Error(); }

        final StringBuilder sb = new StringBuilder();
        Map<Thread, StackTraceElement[]> traces = Thread.getAllStackTraces();
        sb.append("Number of threads: " + traces.size() + "\n");
        for (final Thread th: traces.keySet())
        {
            sb.append("-----------------\n");
            sb.append(th.toString()+"  "+ (th.isDaemon() ? " (deamon) " : " (not deamon) ") + "\n");
            final StackTraceElement[] trace = traces.get(th);
            for (int j=0; j < trace.length; j++)
                sb.append("  at " + trace[j] + "\n");
        }
        System.out.println(sb.toString());
    }

}

and the result:

Number of threads: 6
-----------------
Thread[Reference Handler,10,system]   (deamon)
  at java.lang.Object.wait(Native Method)
  at java.lang.Object.wait(Unknown Source)
  at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
-----------------
Thread[Finalizer,8,system]   (deamon)
  at java.lang.Object.wait(Native Method)
  at java.lang.ref.ReferenceQueue.remove(Unknown Source)
  at java.lang.ref.ReferenceQueue.remove(Unknown Source)
  at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
-----------------
Thread[HookThread,5,main]   (not deamon)
  at java.lang.Thread.dumpThreads(Native Method)
  at java.lang.Thread.getAllStackTraces(Unknown Source)
  at HookThread.run(TestShutdown.java:59)
-----------------
Thread[Attach Listener,5,system]   (deamon)
-----------------
Thread[DestroyJavaVM,5,main]   (not deamon)
  at java.lang.Object.wait(Native Method)
  at java.lang.Thread.join(Unknown Source)
  at java.lang.Thread.join(Unknown Source)
  at java.lang.ApplicationShutdownHooks.runHooks(Unknown Source)
  at java.lang.ApplicationShutdownHooks$1.run(Unknown Source)
  at java.lang.Shutdown.runHooks(Unknown Source)
  at java.lang.Shutdown.sequence(Unknown Source)
  at java.lang.Shutdown.shutdown(Unknown Source)
-----------------
Thread[Signal Dispatcher,9,system]   (deamon)

(By the way: in this case we have two not deamons: the hook thread and the DestroyJavaVM, which has started the hook and waits until it ends.)

But moreover: my hanging java.exe has only one OS-thread! And it's clear that the program java.exe must hava more threads as the application which is running in its virtual machine... (whith the above programm, 6 Java-threads are running in the VM but the java.exe process itself hat 17 OS-threads.)

Olivier Faucheux
  • 2,520
  • 3
  • 29
  • 37
  • 1
    Within your java Installation you have available (from 1.6) jvisualvm which allows you to connect to a Java process. Try to select your java proccess, go to thread tab to see which threads are running, even you can perform a Thread Dump and attach to the question wich can be very helpful. – alphamikevictor Mar 19 '15 at 11:43
  • I've already tried to debug the process. But it is not possible. Jstack could not attach to the application. It is logical, as the windows process only have a thread (instead of several for "still running" applications). The java.exe is in my case something like a zombie... – Olivier Faucheux Mar 19 '15 at 13:31
  • I like the vmmap program to look into process details on Windows, it also shows the memory used by the individual threads. Maybe you find something interesting with it. – lbalazscs Mar 20 '15 at 14:39

2 Answers2

2

This can happen if a shutdown hook or a finalizer does not complete. Do you have shutdown hooks or do you have Runtime.runFinalizersOnExit enabled?

Anyway, if you are the developer, you can start an extra thread that monitors what other threads are doing. See Get a List of all Threads currently running in Java

Community
  • 1
  • 1
lbalazscs
  • 17,474
  • 7
  • 42
  • 50
  • basically, you duplicated my answer. Thats no problem but please explain it a bit more since it apparently is necessary. – specializt Mar 19 '15 at 15:02
  • 1
    @specializt You wrote nothing about shutdown hooks, finalizers. This could be a reason for having only one thread in the app, while your answer didn't explain this fact. – lbalazscs Mar 19 '15 at 16:12
  • hence : your statement is void. – specializt Mar 19 '15 at 16:33
  • 1
    @specializt I meant that the shutdown hook thread is the single thread that the OP is observing. – lbalazscs Mar 19 '15 at 16:37
  • 1
    @specializt Well, if you meant shutdown hooks/finalizers on exit, you should have written so. But if you meant "normal" threads, then your answer is definitely wrong, because in normal state each app has lots of threads. Just check the number of threads in a hello world app. – lbalazscs Mar 19 '15 at 18:12
-1

Your java application does not end because some thread in it loops forever or has a pending lock on a resource - thats proof of a bug, you need to contact the java application developer and show him your current problem.

For starters : its generally a good idea for applications which are used in a productive environment to have some form of watchdog - there are several, well-tested libraries for that kind of purpose -- like Apache commons Watchdog. Classes like these simply suspend/wait until a timeout occurs - at which point they will call your provided function, it is advisable to call System.exit(1) in that function, effectively forcing a shutdown. This works because the watchdog is a daemon thread which will get killed once everything else is already "dead" - so the watchdog will never fire if your application ends within a pre-set timeout.

specializt
  • 1,913
  • 15
  • 26
  • I don't think so, as the java.exe process only have one OS-thread (see above). I've already checked my code (I'm the java application developer and know what a watchdog is.) – Olivier Faucheux Mar 19 '15 at 13:36
  • 2
    That seems like a normal wait condition, not a deadlock. The common understanding of deadlock involves contention between multiple entities. Do you have a citation for an alternative definition that you believe is authoritative? – erickson Mar 20 '15 at 17:53
  • wait = lock = thread suspension = thread yield = NOP. Even if you appear to write a single-thread application in java it will not be singlethreaded - there is at least one additional thread which waits for your main thread to terminate. This is true for almost all high-level languages, if you want to avoid OS-specific multithreading you will most likely need to use lower-level languages like C in which you can easily (!) force your process to have only one single thread. You can test that yourself with Eclipse, a recent JDK and the debug perspective. – specializt Mar 20 '15 at 19:00
  • Even your application has several threads and one of them indefinitely waits on a condition, it doesn't mean that two threads (or more) blocks *one other*. Please take the time to read what a deadlock is before critizing all other developers for what they _know_, and not allege. – Olivier Faucheux Mar 22 '15 at 12:20
  • You basically just said that threads which block each other arent called deadlock. – specializt Mar 22 '15 at 12:22