i have many threads running in my application, but
i want to debug just only one thread. i'm using eclipse, is that possible? i just saw that stuff in visual studio and in c#
Thank you for your help and pacience.
Identify the thread that you want to debug and name it using currentThread().setName("myThreadName"). Then set a conditional breakpoint on currentThread().getName.equals("myThreadName").
Take care though as thread pooling can introduce some complications to your debugging process.
If you open up the debug perspective, the window on the top left ("Debug") will list all the threads and let you pause them individually.
Related
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.
Supposed I have an application that can spawn multiple threads if needed for doing tasks ... so nothing special. I use Eclipse to write and debug Java applications. A thread (lets call it "async task") is immediatly respawned after it leaves the run() method (so there is bug and I want to find the reason for this behavior).
My question, if I pause this thread "async task" using the eclipse IDE (debug perspective ..) is there way to find out where this thread was originally started (for example using the Debug view or any other)? Because I want to know who spawns this thread (without making a text search or something like this).
Is there a good way to get this information?
I would set a breakpoint at Thread.start() and enable a condition
Whenever a thread named "async task" is started the condition is evaluated to true and the thread that invokes the start method is paused. Then you can see in the stacktrace from where the call came.
Had a similar problem in production and wrote a litte java agent that logs the stack of every thread start. So the system can run and you get the info live in the log. That helps a lot, when you have many threads. https://github.com/xdev-software/thread-origin-agent
You can't check whether new thread start or not by using debuger since debug will hang your entire JVM.
You can put some logs and check how threads works there.
I'm currently attempting to debug a medium scale (in the 10's of thousands of lines ballpark) Java project which uses both JavaFX and Swing, and I'm hitting some odd exceptions every so often which I'm pretty sure are because of UI code not being called on the correct thread. The stack trace for these exceptions isn't really helpful at all, since they pretty much all originate from the UI drawing thread.
Now, sure I could sit down with a toothcomb and debug every UI call until I find one that's not being called on the correct thread, and keep doing that for the entire project, but that would be an incredibly long task. Is there some form of easier way to do this sort of debugging? For instance, somehow cause UI code to print out a debug message or throw an exception when it's not been called from its appropriate thread?
Running JavaFX and Swing on the same thread might help fix your threading issues.
There is an experimental feature in Java 8 to run JavaFX and Swing on the same thread:
https://javafx-jira.kenai.com/browse/RT-30694
http://bugs.sun.com/view_bug.do?bug_id=8015477
I think -Djavafx.embed.singleThread=true is the command line property setting to enable the experimental single threading system.
I am not sure if the experimental feature is available in the current Java 8 builds, but I think it might be now, so you may wish to try it.
If you need more information on the experimental single threading feature, you could ask the developers on the openjfx-dev mailing list.
Java 8 has better inbuilt reporting of when code is not run on the correct thread, it's not comprehensive, but it might assist you in locating the source of your error, even if you are not using the single threading option.
Some other users running large applications merging Swing and JavaFX reported similar hard to debug threading issues, so you could check those threads to see if your issues have the same cause.
You could turn on thread checks in glass by -Dglass.disableThreadChecks=false. This would switch on the thread checks in the lowest layer of JavaFX which is responsible for working with OS level APIs. In most cases those checks would be sufficient, because most of the calls are ending up in Glass. These checks would be enabled by default soon.
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.
Is there any mechanism within the Eclipse debugging environment to see the state of synchronization locks held and processes waiting?
You can show the state of object monitors in Eclipse's debugger. You can find a short, clear tutorial here. For each thread, Eclipse can show you the monitors the thread owns and those it is waiting for.
Update 2020-01-20: The link above no longer works. Here's a link to cached version on the Internet Archive.
As suggested here you could (if you run the Sun JVM) perform the following steps:
launch jconsole or jvisualvm (both present in the bin-directory of your JDK-installation,
attach to the process you suspect has locked up
go to the Threads pane. There is a "Detect Deadlock" button
Another option: I would suggest add logging in order to "debug" your code. Sometimes it will be more intuitive.