With JDK >= 1.5, should the preferred way to start a thread always be an Executor or Executor Service, or are there still reasons to prefer to use a Thread.start if you don't need what an ExecutorService provides?
For syncronized, I used to think that using the new Lock implemenations was preferred, until I was explained otherwise. So I'm wondering the same thing about Executors. Are they just a way of handling more complex cases, or should they be the standard choice?
ExecutorService abstracts away many of the complexities associated with the lower-level abstractions like raw Thread . It provides mechanisms for safely starting, closing down, submitting, executing, and blocking on the successful or abrupt termination of tasks (expressed as Runnable or Callable ).
The ExecutorService helps in maintaining a pool of threads and assigns them tasks. It also provides the facility to queue up tasks until there is a free thread available if the number of tasks is more than the threads available.
Interface ExecutorService. An Executor that provides methods to manage termination and methods that can produce a Future for tracking progress of one or more asynchronous tasks. An ExecutorService can be shut down, which will cause it to reject new tasks.
Yes you can use the call() method of a Callable or the run() method of a Runnable from your own thread directly.
Java Concurrency in Practice at least clearly states in section 6.2.:
The primary abstraction for task execution in the Java class libraries is not
Thread
, butExecutor
. [...]Using an Executor is usually the easiest path to implementing a producer-consumer design in your application.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With