“Implémente Runnable” vs “étend Thread” en Java

Depuis que j’ai passé des threads en Java, j’ai trouvé ces deux manières d’écrire des threads:

Avec des implements Runnable :

 public class MyRunnable implements Runnable { public void run() { //Code } } //Started with a "new Thread(new MyRunnable()).start()" call 

Ou, avec extends Thread :

 public class MyThread extends Thread { public MyThread() { super("MyThread"); } public void run() { //Code } } //Started with a "new MyThread().start()" call 

Y a-t-il une différence significative dans ces deux blocs de code?

Oui: implémente Runnable est la manière préférée de le faire, IMO. Vous ne spécialisez pas vraiment le comportement du thread. Vous ne faites que donner quelque chose à courir. Cela signifie que la composition est la voie la plus ” philosophique “.

En termes pratiques , cela signifie que vous pouvez implémenter Runnable et l’étendre à partir d’une autre classe.

tl; dr: implémente Runnable c’est mieux. Cependant, la mise en garde est importante

En général, je vous recommande d’utiliser quelque chose comme Runnable plutôt que Thread car cela vous permet de garder votre travail faiblement associé à votre choix de concurrence. Par exemple, si vous utilisez un Runnable et que vous décidez ultérieurement que cela ne nécessite pas de Thread , vous pouvez simplement appeler threadA.run ().

Mise en garde: Autour d’ici, je déconseille fortement l’utilisation de threads bruts. Je préfère de beaucoup l’utilisation de Callables et FutureTasks (à partir du javadoc: “Un calcul asynchrone annulable”). L’intégration des délais d’attente, l’annulation correcte et la mise en pool des threads du support des access concurrents modernes sont beaucoup plus utiles pour moi que des stacks de threads bruts.

Suivi: il y a un constructeur FutureTask qui vous permet d’utiliser Runnables (si c’est ce que vous êtes le plus à l’aise) et de continuer à bénéficier des outils de concurrence modernes. Pour citer le javadoc:

Si vous n’avez pas besoin d’un résultat particulier, envisagez d’utiliser des constructions de la forme:

 Future f = new FutureTask(runnable, null) 

Donc, si nous remplaçons leur runnable par votre threadA , nous obtenons ce qui suit:

 new FutureTask(threadA, null) 

Une autre option permettant de restr proche de Runnables est un ThreadPoolExecutor . Vous pouvez utiliser la méthode execute pour passer un Runnable pour exécuter “la tâche donnée dans le futur”.

Si vous souhaitez essayer d’utiliser un pool de threads, le fragment de code ci-dessus deviendrait quelque chose comme ce qui suit (en utilisant la méthode d’usine Executors.newCachedThreadPool () ):

 ExecutorService es = Executors.newCachedThreadPool(); es.execute(new ThreadA()); 

Morale de l’histoire:

Héritez uniquement si vous souhaitez modifier un comportement.

Ou plutôt il faut le lire comme suit:

Hériter moins, interface plus.

Eh bien tant de bonnes réponses, je veux append plus à ce sujet. Cela aidera à comprendre Extending v/s Implementing Thread .
Extends lie très étroitement deux fichiers de classe et peut causer des problèmes de gestion de code.

Les deux approches font le même travail mais il y a eu quelques différences.
La différence la plus commune est

  1. Lorsque vous prolongez la classe Thread, vous ne pouvez plus étendre aucune autre classe requirejse. (Comme vous le savez, Java n’autorise pas l’inheritance de plusieurs classes).
  2. Lorsque vous implémentez Runnable, vous pouvez économiser un espace pour que votre classe puisse étendre toute autre classe à l’avenir ou maintenant.

Cependant, une différence significative entre l’implémentation de Thrnable et de Thread est que
by extending Thread, each of your threads has a unique object associated with it, whereas implementing Runnable, many threads can share the same object instance.

L’exemple suivant vous aide à mieux comprendre

 //Implement Runnable Interface... class ImplementsRunnable implements Runnable { private int counter = 0; public void run() { counter++; System.out.println("ImplementsRunnable : Counter : " + counter); } } //Extend Thread class... class ExtendsThread extends Thread { private int counter = 0; public void run() { counter++; System.out.println("ExtendsThread : Counter : " + counter); } } //Use above classes here in main to understand the differences more clearly... public class ThreadVsRunnable { public static void main(Ssortingng args[]) throws Exception { // Multiple threads share the same object. ImplementsRunnable rc = new ImplementsRunnable(); Thread t1 = new Thread(rc); t1.start(); Thread.sleep(1000); // Waiting for 1 second before starting next thread Thread t2 = new Thread(rc); t2.start(); Thread.sleep(1000); // Waiting for 1 second before starting next thread Thread t3 = new Thread(rc); t3.start(); // Creating new instance for every thread access. ExtendsThread tc1 = new ExtendsThread(); tc1.start(); Thread.sleep(1000); // Waiting for 1 second before starting next thread ExtendsThread tc2 = new ExtendsThread(); tc2.start(); Thread.sleep(1000); // Waiting for 1 second before starting next thread ExtendsThread tc3 = new ExtendsThread(); tc3.start(); } } 

Sortie du programme ci-dessus.

 ImplementsRunnable : Counter : 1 ImplementsRunnable : Counter : 2 ImplementsRunnable : Counter : 3 ExtendsThread : Counter : 1 ExtendsThread : Counter : 1 ExtendsThread : Counter : 1 

Dans l’approche d’interface Runnable, une seule instance d’une classe est en cours de création et elle a été partagée par différents threads. La valeur de counter est donc incrémentée pour chaque access de thread.

Alors que l’approche de classe Thread, vous devez créer une instance distincte pour chaque access au thread. Par conséquent, une mémoire différente est allouée pour chaque instance de classe et chaque compteur a un compteur distinct, la valeur rest la même, ce qui signifie qu’aucun incrément ne se produira car aucune des références d’object n’est la même.

Quand utiliser Runnable?
Utilisez l’interface Runnable lorsque vous souhaitez accéder à la même ressource à partir du groupe de threads. Évitez d’utiliser la classe Thread ici, car la création de plusieurs objects consum plus de mémoire et entraîne une perte de performances importante.

Une classe qui implémente Runnable n’est pas un thread et juste une classe. Pour qu’un Runnable devienne un thread, vous devez créer une instance de Thread et la transmettre en tant que cible.

Dans la plupart des cas, l’interface Runnable doit être utilisée si vous prévoyez uniquement de remplacer la méthode run() et aucune autre méthode Thread. Ceci est important car les classes ne doivent pas être sous-classées à moins que le programmeur ne souhaite modifier ou améliorer le comportement fondamental de la classe.

Lorsqu’il est nécessaire d’étendre une super-classe, l’implémentation de l’interface Runnable est plus appropriée que l’utilisation de la classe Thread. Parce que nous pouvons étendre une autre classe en implémentant l’interface Runnable pour créer un thread.

J’espère que cela aidera!

Une chose qui, à mon avis, n’a pas encore été mentionnée, c’est que la mise en œuvre de Runnable rend votre classe plus flexible.

Si vous étendez le thread, alors l’action que vous faites sera toujours dans un thread. Cependant, si vous implémentez Runnable cela ne doit pas être le cas. Vous pouvez l’exécuter dans un thread, ou le transmettre à un type de service exécuteur, ou simplement le transmettre en tant que tâche dans une application à thread unique (peut-être pour être exécuté ultérieurement, mais dans le même thread). Les options sont beaucoup plus ouvertes si vous utilisez simplement Runnable que si vous vous liez à Thread .

Si vous voulez implémenter ou étendre une autre classe, l’interface Runnable est préférable si vous ne voulez pas que d’autres classes soient étendues ou implémentées, alors la classe Thread est préférable.

La différence la plus commune est

entrer la description de l'image ici

Lorsque vous extends Thread classe extends Thread , vous ne pouvez plus étendre aucune autre classe requirejse. (Comme vous le savez, Java n’autorise pas l’inheritance de plusieurs classes).

Lorsque vous implements Runnable , vous pouvez économiser de l’espace pour que votre classe puisse étendre toute autre classe à l’avenir ou maintenant.

  • Java ne prend pas en charge l’inheritance multiple, ce qui signifie que vous ne pouvez étendre qu’une seule classe en Java. Une fois que vous avez étendu la classe Thread, vous avez perdu toute chance et vous ne pouvez pas étendre ou hériter une autre classe en Java.

  • En programmation orientée object, l’extension d’une classe signifie généralement l’ajout de nouvelles fonctionnalités, la modification ou l’amélioration des comportements. Si nous ne modifions pas Thread, utilisez plutôt l’interface Runnable.

  • L’interface exécutable représente une tâche qui peut être exécutée soit par Thread, soit par Executors, soit par tout autre moyen. La séparation logique de Task en tant que Runnable que Thread est une bonne décision de conception.

  • Séparer la tâche comme Runnable signifie que nous pouvons réutiliser la tâche et que nous pouvons également l’exécuter de différentes manières. car vous ne pouvez pas redémarrer un thread une fois qu’il est terminé. à nouveau Runnable vs Thread pour tâche, Runnable est gagnant.

  • Le concepteur Java le reconnaît et c’est pourquoi les exécuteurs acceptent Runnable as Task et ils ont un thread de travail qui exécute ces tâches.

  • L’inheritance de toutes les méthodes Thread est une surcharge supplémentaire uniquement pour représenter une tâche qui peut être effectuée facilement avec Runnable.

Courtesy from javarevisited.blogspot.com

Ce sont des différences notables entre Thread et Runnable en Java, si vous connaissez d’autres différences sur Thread vs Runnable, veuillez les partager via les commentaires. J’utilise personnellement Runnable over Thread pour ce scénario et recommande d’utiliser l’interface Runnable ou Callable en fonction de vos besoins.

Cependant, la différence significative est.

Lorsque vous extends Thread classe extends Thread , chacun de vos threads crée un object unique et s’y associe. Lorsque vous implements Runnable , il partage le même object avec plusieurs threads.

En fait, il n’est pas judicieux de comparer Runnable et Thread uns avec les autres.

Ces deux ont une dépendance et une relation en multi-threading, tout comme la relation Wheel and Engine d’un véhicule à moteur.

Je dirais qu’il n’y a qu’un seul moyen pour le multithreading en deux étapes. Laissez-moi faire mon point.

Runnable:
Lorsque vous implémentez l’ interface Runnable cela signifie que vous créez quelque chose qui peut être run able dans un thread différent. Créer maintenant quelque chose qui peut s’exécuter à l’intérieur d’un thread (exécutable dans un thread) ne signifie pas créer un thread.
Donc, la classe MyRunnable n’est rien d’autre qu’une classe ordinaire avec une méthode void run . Et ses objects seront des objects ordinaires avec seulement une méthode run qui s’exécutera normalement à l’appel. (sauf si on passe l’object dans un thread).

Fil:
class Thread , je dirais une classe très spéciale avec la possibilité de démarrer un nouveau thread qui active en fait le multi-threading via sa méthode start() .

Pourquoi pas sage de comparer?
Parce que nous avons besoin des deux pour le multi-threading.

Pour le multi-threading, nous avons besoin de deux choses:

  • Quelque chose qui peut fonctionner à l’intérieur d’un thread (Runnable).
  • Quelque chose qui peut démarrer un nouveau fil (fil).

Donc, techniquement et théoriquement, les deux sont nécessaires pour démarrer un fil, l’un fonctionnera et l’autre le fera fonctionner (comme la Wheel and Engine du véhicule).

C’est pourquoi vous ne pouvez pas démarrer un thread avec MyRunnable vous devez le transmettre à une instance de Thread .

Mais il est possible de créer et d’exécuter un thread uniquement à l’aide de la class Thread car Class Thread implémente Runnable afin que nous sachions tous que Thread est également un Runnable intérieur.

Enfin Thread et Runnable se complètent pour le multithreading non concurrent ou remplacement.

Vous devez implémenter Runnable, mais si vous utilisez Java 5 ou une version ultérieure, ne le démarrez pas avec un new Thread mais utilisez plutôt un ExecutorService . Pour plus de détails, voir: Comment implémenter des threads simples en Java .

Je ne suis pas un expert, mais je peux penser à une seule raison d’implémenter Runnable au lieu d’étendre Thread: Java ne supporte que l’inheritance unique, vous ne pouvez donc étendre qu’une seule classe.

Edit: Ceci à l’origine dit “La mise en œuvre d’une interface nécessite moins de ressources.” également, mais vous devez créer une nouvelle instance de Thread dans un sens ou dans l’autre, c’est donc faux.

Je dirais qu’il y a une troisième voie:

 public class Something { public void justAnotherMethod() { ... } } new Thread(new Runnable() { public void run() { instanceOfSomething.justAnotherMethod(); } }).start(); 

Cela est peut-être un peu influencé par mon utilisation récente de Javascript et d’Actionscript 3, mais de cette manière, votre classe n’a pas besoin d’implémenter une interface assez vague comme Runnable .

Avec la sortie de Java 8, il existe maintenant une troisième option.

Runnable est une interface fonctionnelle , ce qui signifie que ses instances peuvent être créées avec des expressions lambda ou des références de méthodes.

Votre exemple peut être remplacé par:

 new Thread(() -> { /* Code here */ }).start() 

ou si vous souhaitez utiliser un ExecutorService et une référence de méthode:

 executor.execute(runner::run) 

Celles-ci sont non seulement beaucoup plus courtes que vos exemples, mais comportent également de nombreux avantages énoncés dans d’autres réponses à l’utilisation de Runnable sur Thread , telles que la responsabilité unique et l’utilisation de la composition, car vous ne spécialisez pas le comportement du thread. De cette façon, vous évitez également de créer une classe supplémentaire si tout ce dont vous avez besoin est un Runnable comme vous le feriez dans vos exemples.

L’instanciation d’une interface permet une séparation plus nette entre votre code et l’implémentation des threads. Je préférerais donc implémenter Runnable dans ce cas.

  1. Java ne prend pas en charge l’inheritance multiple, ce qui signifie que vous ne pouvez étendre qu’une seule classe en Java. Une fois que vous avez étendu la classe Thread , vous avez perdu toute chance et vous ne pouvez pas étendre ou hériter une autre classe en Java.
  2. En programmation orientée object, l’extension d’une classe signifie généralement l’ajout de nouvelles fonctionnalités, la modification ou l’amélioration de comportements. Si nous ne modifions pas Thread utilisez plutôt l’interface Runnable .
  3. Runnable interface Runnable représente une Task pouvant être exécutée par un Thread ou des Executors ordinaires, ou par tout autre moyen. Donc, la séparation logique de la Task tant que Runnable que Thread est une bonne décision de conception.
  4. Séparer la tâche comme Runnable signifie que nous pouvons réutiliser la tâche et que nous pouvons également l’exécuter de différentes manières. Comme vous ne pouvez pas redémarrer un Thread une fois qu’il est terminé, à nouveau Runnable vs Thread pour tâche, Runnable est gagnant.
  5. Le concepteur Java le reconnaît et c’est pourquoi les Executors acceptent Runnable as Task et ils ont un thread de travail qui exécute ces tâches.
  6. L’inheritance de toutes les méthodes Thread est une surcharge supplémentaire uniquement pour représenter une Task qui peut être réalisée facilement avec Runnable .

Runnable parce que:

  • Laisse plus de souplesse à l’implémentation de Runnable pour étendre une autre classe
  • Séparer le code de l’exécution
  • Vous permet d’exécuter votre runnable à partir d’un pool de threads, du thread d’événement ou de toute autre manière à l’avenir.

Même si vous n’en avez pas besoin maintenant, vous pouvez le faire à l’avenir. Comme il n’y a aucun avantage à passer outre Thread, Runnable est une meilleure solution.

Tout le monde ici semble penser que l’implémentation de Runnable est la voie à suivre et je ne suis pas vraiment en désaccord avec eux, mais il y a aussi des raisons d’étendre Thread à mon avis.

Si vous implémentez Runnable alors la classe qui implémente Runnable n’a aucun contrôle sur le nom du thread, c’est le code appelant qui peut définir le nom du thread, comme ceci:

 new Thread(myRunnable,"WhateverNameiFeelLike"); 

mais si vous étendez Thread, vous devez gérer cela dans la classe elle-même (tout comme dans votre exemple, vous nommez le thread «ThreadB»). Dans ce cas vous:

A) pourrait lui donner un nom plus utile à des fins de débogage

B) forcent l’utilisation de ce nom pour toutes les instances de cette classe (à moins que vous n’ignoriez le fait qu’il s’agit d’un thread et que vous le fassiez comme si c’était un Runnable, mais nous parlons ici de convention) ignore cette possibilité que je ressens).

Vous pourriez même, par exemple, prendre une trace de stack de sa création et l’utiliser comme nom de thread. Cela peut sembler étrange, mais selon la structure de votre code, il peut être très utile pour le débogage.

Cela peut sembler une petite chose, mais où vous avez une application très complexe avec beaucoup de threads et tout d’un coup les choses se sont arrêtées (soit pour des raisons de blocage, soit à cause d’une faille dans un protocole réseau qui serait moins évident – ou d’autres raisons sans fin) puis obtenir un vidage de stack de Java où tous les threads sont appelés «Thread-1», «Thread-2», «Thread-3» n’est pas toujours très utile (cela dépend de la façon dont vos threads sont structuré et si vous pouvez utilement dire qui est qui par leur trace de stack – pas toujours possible si vous utilisez des groupes de plusieurs threads exécutant tous le même code).

Cela étant dit, vous pouvez bien entendu faire ce qui précède de manière générique en créant une extension de la classe de thread qui atsortingbue son nom à une trace de stack de son appel à la création, puis l’utiliser avec vos implémentations Runnable au lieu de la classe Thread Java standard (voir ci-dessous) mais en plus de la trace de la stack, il pourrait y avoir plus d’informations spécifiques au contexte qui seraient utiles dans le nom du thread pour le débogage (référence à l’une des nombreuses files d’attente ou sockets possibles). extend Thread spécifiquement pour ce cas afin que vous puissiez faire en sorte que le compilateur vous oblige (ou d’autres utilisateurs de vos bibliothèques) à transmettre certaines informations (par exemple, la queue / socket en question) à utiliser dans le nom).

