Page History

Concurrency related issues manifest themselves when assumptions are made about the multithreaded behavior of derived classes. An overridden synchronized method's contract may be violated if a subclass defines an implementation that is not safe for concurrent access. 

{mc}
// This line is not necessary because thread-safe implies all kinds of synchronization
Furthermore, if an overridden method makes concurrency guarantees, even if it is not itself synchronized, the subclass must adhere to those guarantees.
{mc}

The guideline [CON04-J. Synchronize using an internal private lock object] recommends documenting the locking strategy in use for classes designed for inheritance. This information is useful when deciding the locking strategy of subclasses. 

h2. Noncompliant Code Example (synchronized method)

This noncompliant code example defines a {{synchronized}} {{doSomething()}} method in class {{Base}}. 

{code:bgColor=#FFCCCC}
class Base {
  public synchronized void doSomething() {
    // ...	
  }
}

class SubDerived extends Base {
  @Override public void doSomething() {
    // ...		
  }
}
{code}

The {{

 class {{Base}} can be safely used by multiple threads. However, if a subclass {{Sub}} overrides the method but leaves it unsynchronized, its instance cannot be safely used by multiple threads. 

This problem is hard to notice because threads that accept instances of {{Base}} also accept instances of its subclasses. Consequently, the threads may incorrectly assume that the subclasses are thread-safe.


h2. Compliant Solution (synchronized method)

This compliant solution synchronizes the {{doSomething()}} method of the subclass. 

{code:bgColor=#ccccff}
class Base {
  public synchronized void doSomething() {
    // ...	
  }
}

class SubDerived extends Base {
  @Override public synchronized void doSomething() {
    // ...		
  }
}
{code}

This compliant solution does not violate [CON04-J. Synchronize using an internal private lock object] because the accessibility of the class is package-private which is allowable when untrusted code cannot infiltrate the package.


h2. Noncompliant Code Example (private lock)

This noncompliant code example defines a {{doSomething()}} method in class {{Base}} that uses an internal private lock, in accordance with [CON04-J. Synchronize using an internal private lock object].

{code:

class Base {

  public synchronized void doSomething() {
    // ...
  }
}

class Derived extends Base {
  private final Object lock = new Object();

  @Override public void doSomething() {
    synchronized (lock) {
      // ...
    }
  }
}

bgColor=#FFCCCC}
public class Base {
  private final Object lock = new Object();

  public void doSomething() {
    synchronized (lock) {
      // ...	
    }
  }
}

class SubDerived extends Base {
  Logger logger = // Initialize

  @Override public void doSomething() {
    try {
      super.doSomething();
    } finally() {
      logger.log(Level.FINE, "Did something"); 
    }
  }
}
{code}

The {{doSomething()}} method of class {{Sub}} cannot be safely used by multiple threads because it is not thread-safe. It is possible that multiple threads may cause the entries to be logged in a different order than the one in which the tasks are performed.

h2. Compliant Solution (private lock)

This compliant solution synchronizes the {{doSomething()}} method of the subclass. 

{code:bgColor=#ccccff}
public class Base {
  private final Object lock = new Object();

  public void doSomething() {
    synchronized (lock) {
      // ...	
    }
  }
}

class SubDerived extends Base {
  Logger logger = // Initialize

  private final Object lock = new Object();

  @Override public void doSomething() {
    synchronized (lock) {
      try {
        super.doSomething();
      } finally() {
        logger.log(Level.FINE, "Did something"); 
      }
    }
  }
}
{code}