[concurrency-interest] Starting a Thread within a constructor, what can go wrong?

Gregg Wonderly gregg at cytetech.com
Sat Dec 11 15:24:18 EST 2010


One of the more problematic patterns is doing

public MyClass implements Runnable {
	private final SomeClass val = new SomeClass();
	public MyClass() {
		new Thread(this).start();
	}
	public void run() {
		val.doSomething();
	}
}

The initialized final value will not be visible until the constructor completes 
in my experience, and if you instead do

public MyClass implements Runnable {
	private final SomeClass val;
	public MyClass() {
		val = new SomeClass();
		new Thread(this).start();
	}
	public void run() {
		val.doSomething();
	}
}

Then val is visible when the thread starts because of the happens before that 
was alluded to before.

Gregg Wonderly

On 12/10/2010 9:24 PM, Joe Bowbeer wrote:
> Marco,
>
> In addition to the other excellent replies, I'll add my $0.02
>
> The original SwingWorker, which is a class designed for subclassing, started its
> worker thread in its constructor and this led to many problems in practice.
>
> Another problem with starting a thread in a constructor is that it is not
> expected.  My expectation is that a constructor merely creates.  If I want
> action, I'll call a method.
>
> In addition, I would ask why you're even creating a thread?  Consider creating a
> task instead and using an executor.

Executors are not always the best choice for "forever" threads.   Although there 
are some interesting recovery patterns you can create using single thread executors.

> On Fri, Dec 10, 2010 at 5:30 PM, Marco Villalobos wrote:
>
>     QUESTION:
>
>     Can somebody please give me guidance on how I could possibly create a
>     suite of test cases that run in TestNG or JUnit that can prove the
>     thread unsafeness of this bad practice?
>
>     BACKGROUND
>
>     I'm trying to convince my colleague that starting a thread within a
>     constructor compromises thread safety.
>
>     I understand that, "publishing objects before they are fully
>     constructed can compromise thread safety."
>
>     But I would like an elaboration on how it compromises thread safety?
>
>     I understand that publishing the "this" reference would break
>     encapsulation, allowing other classes and threads to potentially
>     change the state of my object in an unthread safe manner.
>
>     But more specifically, what are the side affects of an object not
>     being fully constructed, yet published through a thread.start in a
>     constructor.
>
>     Here is an example of how "not to do things".
>
>     public class DontDoThis {
>
>       public synchronized void mutateMe() {
>           // ... I'm mutating this...
>       }
>
>       public final Thread t;
>
>       public DontDoThis() {
>           t = new Thread(new Runnable() {
>               public void run() {
>                   mutateMe();
>               }
>           });
>           t.start();   //     BAD BAD BAD Don't do this.
>       }
>     }
>
>     Can somebody please give me guidance on how I could possibly create a
>     suite of test cases that run in TestNG or JUnit that can prove the
>     thread unsafeness of this bad practice?
>
>     I want to make a short presentation on the issue.  If I provide a
>     compilable and running test case, that would be amazing :)
>
>     -Marco
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list