Voici un exemple du thread générique avec la trace de la stack appelante comme nom:

 public class DebuggableThread extends Thread { private static Ssortingng getStackTrace(Ssortingng name) { Throwable t= new Throwable("DebuggableThread-"+name); ByteArrayOutputStream os = new ByteArrayOutputStream(); PrintStream ps = new PrintStream(os); t.printStackTrace(ps); return os.toSsortingng(); } public DebuggableThread(Ssortingng name) { super(getStackTrace(name)); } public static void main(Ssortingng[] args) throws Exception { System.out.println(new Thread()); System.out.println(new DebuggableThread("MainTest")); } } 

et voici un exemple de la sortie comparant les deux noms:

 Thread[Thread-1,5,main] Thread[java.lang.Throwable: DebuggableThread-MainTest at DebuggableThread.getStackTrace(DebuggableThread.java:6) at DebuggableThread.(DebuggableThread.java:14) at DebuggableThread.main(DebuggableThread.java:19) ,5,main] 

Comme il s’agit d’un sujet très populaire et que les bonnes réponses sont réparties et traitées de manière approfondie, j’ai estimé qu’il était justifié de comstackr les bonnes réponses des autres sous une forme plus concise, afin que les nouveaux arrivants puissent avoir un aperçu simple:

  1. Vous étendez généralement une classe pour append ou modifier des fonctionnalités. Donc, si vous ne voulez pas écraser un comportement Thread , utilisez Runnable.

  2. Dans le même ordre d’idées, si vous n’avez pas besoin d’ hériter des méthodes de thread, vous pouvez vous en passer en utilisant Runnable.

  3. Héritage unique : Si vous étendez l’extension Thread, vous ne pouvez pas l’étendre depuis une autre classe, donc si c’est ce que vous devez faire, vous devez utiliser Runnable.

  4. It is good design to separate domain logic from technical means, in that sense it is better to have a Runnable task isolating your task from your runner .

  5. You can execute the same Runnable object multiple times , a Thread object, however, can only be started once. (Maybe the reason, why Executors do accept Runnables, but not Threads.)

  6. If you develop your task as Runnable, you have all flexibility how to use it now and in the future . You can have it run concurrently via Executors but also via Thread. And you still could also use/call it non-concurrently within the same thread just as any other ordinary type/object.

  7. This makes it also easier to separate task-logic and concurrency aspects in your unit tests .

  8. If you are interestd in this question, you might be also interestd in the difference between Callable and Runnable .

