Good Day to all:
My job is to create custom tools for our customers. My employer has a flagship product that we sell that has a Java interface. I then build tools (with Java) for our customers to make life easier for them. These tools run as plugins launched from within the Java interface.
My problem is that, during normal operation, I like to use SwingWorkers to do things. During debugging, I began to notice (with the NetBeans debugger) that even though a given SwingWorker was done, the thread was still running. Normally, this would not concern me, but I then began to notice that, even if the tool I was working on was closed, the Swing Worker was still hanging out in the pool. If I closed the primary application, of course all the threads would die as the JVM terminated, but if the primary app was still running, my SwingWorkers would hang around (even though the done & cancel flags are set).
Clearly this means that my Java app is using the primary applications EDT (which makes sense), but it leaves me with a problem. If I have a user who runs my tool multiple times during a single session with the primary app, then I'll start stacking up zombie SwingWorkers who aren't doing anything except chewing up a spot of memory & CPU.
So, the question I have for the hive mind, is there anyway to force terminate a zombie SwingWorker? Or, absent that, is there any way to re-attach to a Zombie SwingWorker if, for instance, I know it's name?
Thank you!
I think this is expected if you use a thread pool, which keeps threads hanging around (probably with an idle loop, causing them to show up as 'running').
The docs say that swingworkers can only execute once, so re-attaching them isn't possible. They aren't threads themselves, but executed on a worker thread.
You could limit the number of threads in the pool by using an ExecutorService.
See this SO question for more details.
Related
I have several threads in my Android application that should be executed concurrently. I am not running them on several cores. REAL parallel execution at exactly the same time is not necessary. If Android switches between the different tasks or temporarily pauses certain threads, it's Ok.
The problem: Some threads are highly time consuming and computationally expensive (complex algorithms), but are not real time critical. Other threads and the Android UI thread are real time critical and should not be blocked or heavily delayed by the time consuming processes. Nevertheless, the time consuming processes should also be executed if there are no other more important tasks to perform. Ideally, the highly important threads should safely pause the less important threads. In Java people used to implement suspend() commands, but they are now depricated.
What is the recommended way to solve this problem in Android?? In Java I would have used Sleep commands or wait and notify methods. What is recommended way in Android?
Thanks for the anwer, guys!
Edit:
I was thinking about threads. But I wrote "processes" instead of "threads", just in case regular threads are not the best way to solve the problem in Android. I am open to anything. I have only ONE App. Sorry if terms get mixed up a little. But I wanted to keep the options and ideas open.
Thanks for the comments and answers so far. But I am more interested in a GENERAL, recommended, established strategy and good practice to solve this kind of problem in Android. I could also do some hacks, but I was really hoping for a clean and established solution. I am more looking for an answer like: "The common, established approach is to use strategy A + strategy B..."
In my opinion you should use a different component (Service) and set it to run on a different process - here you can see how
By doing so you can put all the computing in a different process that not related to your man UI component lifecycle.
If the dependency of algorithms' logics and the main UI is loose I wouldn't try to implement them via Threads concurrency.
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 wrote a web crawler that opens many web pages. As you can see in the image below, some threads seem to be finished (white color), but what does it mean? Do I have some bug? Is there a leak of resources? And, how can I have an idea about where those threads are generated and why are they finished? Should I worry about them?
VisualVM
The problem is that if i keep it running for a day, i get thousands of that threads, so i'm worried about it.
It's fine to start lots of threads, as long as not too many of them are alive at the same time. "Finished" threads are no longer alive, so they won't cause issues.
Having said that, in Java threads are rather expensive to create (this can be different in other languages, like Erlang), and you usually don't want / don't need to create lots of threads during the course of your app's life. You may want to use a Thread Pool. This will re-use threads instead of starting a new one many times.
The finished threads will not kill your application. But instead of creating new threads that we'll be finished, use a thread pool that will re-use them.
I am building a system where there is a simple GUI which will trigger the system to execute. I implemented the system in a way that when an exception is thrown, System.exit(0) is called and so the application stops.
I would like the implementation to stop, as it is doing now, however I wish that the GUI would not be closed as well. I tried implementing the system in a separate thread, however when some exception was thrown, the application still closed down.
Is there a way to leave the UI open, but still stop the implementation?
You cannot use Java system.exit for that purpose because that function kills the instance of Java Virtual Machine that is running your code, consequently stopping all the threads of your application.
In order for System.exit to work the way you want it to right now, you would need to have two different processes, so that each of them would run in its own Java Virtual Machine. However, this will make it harder to link things together.
Ideally, you should add some sort of control in the implementation, so that your GUI thread could activate or deactivate a switch which would naturally stop the logic of the implementation. This really is the best way to go in my opinion.
Essentially, they will need to be separate applications. That is, make them separate processes, not separate threads.
This kind of loose-coupling between your UI and back-end will achieve the behaviour you want, and also yields a bunch of other benefits relating to separating the concerns of your UI and your backend.
No, there is no way to keep your UI open if your program is running on the same process. I suppose you could run your UI and your program as separate applications, but that seems tedious and error prone. If an exception is thrown, you should be notifying the user, not just exiting the JVM.
I'm working on a multi-user Java webapp, where it is possible for clients to use the webapp API to do potentially naughty things, by passing code which will execute on our server in a sandbox.
For example, it is possible for a client to write a tight while(true) loop that impacts the performance of other clients.
Can you guys think of ways to limit the damage caused by these sorts of behaviors to other clients' performance?
We are using Glassfish for our application server.
The halting problem show that there is no way that a computer can reliably identify code that will not terminate.
The only way to do this reliably is to execute your code in a separate JVM which you then ask the operating system to shut down when it times out. A JVM not timing out can process more tasks so you can just reuse it.
One more idea would be byte-code instrumentation. Before you load the code sent by your client, manipulate it so it adds a short sleep in every loop and for every method call (or method entry).
This avoids clients clogging a whole CPU until they are done. Of course, they still block a Thread object (which takes some memory), and the slowing down is for every client, not only the malicious ones. Maybe make the first some tries free, then scale the waiting time up with each try (and set it down again if the thread has to wait for other reasons).
Modern day app servers use Thread Pooling for better performance. The problem is that one bad apple can spoil the bunch. What you need is an app server with one thread or maybe process per request. Of course there are going to be trade offs. but the OS will handle making sure that processing time gets allocated evenly.
NOTE: After researching a little more what you need is an engine that will create another process per request. If not a user can either cripple you servlet engine by having servlets with infinite loops and then posting multiple requests. Or he could simply do a System.exit in his code and bring everybody down.
You could use a parent thread to launch each request in a separate thread as suggested already, but then monitor the CPU time used by the threads using the ThreadMXBean class. You could then have the parent thread kill any threads that are misbehaving. This is if, of course, you can establish some kind of reasonable criteria for how much CPU time a thread should or should not be using. Maybe the rule could be that a certain initial amount of time plus a certain additional amount per second of wall clock time is OK?
I would make these client request threads have lower priority than the thread responsible for monitoring them.