Read that the following code is an example of "unsafe construction" as it allows this reference to escape. I couldn't quite get how 'this' escapes. I am pretty new to the java world. Can any one help me understand this.
public class ThisEscape {
public ThisEscape(EventSource source) {
source.registerListener(
new EventListener() {
public void onEvent(Event e) {
doSomething(e);
}
});
}
}
The example you have posted in your question comes from "Java Concurrency In Practice" by Brian Goetz et al. It is in section 3.2 "Publication and escape". I won't attempt to reproduce the details of that section here. (Go buy a copy for your bookshelf, or borrow a copy from your co-workers!)
The problem illustrated by the example code is that the constructor allows the reference to the object being constructed to "escape" before the constructor finishes creating the object. This is a problem for two reasons:
If the reference escapes, something can use the object before its constructor has completed the initialization and see it in an inconsistent (partly initialized) state. Even if the object escapes after initialization has completed, declaring a subclass can cause this to be violated.
According to JLS 17.5, final attributes of an object can be used safely without synchronization. However, this is only true if the object reference is not published (does not escape) before its constructor finished. If you break this rule, the result is an insidious concurrency bug that might bite you when the code is executed on a multi-core / multi-processor machines.
The
ThisEscape
example is sneaky because the reference is escaping via thethis
reference passed implicitly to the anonymousEventListener
class constructor. However, the same problems will arise if the reference is explicitly published too soon.Here's an example to illustrate the problem of incompletely initialized objects:
If the
Leaker.leak(...)
method callsgetName()
on the leaked object, it will getnull
... because at that point in time the object's constructor chain has not completed.Here's an example to illustrate the unsafe publication problem for
final
attributes.Some runs of this application may print "OUCH!" instead of "OK", indicating that the main thread has observed the
Unsafe
object in an "impossible" state due to unsafe publication via theleak
array. Whether this happens or not will depend on your JVM and your hardware platform.Now this example is clearly artificial, but it is not difficult to imagine how this kind of thing can happen in real multi-threaded applications.
The current Java Memory Model was specified in Java 5 (the 3rd edition of the JLS) as a result of JSR 133. Prior to then, memory-related aspects of Java were under-specified. Sources that refer to earlier versions / editions are out of date, but the information on the memory model in Goetz edition 1 is up to date.
There are some technical aspects of the memory model that are apparently in need of revision; see https://openjdk.java.net/jeps/188 and https://www.infoq.com/articles/The-OpenJDK9-Revised-Java-Memory-Model/. However, this work has yet to appear in a JLS revision.
I just had the exact same question while reading "Java Concurrency In Practice" by Brian Goetz.
Stephen C's answer (the accepted one) is excellent! I only wanted to add on top of that one more resource I discovered. It is from JavaSpecialists, where Dr. Heinz M. Kabutz analyzes exactly the code example that devnull posted. He explains what classes are generated (outer, inner) after compiling and how
this
escapes. I found that explanation useful so I felt like sharing :)issue192 (where he extends the example and provides a race condition.)
issue192b (where he explains what kind of classes are generated after compiling and how
this
escapes.)I had the exact same doubt.
The thing is that every class that gets instantiated inside other class has a reference to the enclosing class in the variable
$this
.This is what java calls a synthetic, it's not something you define to be there but something java does for you automatically.
If you want to see this for yourself put a breakpoint in the
doSomething(e)
line and check what propertiesEventListener
has.My guess is that
doSomething
method is declared inThisEscape
class, in which case reference certainly can 'escape'.I.e., some event can trigger this
EventListener
right after its creation and before execution ofThisEscape
constructor is completed. And listener, in turn, will call instance method ofThisEscape
.I'll modify your example a little. Now variable
var
can be accessed indoSomething
method before it's assigned in constructor.