This is discussed in Oracle’s Defining and Starting a Thread tutorial:

Which of these idioms should you use? The first idiom, which employs a Runnable object, is more general, because the Runnable object can subclass a class other than Thread. The second idiom is easier to use in simple applications, but is limited by the fact that your task class must be a descendant of Thread. This lesson focuses on the first approach, which separates the Runnable task from the Thread object that executes the task. Not only is this approach more flexible, but it is applicable to the high-level thread management APIs covered later.

In other words, implementing Runnable will work in scenarios where your class extends a class other than Thread . Java does not support multiple inheritance. Also, extending Thread will not be possible when using some of the high-level thread management APIs. The only scenario where extending Thread is preferable is in a small application that won’t be subject to updates in future. It is almost always better to implement Runnable as it is more flexible as your project grows. A design change won’t have a major impact as you can implement many interfaces in java, but only extend one class.

If I am not wrong, it’s more or less similar to

What is the difference between an interface and abstract class?

extends establishes ” Is A ” relation & interface provides ” Has a ” capability.

Prefer implements Runnable :

  1. If you don’t have to extend Thread class and modify Thread API default implementation
  2. If you are executing a fire and forget command
  3. If You are already extending another class

Prefer ” extends Thread ” :

  1. If you have to override any of these Thread methods as listed in oracle documentation page

