From what time I've spent with threads in Java
, I've found these two ways to write threads:
With implements Runnable
:
public class MyRunnable implements Runnable { public void run() { //Code } } //Started with a "new Thread(new MyRunnable()).start()" call
Or, with extends Thread
:
public class MyThread extends Thread { public MyThread() { super("MyThread"); } public void run() { //Code } } //Started with a "new MyThread().start()" call
Is there any significant difference in these two blocks of code?
If a class define thread implementing the Runnable interface it has a chance of extending one class. A user must extend thread class only if it wants to override the other methods in Thread class. If you only want to specialize run method then implementing Runnable is a better option.
The other way to create a thread is to declare a class that implements the Runnable interface. That class then implements the run method. An instance of the class can then be allocated, passed as an argument when creating Thread, and started.
That means composition is the better way to go. Java only supports single inheritance, so you can only extend one class. Instantiating an interface gives a cleaner separation between your code and the implementation of threads. Implementing Runnable makes your class more flexible.
By implementing Runnable we can reuse the task to execute it on different threads. Also it could be run by other means like Executor . Implementing Runnable provide Composition and extending Thread is Inheritance .
Yes: implements Runnable
is the preferred way to do it, IMO. You're not really specialising the thread's behaviour. You're just giving it something to run. That means composition is the philosophically "purer" way to go.
In practical terms, it means you can implement Runnable
and extend from another class as well... and you can also implement Runnable
via a lambda expression as of Java 8.
tl;dr: implements Runnable is better. However, the caveat is important
In general, I would recommend using something like Runnable
rather than Thread
because it allows you to keep your work only loosely coupled with your choice of concurrency. For example, if you use a Runnable
and decide later on that this doesn't in fact require it's own Thread
, you can just call threadA.run().
Caveat: Around here, I strongly discourage the use of raw Threads. I much prefer the use of Callables and FutureTasks (From the javadoc: "A cancellable asynchronous computation"). The integration of timeouts, proper cancelling and the thread pooling of the modern concurrency support are all much more useful to me than piles of raw Threads.
Follow-up: there is a FutureTask
constructor that allows you to use Runnables (if that's what you are most comfortable with) and still get the benefit of the modern concurrency tools. To quote the javadoc:
If you don't need a particular result, consider using constructions of the form:
Future<?> f = new FutureTask<Object>(runnable, null)
So, if we replace their runnable
with your threadA
, we get the following:
new FutureTask<Object>(threadA, null)
Another option that allows you to stay closer to Runnables is a ThreadPoolExecutor. You can use the execute method to pass in a Runnable to execute "the given task sometime in the future."
If you'd like to try using a thread pool, the code fragment above would become something like the following (using the Executors.newCachedThreadPool() factory method):
ExecutorService es = Executors.newCachedThreadPool(); es.execute(new ThreadA());
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