In applications where I use threads I usually create them, I start them and wait for them to end up using the join method.
I observe that there is a time when the main process is inactive and I do not know the reason. In the attached graphic it can be verified that there are four threads working and the main thread presents a time of inactivity. It's represented in violet in the next graphic:
Why does that downtime appear? Thank you
I edited and compiled your example and wrote JFR. In JMC I see the same as in any other multithreaded java application. So I think the problem is in profiler tool.
May be it stops main thread in unusual way for monitoring purposes. May be it is just wrong. Use Oracle Java Mission Control. This tool have to be right.
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
I am looking for a java (desktop) profiler that shows thread timeline with details on what methods are being executed by each thread at each time point. A desktop java analogue for Android's traceview would be excellent.
The problem I want to solve is to find out what my threads are wainting for. I see that 3 worker threads are waiting for main thread to complete something (there are several lenghy tasks in there) and I need to determine what task is the longest in main to optimise (or parallel) it.
This Netbeans profiler screenshot probably explains the question that I need answered:
This is what I'd like to see. The problem is, it's a tool for android
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.
I'm developing an artificial intelligent program to explore a given space for resources.
I'd like to run multiple scenarios in order to collect data and output to a file.
I used the "multiple runs" option in the gui and i do stop() when one module run is finished (all the resources have been explored). The problem is when It runs the model a second turn, it doesn't work properly.
What I mean is that after running once I always need to kill the application by exiting because the restart option doesn't work properly.
Is there anything that "restart" forgets to do? Because if I exit the application and run it again it works perfectly
Edited so it's more clear:
I use the Repast platform in order to simulate an exploration to Mars. I have 3 kinds of agents, scouting, digging and transporting. They communicate among them to schedule tasks and other things.
The first time I run the simulation everything runs smoothly. And when all the mineral resources of the planet have been explored I restart the model and try again so I can collect data.
The problem is, when I use the "restart" option the Simulation doesn't run well. But if I exit (not restart) and run it again it works fine.
What I'd like to know is if the restart option of Repast GUI misses any steps..
Thanks in advance
PS: If you guys think that it's absolutely necessary I can post some code...but the project is quite big
Don't use Thread.stop() method. It is deprecated. Thread.stop is being deprecated because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors was in an inconsistent state, other threads might view these objects in an inconsistent state. Such objects are said to be damaged. Threads operating on damaged objects can behave arbitrarily, either obviously or not. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that the program may be corrupted. The corruption can manifest itself at an unpredictable time after the damage occurs. Substitute any use of Thread.stop with code that provides for a gentler termination.
http://docs.sun.com/app/docs/doc/805-4031/6j3qv1of1?a=view
Consider thread stopping either via Thread.interrupt() or via setting cancel flag. Look at Java Concurrency in Practice, Section 7.1. Task Cancellation.