Generally you don’t need to override Thread behaviour. So implements Runnable is preferred for most of the times.

On a different note, using advanced ExecutorService or ThreadPoolExecutorService API provides more flexibility and control.

Have a look at this SE Question:

ExecutorService vs Casual Thread Spawner

Difference between Extending Thread and Implementing Runnable are:

entrer la description de l'image ici

Separating the Thread class from the Runnable implementation also avoids potential synchronization problems between the thread and the run() method. A separate Runnable generally gives greater flexibility in the way that runnable code is referenced and executed.

One reason you’d want to implement an interface rather than extend a base class is that you are already extending some other class. You can only extend one class, but you can implement any number of interfaces.

If you extend Thread, you’re basically preventing your logic to be executed by any other thread than ‘this’. If you only want some thread to execute your logic, it’s better to just implement Runnable.

if you use runnable you can save the space to extend to any of your other class.

Can we re-visit the basic reason we wanted our class to behave as a Thread ? There is no reason at all, we just wanted to execute a task, most likely in an asynchronous mode, which precisely means that the execution of the task must branch from our main thread and the main thread if finishes early, may or may not wait for the twigd path(task).

If this is the whole purpose, then where do I see the need of a specialized Thread. This can be accomplished by picking up a RAW Thread from the System’s Thread Pool and assigning it our task (may be an instance of our class) and that is it.

