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.
Related
I have an android application where I am performing some operations in background threads. For some reason my app becomes extremely slow and unresponsive after being used for few minutes. I am suspecting that it is because of some background thread, so I want to monitor the threads that my app is creating. However, I couldn't find a suitable tool where I can see and monitor those threads. Is there any way I monitor the background threads at runtime.
You can use DDMS to monitor the Threads at runtime. Look at the DDMS document .
I'm not sure about how can you see threads but you can try following
Enable Strict mode in developer setting, you will see screen flashing red on heavy operations.
Add logs to your thread and print progress with time, by this you can know which method is taking time.
More on strict mode here:
https://developer.android.com/reference/android/os/StrictMode.html
You can use the build in tools to profile the app.
See here : https://developer.android.com/studio/profile/traceview.html
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
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
I am debugging an application with lots of threads. My breakpoints are set to suspend the whole VM.
When a thread hits one of the breakpoints, I then want to use Step Over. But this appears to resume the whole VM, until that step completes.
It'd really help if I could step just the single thread that hit the breakpoint.
Is there any way to do this in IntelliJ 11.1 / Java 6? (Hope I'm not missing something obvious...)
This feature was added in IntelliJ 16 (the issue CrazyCoder referenced in his answer was resolved)
More details here:
https://blog.jetbrains.com/idea/2016/02/intellij-idea-16-eap-improves-debugger-and-adds-git-worktree-support/
NetBeans can resume individual threads. While in debug mode, you can resume a thread from the left thread list by pressing a small button shaped like Play (►) near the thread.
Currently there's no such possibility because it may lead to deadlocks. You may vote for IDEA-43728 though.
We are experiencing a bug we cannot track down where something is freezing up our swing thread (it's been almost 2 weeks now and no real results) - we are experienced Swing programmers but we have a huge program and believe it to be in some of the legacy code
I am wondering, is there any way outside of editing the actual EventQueue class in the JDK which will allow us to view all pieces of our code currently running on the Event Dispatch Thread - maybe some type of tool which will allow us to view things as they enter or leave the event dispatch thread?
One interesting approach is to extend EventQueue and push() it, as shown here.
Logging everything that passes through the Event Dispatch Thread seems a cumbersome way to diagnose a freeze. Wouldn't it be easier to wait until the problem occurs, and then ask the Event Dispatch Thread what it's doing now? One way to do this is to enable JMX monitoring, connect to your running process with a JMX client such a VisualVM (which ships with the JDK), wait for the problem to occur, and then take a thread dump.
In case you still wish to log everything the Event Dispatch Thread is doing, you can do this by:
In Eclipse, launch the application in debug mode.
Create a breakpoint on EventQueue.dispatchEvent, right-click it, select "properties", check "condition", and enter the following "condition":
System.out.println(arg0);
return false;
It might be good idea to try BTrace to instrument the EventQueue and capture stack traces each time something gets added. I think the latest VisualVM has plugins that will allow you to instrument a running JVM with a BTrace script.
If you're using the Oracle JRE, there is a TracedEventQueue included already. You can install it as mentioned before:
EventQueue eventQueue = Toolkit.getDefaultToolkit().getSystemEventQueue();
eventQueue.push(new TracedEventQueue());
Note, this will output a lot of output...