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());