When would you call java's thread.run() instead of thread.start()?

Question

... the question says it all I believe!

Answer 1

Call thread.start(), it will in turn call thread.run(). Can't think of a case when you would want to bypass thread.start() and go directly to thread.run()

Answer 2

Never. Calling run() directly just executes the code synchronously (in the same thread), just like a normal method call.

Answer 3

When you want it to run synchronously. Calling the run method won't actually give you multi-threading. The start method creates a new thread which calls the run method.

Answer 4

Taken form the Code Style Java threads FAQ:

Q: What's the difference between a thread's start() and run() methods?

A: The separate start() and run() methods in the Thread class provide two ways to create threaded programs. The start() method starts the execution of the new thread and calls the run() method. The start() method returns immediately and the new thread normally continues until the run() method returns.

The Thread class' run() method does nothing, so sub-classes should override the method with code to execute in the second thread. If a Thread is instantiated with a Runnable argument, the thread's run() method executes the run() method of the Runnable object in the new thread instead.

Depending on the nature of your threaded program, calling the Thread run() method directly can give the same output as calling via the start() method, but in the latter case the code is actually executed in a new thread.

Answer 5

If you want to execute the contents of run() like you would of any other method. Not to start a thread, of course.

Answer 6

You might want to call run() in a particular unit test that is concerned strictly with functionality and not with concurrency.

Answer 7

Assuming that you know the start and run method usage i.e. synchronous vs. asynchronous; run method can be used just to test the functionality.

Plus in some circumstances, the same thread class can be used in two different places with synch and asynch functionality requirements by having two different objects with one's run method and other's start method being invoked.

Answer 8

At least in the JVM 1.6., there's a bit of checking and run is called natively:

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

Answer 9

This has already been alluded to, but just to be clear: creating a new Thread object only to call it's run() method is needlessly expensive and should be a major red flag. It would be a much better, more decoupled design to create a Runnable impl and either (a) call it's run() method directly if that's the desired behavior, or (b) construct a new Thread with that Runnable and start the Thread.

Better yet, for even more decoupling, check out the Executor interface and framework in JDK 5 and newer. This allows you, in a nutshell, to decouple task execution (the Runnable instance) from how it is executed (the Executor implementation, which might execute the Runnable in the current Thread, in a new Thread, using an existing Thread from a pool, and whatnot).