So let us obey the OOPs concept and write a class of the type we need. There are many ways to do things, doing it in the right way matters.

We need a task, so write a task definition which can be run on a Thread. So use Runnable.

Always remember implements is specially used to impart a behaviour and extends is used to impart a feature/property.

We do not want the thread’s property, instead we want our class to behave as a task which can be run.

Yes, If you call ThreadA call , then not need to call the start method and run method is call after call the ThreadA class only. But If use the ThreadB call then need to necessary the start thread for call run method. If you have any more help, reply me.

I find it is most useful to use Runnable for all the reasons mentioned, but sometimes I like to extend Thread so I can create my own thread stopping method and call it directly on the thread I have created.

Java does not support multiple inheritence so if you extends Thread class then no other class will be extended.

For Example: If you create an applet then it must extends Applet class so here the only way to create thread is by implementing Runnable interface

That’s the S of SOLID : Single responsibility.

A thread embodies the running context (as in execution context: stack frame, thread id, etc.) of the asynchronous execution of a piece of code. That piece of code ideally should be the same implementation, whether synchronous or asynchronous .

If you bundle them together in one implementation, you give the resulting object two unrelated causes of change:

  1. thread handling in your application (ie. querying and modifying the execution context)
  2. algorithm implemented by the piece of code (the runnable part)

