2

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!

Shane Gillis
  • 75
  • 6
  • Consider adding some example code and what you've tried. – blm Nov 12 '15 at 19:24
  • Example code won't offer anything, since I'm not having an issue with code or syntax, but something more fundamental (how SwingWorkers operate with the thread pool). – Shane Gillis Nov 12 '15 at 20:10
  • From memory, `SwingWorker` uses a shared fixed thread pool `ExecutorService`. This means that the pool is likely to maintain a series of `Thread`s which it will use to execute tasks (`SwingWorker`s). These threads should be in a idle state, presumably waiting on some kind of lock, which means that they shouldn't be consuming CPU cycles. It's faster to re-use these threads from the pool then having to re-create new ones each time – MadProgrammer Nov 12 '15 at 20:14

1 Answers1

2

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.

Community
  • 1
  • 1
Kenney
  • 9,003
  • 15
  • 21
  • So once a SwingWorker task is complete, the thread is returned to the pool for re-use? – Shane Gillis Nov 12 '15 at 20:12
  • That's my understanding. – Kenney Nov 12 '15 at 20:13
  • @Kenney `SwingWorker` already uses a shared, fixed thread pool `ExecutorService` of it's own, which limits the number of active workers to 10. Of course, you could create you own, but it means you can't use the `execute` method of the `SwingWorker`, not that it can't be done, it just changes the work flow – MadProgrammer Nov 12 '15 at 20:16
  • @MadProgrammer Exactly (thanks for the nr 10 - couldn't find that). I only mentioned using 'your own' ExecutorService so that the thread pool can be controlled (nr of threads, `shutdown`). – Kenney Nov 12 '15 at 20:19
  • @Kenney Nothing wrong with using your own ExecutorService, just need to beware of the change in work flow ;) – MadProgrammer Nov 12 '15 at 20:35
  • @MadProgrammer Gotcha! ;-) – Kenney Nov 12 '15 at 21:01
  • So they aren't Zombie SwingWorkers, just idle threads with that can't number more than 10 (11 is right out!). Excellent, then I shall not worry about them. Thank you! – Shane Gillis Nov 12 '15 at 21:58