BlazkowiczВы наверное про поле CallableClass ?
Нет я имел ввиду именно локальную переменную x метода main. А именно то, что она может передаться новым потокам непроинициализированной.
Blazkowicz_quark_finall это гарантирует. Почитайте
Java Concurrency in Practice - узнаете много нового.
Здесь гонок нет. Если даёте ссылку то давайте на конкретную главу, хотя бы. А так пальцем в небо. Читал. Узнал много нового. Как это применяется к указанному коду?
Глава 3.5. Safe Publication
3.5.1. Improper Publication: When Good Objects Go Bad
You cannot rely on the integrity of partially constructed objects. An observing thread could see the object in an inconsistent state, and then later see its state suddenly change, even though it has not been modified since publication.
In fact, if the Holder in Listing 3.15 is published using the unsafe publication idiom in Listing 3.14, and a thread other than the publishing thread were to call assertSanity, it could throw AssertionError![15]
[15] The problem here is not the Holder class itself, but that the Holder is not properly published. However, Holder can be made immune to improper publication by declaring the n field to be final, which would make Holder immutable; see Section 3.5.2.
Listing 3.15. Class at Risk of Failure if Not Properly Published.
1.
2.
3.
4.
5.
6.
7.
8.
public class Holder {
private int n;
public Holder(int n) { this.n = n; }
public void assertSanity() {
if (n != n)
throw new AssertionError("This statement is false.");
}
}
Because synchronization was not used to make the Holder visible to other threads, we say the Holder was not properly published. Two things can go wrong with improperly published objects. Other threads could see a stale value for the holder field, and thus see a null reference or other older value even though a value has been placed in holder. But far worse, other threads could see an up to date value for the holder reference, but stale values for the state of the Holder.
[16] To make things even less predictable, a thread may see a stale value the first time it reads a field and then a more up to date value the next time, which is why assertSanity can throw AssertionError.
[16] While it may seem that field values set in a constructor are the first values written to those fields and therefore that there are no "older" values to see as stale values, the Object constructor first writes the default values to all fields before subclass constructors run. It is therefore possible to see the default value for a field as a stale value.
At the risk of repeating ourselves, some very strange things can happen when data is shared across threads without sufficient synchronization.
...
3.5.2. Immutable Objects and Initialization Safety
...
To publish an object safely, both the reference to the object and the object's state must be made visible to other threads at the same time. A properly constructed object can be safely published by:
Initializing an object reference from a static initializer;
Storing a reference to it into a volatile field or AtomicReference;
Storing a reference to it into a final field of a properly constructed object; or
Storing a reference to it into a field that is properly guarded by a lock.
В данном случае локальная переменная x метода main как раз публикуется (передается конструкторам CallableClass) не безопасно. Поэтому другие потоки могут увидеть её в непроинициализированном состоянии.
final обеспечивает безопасную публикацию.
