I recently ported a fairly large application from C# to Java. It ought to have about 6 main threads running and lots of timers being fired (but each executing only briefly). I make use of the Timer class and call myTimer.schedule(new TimerTask() { ...
Now that I'm at the end of the port, I'm having a problem debugging the application in Eclipse, especially lately. I set a breakpoint: Eclipse will hit it but I can't step through at that point. I don't think I can look at variable values or stack trace or anything.
I see my list of threads going crazy, and based on output statements I've written, I can see that Thread.activeCount() gets to be over 200 threads. I am curious as to whether this is my debugging problem. Have I overloaded Eclipse to the point that it goes crazy?
From the threads I can actually see, most of them are my Timers that have been run. Somewhere I read that the JVM will keep those alive even if you cancel them (?). Anyway, if it's including all of the timers I've fired then perhaps over 200 threads makes sense.
I did once today also see an Eclipse "out of memory" error.
Any advice? Thanks.
Related
I have a JavaFX 8 app that is occasionally hanging/freezing. I feel I've ruled out many causes of the problem, but it's still happening.
Unfortunately I cannot reproduce the freeze/hang on demand. It actually only happens (so far) on my colleague's computer. It can happen not long after the App has been running, or it may happen after many hours, or it may not happen at all. It does not happen after any user initiated event (such as pressing a button).
I have a few background threads running that read data from sockets and update the JavaFX UI. These updates are always done via the Platform.runLater() method.
The background threads may read many hundreds of data updates per second, so I have applied throttling to prevent too many updates on the UI, as suggested here: Throttling javafx gui updates
The user can initiate some long(ish) tasks, which are run on the JavaFX UI thread, or using the Task method. I know and expect the JavaFX UI to block/freeze when calling a method with long execution time on the JavaFX UI thread. But such calls are only made by the user pressing a button and as stated above, the freeze occurs without the user interacting the the App in any way.
I have caught the freezing (twice) on my colleagues computer and inspected the process in JConsole and VisualVM. The thread dump showed no deadlocks. When I compare the thread dump with a non-frozen JavaFX App thread dump, there are no obvious differences.
It appears that only the JavaFX UI is frozen. The background threads continue without error.
The CPU is not high and the computer is not running slow when the freeze occurs.
My App code consists of many classes, so it's not straight forward to include it here, especially as I don't know which method causes to freeze. And therefore my question is rather broader than I would like:
Given the assertions above, do you have any suggestions as to what
might be a cause of such an error?
Given the assertions above, do
you have any suggestions as to what might be another way to trace
such an error?
Thanks to John16384 and Mipa for their replies...
I use the javafx-maven-plugin Maven plugin, so the JavaVM arguments by including:
<jvmArgs>
<jvmArg>-Dprism.verbose=true</jvmArg>
<jvmArg>-Dprism.order=sw</jvmArg>
</jvmArgs>
in my plugin configuration. Since including this, we haven't had the freeze for a couple of days. I'm hoping this is the final fix!
Have you tried AOP ?
Aspect Orientated programming
It in your case would allow you to run a method before and after every method you use, if you logged something if these times were greater than a certain time, then you could determine which bit of code was causing it e.g. log if the time inside a method is greater than 5 seconds
See here for a tutorial to just that
My application run some complex threads that fetch maps in a background thread and draw them. Sometimes if I run the app for a couple hours on a slow network I seem to be getting it into a weird state where all my threads status are showing TimedWait or Wait (except the ones that are Native such as main).
What is the cause of this? How can I debug it? I am absolutely lost and I know this is a bit of a general question but I would appreciate it if someone could point me to the right direction. EG:
How to pin point the cause of the problem.
What king of issues generally cause all the threads to lock up?
Anybody seen anything similar?
Thanks
A timed wait is simply a thread which is blocked on some O/S level call which has a timeout specified, such as a simple wait primitive (Object.wait()) or a socket operation (Socket read()/write()), a thread queue etc. It's quite normal for any complex program to have several or many of these - I have an application server which routinely has hundreds, even thousands.
Your threads may be backing up on non-responsive connections and may not be misbehaving at all, per se. It may simply be that you need to program them to detect and abort an idle connection.
Click on each of the threads which you are concerned about and analyze their stack trace for how they got there.
Most decent profiling tools (and application containers) will have the option of printing a full stack trace, and more modern ones will do a dead-lock and live-lock analysis for you. The JVisualVM tool distributed with Sun's JDK and available on the net as VisualVM will do this and it's very effective. Most decent profilers will also show lock acquisition in the stack trace (yours, above, is not in that view).
Otherwise, you are looking for two or more threads contending for the same lock or acquiring the same locks in a different order. You may need to do this manually by actually examining the source and annotating your stack trace, but you should be able to whittle down likely candidates if your tool doesn't point right to the conflicting threads.
I am developing a software with java, it creates a thread upon receiving an event (from sensors). the time-to-live of these threads is very small (< 1 second)
The sensor sends maximal 10 events/minute.
This app works fine for most of the time. but sometime it hangs.
When looking at the eclipse debugger, I find out that there are to many threads and most of them are "Thread[garbage collected]" (about 800 threads #_#)
I don't know if that bug is caused by dynamic-creating-threads in my code or other bugs?
EDIT:
The problem is indeed caused by creating too many threads. I have logged all sensor's events with timestamp and there are some points it creates about 1200 events/minute (damn!).
I also wrote a small java program which creates as many threads as posible. At ~4100th thread (well, wooden computer) , jvm crashes. It does not hangs like my app does :-?.
Therefore I suppose that there are (maybe) rare conditions while creating threads dynamically and it causes the garbage collection threads hang?
Don't create a new thread for each event that is received. Instead, use the classes from the java.util.concurrent package.
Create an ExecutorService (using one of the static methods in class Executors) and submit jobs for handling events to the ExecutorService. The ExecutorService is a thread pool that manages the threads for you.
I had a similar problem in NetBeans. After a while, the program would hang with lots (maybe 500) of suspended threads. However, when run outside the debugger it worked just fine. I don't think I ever got more than a couple hundred threads going at once running when running outside, but the program did tend to start them at a furious rate. My suspicion was that the debugger never shut down a thread and could only handle so many.
My experience so far is that the JVM handles vast numbers of rapidly starting and stopping threads very well, but that the NetBeans debugger (several versions ago now, one of the 6's) did not.
One day our java web application goes up to 100% CPU usage.
A restart solve the incident but not the problem because a few hours after the problem came back.
We suspected a infinite loop introduced by a new version but we didn't make any change on the code or on the server.
We managed to find the problem by making several thread dumps with kill -QUIT and by looking and comparing every thread details.
We found that one thread call stack appear in all the thread dumps.
After analysis, there was a while loop condition that never go false for some data that was regularly updated in the database.
The analysis of several thread dumps of web application is really tedious.
So do you know any better way or tools to find such issue in a production environment ?
After some queries, I found an answer in Monitoring and Managing Java SE 6 Platform Applications :
You can diagnose looping thread by using JDK’s provided tool called JTop that will show the CPU time each thread is using:
With the thread name, you can find the stack trace of this thread in the “Threads” tab of by making a thread dump with a kill -QUIT.
You can now focus on the code that cause the infinite loop.
PS.: It seems OK to answer my own question according to https://blog.stackoverflow.com/2008/07/stack-overflow-private-beta-begins/ :
[…]
“yes, it is OK and even encouraged to answer your own questions, if you find a good answer before anyone else.”
[…]
PS.: In case sun.com domain will no longer exists:
You can run JTop as a stand-alone GUI:
$ <JDK>/bin/java -jar <JDK>/demo/management/JTop/JTop.jar
Alternately, you can run it as a JConsole plug-in:
$ <JDK>/bin/jconsole -pluginpath <JDK>/demo/management/JTop/JTop.jar
Fix the problem before it occurs! Use a static analysis tool like FindBugs or PMD as part of your build system. It won't find everything, but it is a good first step.
Think of using coverage tools like Cobertura.
It would have shown you, that you didn't test these code-paths.
Testing sth. like this can become really cumbersome, so try to avoid this by introducing quality measurements.
Anyways tools like VisualVM will give you a nice overview of all threads, so it becomes relatively easy to identify threads which are working for an unexpectedly long time.
I am running a Java Program in command prompt
The normal course is after successfully executing the program it comes back to prompt .. what are the possible reasons it will not come back to prompt after successfully executing the program
why is it not coming back to prompt after execution
usually it comes back but sometimes it doesn't...
This sounds like a race condition. Something in your application's shutdown sequence is non-deterministic, and it works or does not work depending on various platform specific (and possibly external) factors. There is probably no point figuring out what those factors are (or might be), since it won't help you fix the problem.
Only difference is in RAM hard disk capacity mine is slower.. Can it be possible reason?
These could be factors, but they are not the cause of the problem. So focus on figuring out what makes your application non-deterministic.
As others have said, without more information (and relevant code) we can only guess.
When the application has failed to shut down, get it to give you a thread dump. Or try shutting it down while it is attached to a debugger. These may allow you to get some clues as to what is going wrong.
Finally, the brute force solution is simply to have the main method (or whatever) call System.exit(0) on its way out. But beware of the possibility of files not being flushed, etc if you do that.
Because it's not finishing. If it's sometimes happening and sometimes not, my instinct is that you have some sort of race condition. Probably one of your cleanup steps is hanging if another action has or hasn't been taken.
Without source code this will be hard to debug.
There could be an active thread still running which is not in "daemon" mode. For example, if you have a Swing GUI and all of the frames are closed the Event Dispatch thread is still active so the JVM will not exit.