I have a Java program which sometimes works OK untill the very end, but sometimes just hangs in a random moment and doesn't react to Ctrl+C or Ctrl+Break. Process doesn't use CPU, so I guess it isn't something like infinite loop (I actually cannot think of places in my program where this kind of loop may occur). I tried to get thread dump to see if there are any deadlocks, but Ctrl+Break doesn't work and jstack doesn't work also (I've read that there is -F option, but it isn't available on Windows). Also I tried to connect to a hanged process with Java Visual VM - doesn't help too (just says 'Connecting...' forever).
I tried to start my program, connect with Java Visual VM to it at the beginning and see how threads visualisation will look like in a moment when program hangs. My programm died after about 50 min and all info which I was able to see was about this period of time (e.g. a timeline diagram stopped changing and the last time mark was 49:23), but Java Visual VM was still connected to a process. I pressed Thread Dump button, it worked, but there was nothing 'criminal' on the dump it provided. So I guess maybe it is not actual thread dump, it is something that Java Visual VM was able to get before process hanged.
What else can I do to find out what's going on in my programm and fix it?
I tried to run it with JDK 1.6.0_07 and 1.6.0_16. I'm using Windows Vista Enterprise SP1, 64-bit.
Ok, here is what I see, not sure if it is helpful at all or not but...
1) You have a hole lot of Threads that are like this:
2) You have another Thread that looks like this:
Both of these types of Threads are Blocking waiting to get the monitor lock for the same Object: 0x00000000a952e968. They are just doing it in 2 different places - most on line 444 and one on line 378.
Another Thread looks like this:
It appears to have been locked on the Object (0x00000000a952e968) but is now waiting on a condition. That condition is not something you coded - I think it is usually a JVM - based lock, like one used for loading a class. This smells a little of bugs 629887 and 6401751, but hard to say for sure. In both those cases it seems the bug was sporadic.
The major Thread I see that has problems I would be concerned about (meaning has something which you should be able to fix) is this:
It looks like you have a SwingWorker which is locked on a ReentrantLock, then took lock on another Object, and then called wait() on the other Object. This nested locking can be a difficult task to perform. If this SwingWork holds on to a the ReentrantLock, and then is waiting on another monitor, then any other Thread which attempts to get a hold of the ReentrantLock can't do so. If that second Thread already owns the lock to the monitor (0x00000000aa1c9030) the SwingWorker is waiting on then you are stuck in a deadlock situation you can't get out of. So tread very carefully when working with nested locks.
I can't tell if that is what is going on here or not. It is one possibility. Another is that this is some incarnation of one of those bugs I pointed out (most likely the 6298877 one rather than the other). There could obviously be more to it that I am not seeing...