Escaping

In a thread-safe class, non-final fields should generally be private (or possibly volatile) to ensure that they cannot be accessed by other threads in an unsafe manner.

Recommendation

If the field does not change, mark it as final. If the field is mutable, mark it as private and provide properly synchronized accessors.

References

• Java Language Specification, chapter 17: Threads and Locks.
• Java concurrency package: java.util.concurrent.

Safe publication

In a thread-safe class, values must be published safely to avoid inconsistent or unexpected behavior caused by visibility issues between threads. If a value is not safely published, one thread may see a stale or partially constructed value written by another thread, leading to subtle concurrency bugs.

In particular, values of primitive types should not be initialised to anything but their default values (which for Object is null) unless this happens in a static context.

Techniques for safe publication include:

• Using synchronized blocks or methods to ensure that a value is fully constructed before it is published.
• Using volatile fields to ensure visibility of changes across threads.
• Using thread-safe collections or classes that provide built-in synchronization, such as are found in java.util.concurrent.
• Using the final keyword to ensure that a reference to an object is safely published when the object is constructed.

Recommendation

Choose a safe publication technique that fits your use case. If the value only needs to be written once, say for a singleton, consider using the final keyword. If the value is mutable and needs to be shared across threads, consider using synchronized blocks or methods, or using a thread-safe collection from java.util.concurrent.

Example

In the following example, the value of value is not safely published. The produce method creates a new object and assigns it to the field value. However, the field is not declared as volatile, and there are no synchronization mechanisms in place to ensure that the value is fully constructed before it is published.

@ThreadSafe
public class UnsafePublication {
    private Object value;

    public void produce() {
        value = new Object(); // Not safely published, other threads may see the default value null
    }

    public Object getValue() {
        return value;
    }
}

To fix this example, declare the field value as volatile, or use synchronized blocks or methods to ensure that the value is fully constructed before it is published. We illustrate the latter with the following example:

public class SafePublication {
    private Object value;

    public synchronized void produce() {
        value = new Object(); // Safely published using synchronization
    }

    public synchronized Object getValue() {
        return value;
    }
}

References

• Java Language Specification, chapter 17: Threads and Locks.
• Java concurrency package: java.util.concurrent.

Not thread-safe

In a thread-safe class, all field accesses that can be caused by calls to public methods must be properly synchronized.

Recommendation

Protect the field access with a lock. Alternatively mark the field as volatile if the write operation is atomic. You can also choose to use a data type that guarantees atomic access. If the field is immutable, mark it as final.

References

• Java Language Specification, chapter 17: Threads and Locks.
• Java concurrency package: java.util.concurrent.