If the language you use supports partial classes or multiple inheritance, then you can segregate each cause in its own super class, but it boils down to the same as composing the two objects, since their feature sets don’t overlap. That’s for the theory.

In practice, generally speaking, a programme does not need to carry more complexity than necessary. If you have one thread working on a specific task, without ever changing that task, there is probably no point in making the tasks separate classes, and your code remains simpler.

In the context of Java , since the facility is already there , it is probably easier to start directly with stand alone Runnable classes, and pass their instances to Thread (or Executor ) instances. Once used to that pattern, it is not harder to use (or even read) than the simple runnable thread case.

Difference between Thread and runnable .If we are creating Thread using Thread class then Number of thread equal to number of object we created . If we are creating thread by implementing the runnable interface then we can use single object for creating multiple thread.So single object is shared by multiple Thread.So it will take less memory

So depending upon the requirement if our data is not senstive. So It can be shared between multiple Thread we can used Runnable interface.

Adding my two cents here – Always whenever possible use implements Runnable . Below are two caveats on why you should not use extends Thread s

  1. Ideally you should never extend the Thread class; the Thread class should be made final . At least its methods like thread.getId() . See this discussion for a bug related to extending Thread s.

  2. Those who like to solve puzzles can see another side effect of extending Thread. The below code will print unreachable code when nobody is notifying them.

