2

I have seen several comments to the effect that Executors are better than Threads, but if you have a number of Threads communicating via bounded buffers (as in Flow-Based Programming) why would you use Executors when you have to use Threads anyway (with newCachedThreadPool (?)). Also, I use methods like isAlive(), interrupt() - how do I get hold of the Thread handle?

Does anyone have sample code that I can plagiarize? ;-)

Paul Morrison
  • 1,694
  • 3
  • 20
  • 35
  • I suggest you buy and read http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601/ref=sr_1_1?ie=UTF8&s=books&qid=1260237309&sr=8-1 cover to cover. – cletus Dec 08 '09 at 01:55
  • Not very helpful, @Cletus! I do understand about threads and locks - I am not about to shell out $40 to get one question answered :-) – Paul Morrison Dec 08 '09 at 20:57
  • No answers after a day, so I'll try on the Sun forum... Thanks anyway! – Paul Morrison Dec 09 '09 at 18:07
  • This question may be helpful : http://stackoverflow.com/questions/21156599/javas-fork-join-vs-executorservice-when-to-use-which/34922218#34922218 – Ravindra babu Jan 21 '16 at 12:17

1 Answers1

1

Executors are basically an abstraction over Threads. They make you isolate your potentially parallel logic in Runnable/Callable instances while liberating you from the duties of manually creating and starting a thread or managing a pool. You still need to handle dependencies as part of your application logic.

If you want to interact / are comfortable with Threads for your application logic, you may skip using Executors. Regarding getting hold of the thread, you can always execute Thread.currentThread() to get hold of the current thread from any executing context.

shams
  • 3,460
  • 24
  • 24