Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

If not listening to socket but might later, kill threads in pool, recreate?

 
Dan Bizman
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Guy Allard
Ranch Hand
Posts: 776
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Guy
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Dan Bizman
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic