Solution: Double-Checked Locking Pattern

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

/**
 * Double-Checked Locking - Naive Implementation
 * 
 * WARNING: This implementation is BROKEN in most languages/runtimes!
 * Shown here only to illustrate the pattern structure.
 */
class Singleton {
    private static instance: Singleton | null = null;
    private static mutex = new Mutex();
    
    private constructor() {
        // Expensive initialization
        this.initializeResources();
    }
    
    private initializeResources(): void {
        // Setup database connections, load config, etc.
    }
    
    /**
     * The Double-Checked Locking Pattern
     * 
     * Structure:
     * 1. First check (unsynchronized) - fast path for common case
     * 2. Synchronize (only if first check fails)
     * 3. Second check (synchronized) - guard against race
     * 4. Initialize (only if both checks fail)
     */
    public static async getInstance(): Promise<Singleton> {
        // ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
        // FIRST CHECK: No lock - fast path
        // ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
        if (Singleton.instance === null) {
            
            // ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
            // LOCK: Only acquire if instance might be null
            // ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
            await Singleton.mutex.acquire();
            try {
                
                // ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                // SECOND CHECK: Verify still null after lock
                // (Another thread may have initialized while we waited)
                // ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                if (Singleton.instance === null) {
                    
                    // ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                    // INITIALIZE: Create the instance
                    // ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                    Singleton.instance = new Singleton();
                }
            } finally {
                Singleton.mutex.release();
            }
        }
        
        // Return the (supposedly) initialized instance
        return Singleton.instance;
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// What you write:
instance = new Singleton();
 
// What this expands to at the low level:
// Step 1: Allocate memory for Singleton object
// Step 2: Initialize fields to default values
// Step 3: Run constructor (assign fields to proper values)
// Step 4: Assign the memory address to 'instance'
 
// What the compiler/CPU might REORDER to:
// Step 1: Allocate memory for Singleton object
// Step 2: Assign the memory address to 'instance'  ← MOVED UP!
// Step 3: Initialize fields to default values
// Step 4: Run constructor (assign fields to proper values)
 
// The reordering is valid for single-threaded execution:
// The final result is the same—'instance' points to a fully
// constructed object. But between steps 2 and 4, 'instance'
// points to a PARTIALLY CONSTRUCTED object!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

/**
 * Let's examine what happens during object construction
 * and how reordering creates the bug
 */
 
class ConfigService {
    private configData: Map<string, string>;
    private initialized: boolean;
    private connectionPool: ConnectionPool;
    
    constructor() {
        // Step A: Initialize configData
        this.configData = new Map();
        this.configData.set("apiUrl", "https://api.example.com");
        
        // Step B: Set up connection pool
        this.connectionPool = new ConnectionPool(10);
        
        // Step C: Mark as initialized
        this.initialized = true;
    }
    
    getApiUrl(): string | undefined {
        if (!this.initialized) {
            throw new Error("Not initialized!");
        }
        return this.configData.get("apiUrl");
    }
}
 
// The expression "instance = new ConfigService()" involves:
//
// INTENDED ORDER (what we expect):
// ┌────────────────────────────────────────────────────────┐
// │ 1. Allocate memory (configData=null, initialized=false,│
// │    connectionPool=null)                                │
// │ 2. Execute constructor body:                           │
// │    2a. configData = new Map()                          │
// │    2b. configData.set("apiUrl", ...)                   │
// │    2c. connectionPool = new ConnectionPool(10)         │
// │    2d. initialized = true                              │
// │ 3. Assign completed object address to 'instance'       │
// └────────────────────────────────────────────────────────┘
//
// POSSIBLE REORDERED EXECUTION (the bug):
// ┌────────────────────────────────────────────────────────┐
// │ 1. Allocate memory (configData=null, initialized=false,│
// │    connectionPool=null)                                │
// │ 2. Assign memory address to 'instance' ← EARLY!        │
// │    (instance now points to UNINITIALIZED object)       │
// │ 3. Execute constructor body:                           │
// │    3a. configData = new Map()                          │
// │    3b. configData.set("apiUrl", ...)                   │
// │    3c. connectionPool = new ConnectionPool(10)         │
// │    3d. initialized = true                              │
// └────────────────────────────────────────────────────────┘
//
// Between steps 2 and 3d, any thread checking "instance != null"
// sees TRUE, but the object fields are still null/false!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// Thread A is in the middle of construction...
// (has allocated memory and assigned to 'instance', but
//  constructor body hasn't executed yet)
 
// Thread B comes along:
function threadB_execution() {
    const config = ConfigService.getInstance(); 
    // ^ First check: instance != null → TRUE (sees the address)
    // ^ Returns immediately without acquiring lock
    
    // Thread B now has a reference to a partially constructed object
    // where:
    //   - configData = null
    //   - connectionPool = null  
    //   - initialized = false
    
    const url = config.getApiUrl();
    // ^ Throws "Not initialized!" or, worse...
    
    // If the check wasn't there:
    const url2 = config.configData.get("apiUrl");
    // ^ NullPointerException: configData is null!
    
    // If configData was set but connectionPool wasn't:
    const pool = config.connectionPool;
    pool.getConnection(); // NullPointerException!
}
 
// Key insight: The object EXISTS (has a memory address) but its
// FIELDS aren't initialized. The reference is valid; the object
// state is not.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

/**
 * This code appeared in countless Java books and articles
 * between 1995-2004. It is BROKEN.
 * 
 * From "Design Patterns: Elements of Reusable Object-Oriented
 * Software" (1994) - adapted to Java
 */
public class Singleton {
    private static Singleton instance = null;
    
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();  // BROKEN!
                }
            }
        }
        return instance;
    }
}
 
// Why it's broken:
// 1. 'instance' is not volatile
// 2. The JVM is free to reorder the constructor operations
// 3. Thread B can see a non-null 'instance' that points
//    to an incompletely constructed object
//
// This bug affected production systems at:
// - Sun Microsystems (ironic, given they created Java)
// - IBM WebSphere
// - Numerous open-source projects
// - Enterprise applications worldwide