1. Java Concurrency and Multithreading Tutorial
2. Multithreading Benefits
3. Multithreading Costs
4. Concurrency Models
5. Same-threading
6. Single-threaded Concurrency
7. Concurrency vs. Parallelism
8. Creating and Starting Java Threads
9. Java Virtual Threads
10. Race Conditions and Critical Sections
11. Thread Safety and Shared Resources
12. Thread Safety and Immutability
13. Java Memory Model
14. Java Happens Before Guarantee
15. Java Synchronized Blocks
16. Java Volatile Keyword
17. CPU Cache Coherence in Java Concurrency
18. False Sharing in Java
19. Java ThreadLocal
20. Thread Signaling in Java
21. Deadlock
22. Deadlock Prevention
23. Starvation and Fairness
24. Nested Monitor Lockout
25. Slipped Conditions
26. Locks in Java
27. Read / Write Locks in Java
28. Reentrance Lockout
29. Semaphores
30. Blocking Queues
31. The Producer Consumer Pattern
32. Thread Pools
33. Thread Congestion in Java
34. Compare and Swap
35. Anatomy of a Synchronizer
36. Non-blocking Algorithms
37. Amdahl's Law
38. Java Concurrency References

• The Reference is not Thread Safe!

Race conditions occur only if multiple threads are accessing the same resource, and one or more of the threads write to the resource. If multiple threads read the same resource race conditions do not occur.

We can make sure that objects shared between threads are never updated by any of the threads by making the shared objects immutable, and thereby thread safe. Here is an example:

public class ImmutableValue{

  private int value = 0;

  public ImmutableValue(int value){
    this.value = value;
  }

  public int getValue(){
    return this.value;
  }
}

Notice how the value for the ImmutableValue instance is passed in the constructor. Notice also how there is no setter method. Once an ImmutableValue instance is created you cannot change its value. It is immutable. You can read it however, using the getValue() method.

If you need to perform operations on the ImmutableValue instance you can do so by returning a new instance with the value resulting from the operation. Here is an example of an add operation:

public class ImmutableValue{

  private int value = 0;

  public ImmutableValue(int value){
    this.value = value;
  }

  public int getValue(){
    return this.value;
  }

  
      public ImmutableValue add(int valueToAdd){
      return new ImmutableValue(this.value + valueToAdd);
      }
  
}

Notice how the add() method returns a new ImmutableValue instance with the result of the add operation, rather than adding the value to itself.

The Reference is not Thread Safe!

It is important to remember, that even if an object is immutable and thereby thread safe, the reference to this object may not be thread safe. Look at this example:

public class Calculator{
  private ImmutableValue currentValue = null;

  public ImmutableValue getValue(){
    return currentValue;
  }

  public void setValue(ImmutableValue newValue){
    this.currentValue = newValue;
  }

  public void add(int newValue){
    this.currentValue = this.currentValue.add(newValue);
  }
}

The Calculator class holds a reference to an ImmutableValue instance. Notice how it is possible to change that reference through both the setValue() and add() methods. Therefore, even if the Calculator class uses an immutable object internally, it is not itself immutable, and therefore not thread safe. In other words: The ImmutableValue class is thread safe, but the use of it is not. This is something to keep in mind when trying to achieve thread safety through immutability.

To make the Calculator class thread safe you could have declared the getValue(), setValue(), and add() methods synchronized. That would have done the trick.