Threads: calling thread.start() within its own constructor

I was thinking to improve my threading fundamentals, so I planned to make few notes for myself that will assist me in future (Obviously at the time of Interviews). Following questions and answers have been taken from stackoverflow.com. This post is a sticky notes post for me. Please do not use the answers for reference purpose.

This post will not provide lot of information, but it is good to know.

calling thread.start() within its own constructor

public class MyNewThread implements Runnable {

    Thread t;

Int counter;

String name;

    MyNewThread() {

        t = new Thread (this, "Data Thread");

        t.start();

counter = 0;

name = “Default”;

    }

    public void run()  {

        // New Thread code here

    }

public class Main {

    public static void main(String[] args) throws Exception{

        new MyNewThread();

        // First thread code there

    } 

}

On executing the program, compiler warns from starting the thread at the time of initialization.

Simplest answer is as following

In this instance the MyNewThread.this is said to escape the constructor. That means that the object is available to reference but all of its fields that are being built in the constructor may not be created. To take this to another level what if b was final you would expect it to be available but it is not ensured. This is known as partially constructed objects and is perfectly legal in java.

For memory-safety reasons, you shouldn't expose a reference to an object or that object's fields to another thread from within its constructor. Assuming that your custom thread has instance variables, by starting it from within the constructor, you are guaranteed to violate, though legal, the Java Memory Model guidelines. 

Another good reason for not starting the thread in constructor is convention. Anyone familiar with Java will assume that the thread has not been started. Worse yet, if they write their own threading code which interacts in some way with yours, then some threads will need to call start and others won't.

This may not seem compelling when you're working by yourself, but eventually you'll have to work with other people, and it's good to develop good coding habits so that you'll have an easy time working with others and code written with the standard conventions.

Various other such memory violation issues are reported at this place. http://www.ibm.com/developerworks/java/library/j-jtp0618/index.html

Following text is specific to our case.

“Don't start threads from within constructors

A special case of the problem in Listing 4 is starting a thread from within a constructor, because often when an object owns a thread, either that thread is an inner class or we pass the this reference to its constructor (or the class itself extends the Thread class). If an object is going to own a thread, it is best if the object provides a start() method, just like Thread does, and starts the thread from the start() method instead of from the constructor. While this does expose some implementation details (such as the possible existence of an owned thread) of the class via the interface, which is often not desirable, in this case the risks of starting the thread from the constructor outweigh the benefit of implementation hiding.”