¿Cuándo llamarías a thread.run () de java en lugar de thread.start ()?

¿Cuándo llamarías a Java en thread.run()lugar de thread.start()?

Es posible que desee llamar a run () en una prueba unitaria particular que se refiera estrictamente a la funcionalidad y no a la concurrencia.

Nunca. Llamar a run () directamente solo ejecuta el código sincrónicamente (en el mismo hilo), como una llamada a un método normal.

Tomado de las preguntas frecuentes sobre hilos de Java de estilo de código :

P: ¿Cuál es la diferencia entre los métodos start () y run () de un hilo?

R: Los métodos separados start () y run () de la clase Thread proporcionan dos formas de crear programas con subprocesos. El método start () inicia la ejecución del nuevo hilo y llama al método run (). El método start () regresa inmediatamente y el nuevo hilo normalmente continúa hasta que regresa el método run ().

El método run () de la clase Thread no hace nada, por lo que las subclases deben anular el método con código para ejecutar en el segundo hilo. Si se crea una instancia de un hilo con un argumento Runnable, el método run () del hilo ejecuta el método run () del objeto Runnable en el nuevo hilo.

Dependiendo de la naturaleza de su programa enhebrado, llamar al método Thread run () directamente puede dar el mismo resultado que llamar a través del método start (), pero en el último caso, el código se ejecuta en un nuevo hilo.

La ejecución thread.run()no crea una nueva Threaden la que se ejecuta su código. Simplemente ejecuta el código en el Thread actual desde el que thread.run()se invoca el código.

La ejecución thread.start()crea un nuevo hilo de nivel de sistema operativo en el run()que se llama al método.

En esencia:

Programación de un solo hilo → Llamar directamente al run()método

Programación multiproceso → Llamar al start()método

Además, como han mencionado otros, "probar" parece ser el único caso aconsejable en el que puede invocar run()directamente desde su código.

Ya se ha aludido a esto, pero para que quede claro: crear un nuevo objeto Thread solo para llamar a su método run () es innecesariamente caro y debería ser una señal de alerta importante. Sería un diseño mucho mejor y más desacoplado crear un impl Runnable y (a) llamar a su método run () directamente si ese es el comportamiento deseado, o (b) construir un nuevo Thread con ese Runnable e iniciar el Thread.

Mejor aún, para un desacoplamiento aún mayor, consulte la Executorinterfaz y el marco en JDK 5 y versiones posteriores. Esto le permite, en pocas palabras, desacoplar la ejecución de la tarea (la instancia Runnable) de cómo se ejecuta (la implementación Executor, que podría ejecutar el Runnable en el Thread actual, en un Thread nuevo, utilizando un Thread existente de un grupo, Y qué no).

Llame thread.start(), a su vez llamará thread.run(). No puedo pensar en un caso en el que quiera omitir thread.start()e ir directamente athread.run()

Los métodos separados start()y run()de la clase Thread proporcionan dos formas de crear programas con subprocesos. El start()método inicia la ejecución del nuevo hilo y llama al run()método. El start()método regresa inmediatamente y el nuevo hilo normalmente continúa hasta run()que regresa el método.

El run()método de la clase Thread no hace nada, por lo que las subclases deben anular el método con código para ejecutar en el segundo hilo. Si se crea una instancia de un hilo con un argumento Runnable, el run()método del hilo ejecuta el run()método del objeto Runnable en el nuevo hilo.

Dependiendo de la naturaleza de su programa enhebrado, llamar al run()método Thread directamente puede dar el mismo resultado que llamar a través del start()método, pero en el último caso, el código se ejecuta en un nuevo hilo.

referencia

Si la pregunta era: "¿por qué se llama al método de inicio del hilo en lugar de ejecutar el método directamente?", Entonces he respondido con un código de ejemplo a continuación. Espero que aclare. En el ejemplo siguiente:

/*
By calling t1.start(), 
we are getting the main calling thread returned immediately 
after the t1.start() called and is ready to proceed for other 
operations.And the thread t1 starts executing the run method of the object r. 
Hence the the output will be:

      I am the main thread , i created thread t1 and had it execute run method, which is currently looping from 0 to 1000000

      I am done executing run method of testThread

*/


/* If we call t1.run() instead of t1.start(), (just replace t1.start() with t1.run() in the code for testing)
 its like a regular method call and the main thread will not return until the run method completes, 
 hence the output will be:

         I am done executing run method of testThread

         I am the main thread , i created thread t1 and had it execute run method, which is currently looping for i to 1000000

*/


class testThread implements Runnable{

 public void run()
 {
     for(int i=0;i<1000000;i++){} //a simple delay block to clarify.

     System.out.println("I am done executing run method of testThread");

 }  
}

public class mainClass{

   public static void main(String [] args)
    {
          testThread r = new testThread();
          Thread t1 = new Thread(r);
          t1.start();  /* Question is: can we call instead t1.run() */  
          System.out.println("I am the main thread , i created thread t1 and had it execute run method, which is currently looping for i to 1000000");

    }
}

Cuando desee que se ejecute sincrónicamente. Llamar al método de ejecución en realidad no le dará múltiples subprocesos. El método de inicio crea un nuevo hilo que llama al método de ejecución.

Si desea ejecutar el contenido de run () como lo haría con cualquier otro método. No para iniciar un hilo, por supuesto.

Suponiendo que conoce el uso del método de inicio y ejecución, es decir, síncrono frente a asíncrono; El método de ejecución se puede utilizar solo para probar la funcionalidad.

Además, en algunas circunstancias, la misma clase de subproceso se puede usar en dos lugares diferentes con requisitos de funcionalidad de sincronización y asincronización al tener dos objetos diferentes con el método de ejecución de uno y el método de inicio de otro invocado.

Al menos en la JVM 1.6., Hay un poco de verificación y la ejecución se llama de forma nativa:

 public synchronized void start() {
        /**
     * This method is not invoked for the main method thread or "system"
     * group threads created/set up by the VM. Any new functionality added 
     * to this method in the future may have to also be added to the VM.
     *
     * A zero status value corresponds to state "NEW".
         */
        if (threadStatus != 0)
            throw new IllegalThreadStateException();
        group.add(this);
        start0();
        if (stopBeforeStart) {
        stop0(throwableFromStop);
    }
    }

    private native void start0();

Solo una nota a los excelentes comentarios anteriores: a veces escribes un código de múltiples subprocesos que usa el método "start" para ejecutar diferentes subprocesos. Le resultará mucho más fácil si usa "ejecutar" (en lugar de "iniciar) para depurar, ya que hace que el código se ejecute sincrónicamente y depurarlo mucho más fácilmente.

public class TestClass implements Runnable {
    public static void main(String[] args) {
        TestClass tc = new TestClass();

        Thread t1 = new Thread(tc);
        System.out.println("Before Starting Thread " + Thread.currentThread().hashCode());
        t1.start();
        System.out.println("After Starting Thread " + Thread.currentThread().hashCode());
    }

    @Override
    public void run() {
        System.out.println("TestClass Run method is  Running with thread " + Thread.currentThread().hashCode());        
    }
}