I am working on a Java application which has a threading issue.
While using the applications for some time with Netbeans profiler attached, I can see several threads are created. Most of them finish in some .5 seconds. I could only find SwingWorkers used in the application.
Moreover, the majority of threads displayed by the profiler are normal threads and not SwingWorkers. Unless these threads were created by SwingWorker indirectly, I suspect, some library that the application uses is creating them.
Now I would like to remove this issue. But I could not find a way to determine the source of thread creation. If you can please suggest some other profiler/tool by means of which I can find the source(method) of thread creation.
If using Eclipse and its debugger is an option, you might try the following:
Import the code into a Java project.
Ctrl-Shift-T (Open Type), enter "Thread". The binary source editor for the Thread class opens.
Select all the Thread constructors in the Outline view, use context menu "Toggle Method Breakpoint". That creates breakpoints for the constructors.
Run and debug.
Alternatively
You could get the Yourkit Java profiler, which is also available for evaluation. It can show the threads created in an application including their stack traces (also after the thread finished). It does not show where the threads were created, but the stack trace of the threads might give you some clues about the involved libraries.
JProfiler can do that. The thread monitor view shows the stack trace where a thread was created - if CPU recording was active at that time:
Disclaimer: My company develops JProfiler
Related
Back when I was using Eclipse for Android development, it was possible to select a thread and freeze it - so it would not run. This allowed the debugging of one thread without interruptions from other threads.
How can a thread be frozen - prevented from running - in Android Studio. I have found the list of threads but I do not see any controls for freezing a thread.
--------< additional information >----
2 people didn't understand the question, so let me try again.
In Eclipse, when debugging a multi-threaded app, you can suspend and resume threads in the debugger.
In the above image, you see the Debug view, showing a list of threads. Right mouse on one of these threads and in the menu is Resume, Suspend, Terminate. These menu actions apply to the selected thread.
When debugging multi-threaded apps, sometimes it is essential to suspend a thread temporarily.
In Android Studio, I can get a dump of the threads, and selecting each one shows me its stack trace on the right.
But I can not find any way to suspend and resume the thread.
Again this is a critical requirement of a debugger.
Does anyone know how this suspend/resume can be done in Android Studio???
I haven't looked under hood to be sure of this, but I imagine that it is using JVMTI. This "hooks into" the JVM at a lower level than is possible through the APIs in the Java class libraries.
And, before you ask:
I doubt that JVMTI is available on a real Android device. (I don't know if there is an equivalent.)
A Java application using JVMTI to control its own threads would be a really bad idea. Think about the reasons that Thread.stop and friends were deprecated, and multiply by 10.
I've just started programming in Java, and I'm interested in how computers distribute their CPU load. I have made a very basic program that creates a window and makes a box and line move. While testing this, I looked at Task Manager; Task manager said I was using ~1% of my CPUs. however, when I ran my program, the CPU usage went up to ~36% (I only started the program, nothing else). Can anyone tell me what is going on here, please?
You think that your program has only one thread, but in reality every Java program has lots of threads. GUI apps have the Event Dispatch Thread, garbage collection has its own thread etc. You can use a profiler (like the VisualVM that is in the JDK) to see all the threads in your app.
Or you can see them programmatically, see Get a List of all Threads currently running in Java
with threads & swing, the event queue (event dispatch thread) is broadly presented & discussed.
However, when examining the thread states with a Swing application, there's also a thread named Swing-Shell. With brief googling I couldn't find much details, mostly thread stack traces with bug reports etc.
Can somebody describe shortly what that thread does. Or even better, does somebody have some link to some documentations
EDIT: I was asking too fast without enough details, sorry. I was going though various
JFileChooser issues and a thread named "Swing-Shell" occurs there, having
something to do with Windows COM services for file system.
A sample stack trace within a deadlock problem can be found at
Sun Bug #6741890.
(The thread stack trace starts with sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run).
With closer inspection with jconsole, I noticed that the thread isn't present there until
I have used JFileChooser (JFileChooser for example; the Swing-Shell thread will probably be started
by any components using Win32ShellFolderManager)
The thread seems to exist also after the usage of JFileChooser.
So, answering to myself, the thread seems to be a separate thread used for COM services with
file-related operations (with Windows only? ). If somebody can provide more details, welcome =)
The number, purpose and naming of initial threads is implementation dependent. On my platform, the event dispatch thread (EDT) is named AWT-EventQueue-0.
Addendum: The only other reference I found says, "A Motif application uses a shell widget to communicate with the window manager." Are you using a Swing library of some kind?
As suggested above, a thread dump might be illuminating. Recent versions of NetBeans' profiler include a save button; I've attached a snapshot of the threads in a typical busy demo.
I have a web application running in a jboss application server (But it is not jboss specific so we could also assume it is a tomcat or any other server). Now I have the problem that one thread seems to be in dead-lock situation. It uses 100% CPU all the time. I have started the server with enabled debug port and I can connect Eclipse to it. But the problem is: There are a lot of threads running. How can I find the right thread? I know the process id (from Linux "top" command) but I think this will not help. Do I really have to open each thread separately and check what they are currently doing? Or is there a way to filter the threads for "most active" or something like that in Eclipse?
You can try and generate a thread dump (CTRL+Break as shown in this thread).
Or you could attach a JConsole to the remote session (so leaving Eclipse aside for now), monitor the threads and generate a thread dump.
alt text http://www.jroller.com/dumpster/resource/tdajconsole.png
Seems to be you need to narrow things down to the code that has the bug by identifying which thread is eating the CPU first, then which code is being executed by that thread and at that point you can remote debug.
I would suggest using something like JProfiler, jvisualvm, jconsole or something similar. Using one of these tools will allow you to get some insight into what the thread is doing and should allow you to sort the threads by cpu cycles used so you kind find the offending thread quickly.
It is Hallowe'en after all.
Here's the problem: I'm maintaining some old-ish J2EE code, using Quartz, in which I'm running out of threads. jconsole tells me that there are just short of 60K threads when it goes pear-shaped, of which about 100 (!!) are actually running. Intuition and some googling (see also here) suggest that what's happening is something (I'm betting Quartz) is creating unmanaged threads that never get cleaned up.
Several subquestions:
It there a tool that I can use easily to trace thread creation, so I can be certain the issue is really Quartz?
Most everything I've found about similar problems references Weblogic; is this a false lead for Tomcat?
Does anyone have a known solution?
It's been years since I did J2EE, so I wouldn't be too surprised if this is something that can be solved simply.
Update: It's clearly increasing threads without bound, see this plot from jconsole.
Try to increase the logging level of org.quartz.simpl.SimpleThreadPool to debug to get more information.
If that does not work, try a logging listener. Quartz has a JobListener interface, which is specified in its tutorial. A listener can help you trace job execution. Maybe jobs just don't finish and get deadlocked.
Configure org.quartz.threadPool.threadCount to stop running out of threads.
update:
Also, you might want to take a thread dump and see the thread stats. visual vm has a plugin called TDA, or you can use Thread dump analyzer directly.
Just in case, check the quartz version to see if there is no known bug.
Have you had a look with jvisualvm - it gives some more information.
Also, get stack traces to see what the threads are actually waiting on. You might have an aha-feeling right there.