08. Locking (LCK)

Guidelines

• Page:
  LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code
• Page:
  LCK01-J. Do not synchronize on objects that may be reused
• Page:
  LCK02-J. Do not synchronize on the class object returned by getClass()
• Page:
  LCK03-J. Do not synchronize on the intrinsic locks of high-level concurrency objects
• Page:
  LCK04-J. Do not synchronize on a collection view if the backing collection is accessible
• Page:
  LCK05-J. Synchronize access to static fields that can be modified by untrusted code
• Page:
  LCK06-J. Do not use an instance lock to protect shared static data
• Page:
  LCK07-J. Avoid deadlock by requesting and releasing locks in the same order
• Page:
  LCK08-J. Ensure actively held locks are released on exceptional conditions
• Page:
  LCK09-J. Do not perform operations that can block while holding a lock
• Page:
  LCK10-J. Use a correct form of the double-checked locking idiom
• Page:
  LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy
• Page:
  Rule 09. Locking (LCK)

Introduction

Memory that can be shared between threads is called shared memory or heap memory. The term variable as used in this section refers to both fields and array elements [[JLS 05]]. Variables that are shared between threads are referred to as shared variables. All instance fields, static fields, and array elements are shared variables and are stored in heap memory. Local variables, formal method parameters, and exception handler parameters are never shared between threads and are unaffected by the [memory model].

In modern shared-memory multiprocessor architectures, each processor has one or more levels of cache that are periodically reconciled with main memory as shown in the following figure:

The visibility of writes to shared variables can be problematic because the value of a shared variable may be cached; writing its value to main memory may be delayed. Consequently, another thread may read a stale value of the variable.

A further concern is that concurrent executions of code are typically interleaved and statements may be reordered by the compiler or runtime system to optimize performance. This results in execution orders that are difficult to discern by examination of the source code. Failure to account for possible reorderings is a common source of data races.

Consider the following example in which a and b are (shared) global variables or instance fields, but r1 and r2 are local variables that are inaccessible to other threads.

Initially, let a = 0 and b = 0.

VNA06-J. Do not assume that declaring a reference volatile guarantees visibility of the members of the referenced object      The CERT Oracle Secure Coding Standard for Java