6

As far as I understand Executors help handling the execution of runnables. E.g. I would choose using an executor when I have several worker threads that do their job and then terminate. The executor would handle the creation and the termination of the Threads needed to execute the worker runnables.

However now I am facing another situation. A fixed number of classes/objects shall encapsulate their own thread. So the thread is started at the creation of those objects and the Thread shall continue running for the whole life time of these objects. The few objects in turn are created at the start of the programm and exist for the whole run time. I guess Threads are preferable over Executors in this situation, however when I read the internet everybody seems to suggest using Executors over Threads in any possible situation.

Can somebody please tell me if I want to choose Executors or Threads here and why?

Thanks

flxh
  • 565
  • 4
  • 19
  • What will these threads be doing during their life time? Will they be 100% busy computing decimals of pi, or will they idle until interacted with? – aioobe Feb 11 '15 at 21:45
  • it depends ... some of them will have about 50% idle time, others just about 10% – flxh Feb 11 '15 at 21:48
  • ...still others will be 100% busy computing hashes of trees. – flxh Feb 11 '15 at 21:50

3 Answers3

3

You're somewhat mixing things. Executor is just an interface. Thread is a core class. There's nothing which directly implies that Executor implementations execute tasks in separate threads.

Read the first few lines of the JavaDoc.

Executor

So if you want full control, just use Thread and do things on your own.

peter.petrov
  • 38,363
  • 16
  • 94
  • 159
1

Without knowing more about the context, it's hard to give a good answer, but generally speaking I'd say that the situations that calls for using Thread are pretty few and far between. If you start trying to synchronize your program "manually" using synchronized I bet things will get out of hand quickly. (Not to mention how hard it will be to debug the code.)

Last time I used a thread was when I wanted to record some audio in the background. It was a "start"/"stop" kind of thing, and not "task oriented". (I tried long and hard to try to find an audio library that would encapsulate that for me but failed.)

If you choose to go for a thread-solution, I suggest you try to limit the scope of the thread to only execute within the associated object. This will to an as large extent as possible avoid forcing you to think about happens-before relations, thread-safe publishing of values etc throughout the code.

aioobe
  • 413,195
  • 112
  • 811
  • 826
  • "If you start trying to synchronize your program "manually" using synchronized I'd say you're out on really thin ice" Why so? Any reference to support that? – peter.petrov Feb 11 '15 at 21:53
  • The Java Memory Model is extremely hairy and thinking in terms of happens before relations quickly gets out of hand. In just about every situation you should try to work on a higher level of abstraction by using the classes provided by java.util.concurrent. – aioobe Feb 11 '15 at 21:55
  • actually at the moment I am synchronizing my program "manually" unsing synchronized. What would be an alternative ? – flxh Feb 11 '15 at 21:59
  • 2
    @user3187049 IMHO, keep using it, learn the low-level stuff first. Then you'll be much comfortable with the higher-level stuff. :) – peter.petrov Feb 11 '15 at 22:00
  • If you have `N` threads running in parallel and you use `synchronize` to make sure they all publish values in safe ways I'd say you may have a quite fragile program. If you go with one thread per object, I'd suggest each object should have a queue of messages (`BlockingQueue` for instance) which it can read/write messages from. – aioobe Feb 11 '15 at 22:02
  • 1
    In short, you either use `Thread` because you are implementing a custom Executor Service; or use an existing implementation. Very few situations call for a custom implementation. – Marko Topolnik Feb 11 '15 at 22:07
  • Problem here is : I need to use an very specific implementation of a tree structure for this project. Java .util.concurrent just doesnt provide any thread safe implementation of that tree structure. And as there will be reads and writes from multiple Threads on that tree I have no other choice than doing the synchronization on my own. – flxh Feb 11 '15 at 22:08
  • There are still many alternatives that abstracts away from `synchronized`. Perhaps you could use a `ReadWriteLock` for instance? – aioobe Feb 11 '15 at 22:11
  • You are building a concurrent tree structure with a segmented locking scheme? It doesn't sound like that, though, if you're starting a separate thread for working on it. – Marko Topolnik Feb 11 '15 at 22:13
  • 1
    Maybe you should describe what you should really need, because I have a feeling that you are creating wrong solution to your problem – Gaskoin Feb 11 '15 at 22:36
1
  • ExecutorService can have thread pool

It optimizes performance, because creating a Thread is expensive.

  • ExecutorService has life cycle control

shutdown(), shutdownNow() etc are provided.

  • ExecutorService is flexible

You could invoke variety of behaviors: customize ThreadFactory, set thread pool size, delay behavior ScheduledThreadPoolExecutor etc...

卢声远 Shengyuan Lu
  • 31,208
  • 22
  • 85
  • 130