...
Thread-safe classes (which may not be strictly immutable), such as Container in this noncompliant code example, must not declare fields as non-final and non-volatile (see CON09-J. Do not assume that classes having only immutable members are thread-safe). Non-final, non-volatile fields may be observed by other threads before the sub-objects' initialization has concluded.
...
| Wiki Markup |
|---|
Alternative solutions to using {{volatile}} for safe publication are described in [CON26-J. Do not publish partially-constructed objects]. These alternative solutions are recommended if the values of the {{map}} can be mutated after initialization because the use of {{volatile}} only guarantees "one time safe publication" \[[Goetz 06|AA. Java References#Goetz 06]\], that is the reference is made visible only after initialization. There is no guarantee that any future updates to the map's contents will be visible immediately (see [CON11-J. Do not assume that declaring an object volatile guarantees visibility of its members] for more information). |
Risk Assessment
Failing to use volatile to guarantee visibility of shared values across multiple thread and prevent reordering of accesses can result in unpredictable control flow.
...