1

The Java Concurrency API gives you Executor and ExecutorService interfaces to build from, and ships with several concrete implementations (ThreadPoolExecutor and ScheduledThreadPoolExecutor).

I'm completely new to Java Concurrency, and am having difficulty finding answers to several very-similarly-related questions. Rather than cluttering SO with all these tiny questions I decided to bundle them together, because there's probably a way to answer them all in one fell swoop (probably because I'm not seeing the whole picture here):

  • Is it common practice to implement your own Executor/ExecutorService? In what cases would you do this instead of using the two concretions I mention above? In what cases are the two concretions preferable over something "homegrown"?
  • I don't understand how all of the concurrent collections relate to Executors. For instance, does ThreadPoolExecutor use, say, ConcurrentLinkedQueue under the hood to queue up submitted tasks? Or are you (the API developer) supposed to select and use, say, ConcurrentLinkedQueue inside your parallelized run() method? Basicaly, are the concurrent collections there to be used internally by the Executors, or do you use them to help write non-blocking algorithms?
  • Can you configure which concurrent collections an Executor uses under the hood (to store submitted tasks), and is this common practice?

Thanks in advance!

IAmYourFaja
  • 55,468
  • 181
  • 466
  • 756

1 Answers1

4

Is it common practice to implement your own Executor/ExecutorService?

No. I've never had to do this and I've been using the concurrency package for some time. The complexity of these classes and the performance implications around getting them "wrong" mean that you should really think carefully about it before undertaking such a project.

The only time that I felt the need to implement my own executor service was when I wanted to implement a "self-run" executor service. That was until a friend showed me that there was a way to do it with a RejectedExecutionHandler.

The only reason why I'd wanted to tweak the behavior of the ThreadPoolExecutor was to have it start all of the threads up to the max-threads and then stick the jobs into the queue. By default the ThreadPoolExecutor starts min-threads and then fills the queue before starting another thread. Not what I expect or want. But then I'd just be copying the code from the JDK and changing it -- not implementing it from scratch.

I don't understand how all of the concurrent collections relate to Executors. For instance, does ThreadPoolExecutor use, say, ConcurrentLinkedQueue under the hood to queue up submitted tasks?

If you are using one of the Executors helper methods then you don't have to worry about this. If you are instantiating ThreadPoolExecutor yourself then you provide the BlockingQueue to use.

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
           0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());
}

Versus:

 ExecutorService threadPool = 
     new ThreadPoolExecutor(minThreads, maxThreads, 0L, TimeUnit.MILLISECONDS,
            new SynchronousQueue<Runnable>());

Can you configure which concurrent collections an Executor uses under the hood (to store submitted tasks), and is this common practice?

See the last answer.

Community
  • 1
  • 1
Gray
  • 115,027
  • 24
  • 293
  • 354
  • Thanks @Gray (+1) - so to summarize, I'll always be using either `ThreadPoolExecutor` or `ScheduledPoolExecutor` and the *only* time I'll ever use a concurrent collection is when I'm using it to create a new instance of one of these two types? There's no reason for a `BlockingQueue` to appear inside my `run()` method as a part of my non-blocking algorithm, yes? Just want to be sure I understand completely! – IAmYourFaja Jun 29 '12 at 18:37
  • Yes in terms of the executors. I use concurrent collections all of the time to communicate between threads but you don't have to worry about them with regards to the executor service. There is no reason the reference the `Runnable` blocking queue in your `run()` method. – Gray Jun 29 '12 at 18:42
  • See my example here for setting a rejection handler. That references the queue but again, not in the `run()` method: http://stackoverflow.com/questions/11249342/creating-a-dynamic-growing-shrinking-thread-pool-in-java/11249485#11249485 – Gray Jun 29 '12 at 18:43