What does object owning a thread mean?

Question

I was reading this article by Brian Goetz. Under the section Don't start threads from within constructors he says "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. " What does he mean by "often when an object owns a thread"?

It can also *be* an object if you refer to an instance of the [Thread](http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html) class. — matsev, Jun 30 '12 at 18:10
@Jeffrey I was reading this article by Brian Goetz http://www.ibm.com/developerworks/java/library/j-jtp0618/index.html#code4 and while reading the section "Don't start threads from within constructors" I got a little bit confused as to how an object owns a thread. I thought it was the other way around. — Inquisitive, Jun 30 '12 at 18:12
Threads aren't exactly owned per say, by objects. They are more or less owned by the process spawning them. You can spawn threads and maintain a handle to the thread, that may be consider an object, but it doesn't exactly own the thread as it's more of a reference. However, much of this, like Jeffrey said, is determined by the context. Do you have specific sample code in mind? — Jason Huntley, Jun 30 '12 at 18:12
-1; the title **does not** say it all... far too vague. Any references? — home, Jun 30 '12 at 18:20

score 4 · Answer 1 · answered Jun 30 '12 at 18:15

It can be either, or both. A thread is represented by an object (an instance of the java.lang.Thread class), and how that object relates to other objects is entirely up to you.

If the code running in the thread creates some objects that are used only by the thread, you can think of those objects as being owned by the thread. And if you have some other object that's responsible for creating, starting, and controlling the thread, you can think of that object as owning the thread. But neither of these things is required or enforced by Java; it's your choice when designing your software.

score 2 · Answer 2 · answered Jun 30 '12 at 20:41

Goetz's intended meaning is quite simple, and is not specific to a Thread. It simply means that an object owns the Thread instance through a composition relation—it holds a private reference to it and doesn't let any outside objects access to it.

You could also note that this kind of ownership is not really enforceable since any code that executes on that thread will also have access to the Thread instance via the currentThread method.

score 1 · Accepted Answer · edited May 23 '17 at 11:43

I don't think Goetz means to be taken too literally about an object owning a thread. He just means the thread was started within some other object's constructor, so it can access the state of that object possibly before it has a chance to finish getting constructed. There is no formal, meaningful ownership relationship, it's all contextual. For instance you might say whoever has a reference to the thread is the owner because they can cancel it, but the reference can get passed around, there's nothing special about the object that first created the thread.

If you read Goetz' book Java Concurrency in Practice it covers design techniques like thread confinement where the scope of things that a thread interacts with are restricted. Also you can create objects so that only one thread can see them, such as when using a ThreadLocal. So you can design your abstractions to create ownership relationships, but it's up to you.

What does object owning a thread mean?

3 Answers3