Please see http://pastebin.com/BjKNNs2G .

 public class WaitPuzzle { public static void main(Ssortingng[] args) throws InterruptedException { DoNothing doNothing = new DoNothing(); new WaitForever(doNothing).start(); new WaitForever(doNothing).start(); new WaitForever(doNothing).start(); Thread.sleep(100); doNothing.start(); while(true) { Thread.sleep(10); } } static class WaitForever extends Thread { private DoNothing doNothing; public WaitForever(DoNothing doNothing) { this.doNothing = doNothing; } @Override public void run() { synchronized (doNothing) { try { doNothing.wait(); // will wait forever here as nobody notifies here } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("Unreachable Code"); } } } static class DoNothing extends Thread { @Override public void run() { System.out.println("Do Nothing "); } } } 

One difference between implementing Runnable and extending Thread is that by extending Thread, each of your threads has a unique object associated with it, whereas implementing Runnable, many threads can share the same object instance.

A class that implements Runnable is not a thread and just a class. For a Runnable to be executed by a Thread, you need to create an instance of Thread and pass the Runnable instance in as the target.

In most cases, the Runnable interface should be used if you are only planning to override the run() method and no other Thread methods. This is important because classes should not be subclassed unless the programmer intends on modifying or enhancing the fundamental behavior of the class.

When there is a need to extend a superclass, implementing the Runnable interface is more appropriate than using the Thread class. Because we can extend another class while implementing Runnable interface to make a thread. But if we just extend the Thread class we can’t inherit from any other class.