I have an app that has a pool of threads which wait to be passed a socket (from ServerSocket.accept()). The user can click a "do not disturb" button which will stop them from being notified of info coming in to the socket. Is it better performance-wise (or otherwise) when the don't disturb is selected to:
1. kill all threads in the pool (and now serversocket class won't even call sock.accept() ) 2. When they turn it back on, recreate a pool of threads
or keep those threads running in the background but just don't send them anything?
I'll assume a normal kind of thread pool thing where a number of threads are blocked waiting to get a task from a queue. I'd have to guess those blocked threads are using zero CPU cycles and whatever memory the Thread class plus your Runnable take up. I'd rather leave them waiting around than tear them down and build new ones later.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I think the answer depends on what the user is likely to do.
If "do not disturb" is usually reversed by the user in a short time (60 secs???) then keep the threads alive, otherwise kill.
Might try and keep some history, so you can possibly calculate an individual user's optimal wait-to-kill time.
Joined: Jan 29, 2003
Not wanting to sound argumentative, but I'd want some proof that idle threads are a problem before I put any effort into making them go away and come back and track time and such. Thread pools come free with Java5, pick one, devote your time to the next feature the customer cares about. If the app has problems, profile it and find the real issues. If you're really worried about this one, hide it behind an API that will be stable even if you have to come back in and rewrite this bit. [ October 05, 2006: Message edited by: Stan James ]
Joined: Feb 25, 2003
Originally posted by Stan James: I'll assume a normal kind of thread pool thing where a number of threads are blocked waiting to get a task from a queue. I'd have to guess those blocked threads are using zero CPU cycles and whatever memory the Thread class plus your Runnable take up. I'd rather leave them waiting around than tear them down and build new ones later.
That's sort of what I was thinking. I mean, there's something in me where I don't want to leave objects sitting around uncollected (feels like memory leaks perhaps ) but my understanding is that creating threads is VERY intensive and a thread can sit on wait() with very little in the way of resources.
I know that it's not guaranteed to do anything, but perhaps it'd be worth marking down the priority of each of those threads when "do not disturb" is chosen?
(And yes, they'll be waiting on a task)
Joined: Jan 29, 2003
I'd guess the cost of a blocked thread is very near zero. Any time the thread manager in the JVM thinks it might be time to switch threads it looks through all the non-running ones to find one that is runnable. Your blocked threads aren't runnable, so the cost is just the check. Again, I wouldn't worry about those idle threads until I knew I had a problem.