79:T520,**Lazy initialization** is a design pattern where the creation of an object is deferred until it is first needed. This contrasts with **eager initialization**, where the object is created immediately at program startup or class loading. The motivation for lazy initialization typically falls into one of these categories: **1. Performance Optimization** Some resources are expensive to create—establishing database connections, loading configuration files from disk, parsing large XML documents, or initializing complex subsystems. If these resources might not be used in every program execution path, creating them eagerly wastes time and memory. **2. Resource Conservation** Objects that consume significant memory (large caches, image buffers, machine learning models) should only be instantiated when genuinely needed. A program that initializes ten optional modules eagerly consumes resources for all ten, even if only two are used. **3. Dependency Resolution** Some objects depend on runtime information unavailable at startup. A configuration-dependent service might need to wait until configuration is loaded before initialization. **4. Avoiding Circular Dependencies** Lazy initialization can break circular dependency chains by deferring creation until the dependency graph is fully established.7a:T602,/** * Single-Threaded Lazy Initialization * Works perfectly in single-threaded contexts */ class ExpensiveResource { private static instance: ExpensiveResource | null = null; // Private constructor prevents direct instantiation private constructor() { // Simulate expensive initialization console.log("Creating expensive resource..."); this.loadConfigFromDisk(); this.establishDatabaseConnections(); this.warmUpCaches(); } private loadConfigFromDisk(): void { // Simulate 500ms disk I/O } private establishDatabaseConnections(): void { // Simulate 1000ms connection setup } private warmUpCaches(): void { // Simulate 2000ms cache population } /** * Lazy getter - creates instance on first call * In single-threaded code, this is completely safe */ public static getInstance(): ExpensiveResource { if (ExpensiveResource.instance === null) { // First call: create the instance ExpensiveResource.instance = new ExpensiveResource(); } // Subsequent calls: return cached instance return ExpensiveResource.instance; } public doWork(): void { console.log("Performing work with expensive resource"); } } // Usage const resource = ExpensiveResource.getInstance(); // First call: initializes const sameResource = ExpensiveResource.getInstance(); // Returns cached console.log(resource === sameResource); // true7b:T6a4,/** * Single-Threaded Lazy Initialization * Works perfectly in single-threaded contexts */ public class ExpensiveResource { private static ExpensiveResource instance = null; // Private constructor prevents direct instantiation private ExpensiveResource() { // Simulate expensive initialization System.out.println("Creating expensive resource..."); loadConfigFromDisk(); establishDatabaseConnections(); warmUpCaches(); } private void loadConfigFromDisk() { // Simulate 500ms disk I/O try { Thread.sleep(500); } catch (InterruptedException e) {} } private void establishDatabaseConnections() { // Simulate 1000ms connection setup try { Thread.sleep(1000); } catch (InterruptedException e) {} } private void warmUpCaches() { // Simulate 2000ms cache population try { Thread.sleep(2000); } catch (InterruptedException e) {} } /** * Lazy getter - creates instance on first call * In single-threaded code, this is completely safe */ public static ExpensiveResource getInstance() { if (instance == null) { // First call: create the instance instance = new ExpensiveResource(); } // Subsequent calls: return cached instance return instance; } public void doWork() { System.out.println("Performing work with expensive resource"); } } // Usage ExpensiveResource resource = ExpensiveResource.getInstance(); // First call ExpensiveResource sameResource = ExpensiveResource.getInstance(); // Cached System.out.println(resource == sameResource); // true7c:T70d,""" Single-Threaded Lazy Initialization Works perfectly in single-threaded contexts """ import time class ExpensiveResource: _instance = None def __new__(cls): """Override __new__ to implement singleton""" if cls._instance is None: print("Creating expensive resource...") cls._instance = super().__new__(cls) cls._instance._initialize() return cls._instance def _initialize(self): """Simulate expensive initialization""" self._load_config_from_disk() self._establish_database_connections() self._warm_up_caches() def _load_config_from_disk(self): # Simulate 500ms disk I/O time.sleep(0.5) def _establish_database_connections(self): # Simulate 1000ms connection setup time.sleep(1.0) def _warm_up_caches(self): # Simulate 2000ms cache population time.sleep(2.0) def do_work(self): print("Performing work with expensive resource") # Alternative approach using class method class ExpensiveResourceV2: _instance = None @classmethod def get_instance(cls) -> 'ExpensiveResourceV2': """ Lazy getter - creates instance on first call In single-threaded code, this is completely safe """ if cls._instance is None: # First call: create the instance cls._instance = cls() # Subsequent calls: return cached instance return cls._instance def do_work(self): print("Performing work with expensive resource") # Usage resource = ExpensiveResourceV2.get_instance() # First call: initializes same_resource = ExpensiveResourceV2.get_instance() # Returns cached print(resource is same_resource) # True7d:T464,**The consequences of this race condition are severe:** **1. Multiple Instance Creation** The resource is created twice (or more), wasting the expensive initialization cost we sought to avoid. If initialization takes 3 seconds, we're now spending 6 seconds (or more) on parallel, redundant creations. **2. Singleton Guarantee Violated** If we intended to create a singleton (exactly one instance), we've failed. Different threads may hold references to different instances, leading to subtle inconsistencies. **3. State Corruption** If the "singleton" maintains mutable state, different threads operating on different instances will have divergent state. Changes made through Instance #1 won't be visible to code using Instance #2. **4. Resource Leaks** If the resource allocates external resources (database connections, file handles, network sockets), each redundant instance allocates its own, leading to resource exhaustion. **5. Initialization Side Effects** If initialization has side effects (registering with a global service, writing to a log, incrementing a counter), these execute multiple times incorrectly.7e:Ta6d,/** * DANGEROUS: Race condition in lazy initialization * This code is broken when called from multiple threads */ class DatabaseConnectionPool { private static instance: DatabaseConnectionPool | null = null; private static creationCount = 0; private connections: Connection[] = []; private instanceId: number; private constructor() { DatabaseConnectionPool.creationCount++; this.instanceId = DatabaseConnectionPool.creationCount; console.log(`Creating connection pool #${this.instanceId}...`); // Expensive: create 10 database connections for (let i = 0; i < 10; i++) { this.connections.push(this.createConnection()); } console.log(`Pool #${this.instanceId} ready with ${this.connections.length} connections`); } private createConnection(): Connection { // Simulate connection establishment (1 second each) return new Connection(); } /** * BROKEN: Race condition between check and assignment * * Problem: The gap between "if (instance === null)" and * "instance = new DatabaseConnectionPool()" allows multiple * threads to pass the check simultaneously */ public static getInstance(): DatabaseConnectionPool { // DANGER ZONE: This check-then-act is NOT atomic if (DatabaseConnectionPool.instance === null) { // Multiple threads can reach here simultaneously! DatabaseConnectionPool.instance = new DatabaseConnectionPool(); } return DatabaseConnectionPool.instance; } public getConnection(): Connection { return this.connections[Math.floor(Math.random() * this.connections.length)]; } public getInstanceId(): number { return this.instanceId; } } // Simulated concurrent access (pseudocode - actual threading varies by runtime) async function demonstrateRaceCondition() { const promises = []; // Launch 10 "threads" simultaneously for (let i = 0; i < 10; i++) { promises.push( (async () => { const pool = DatabaseConnectionPool.getInstance(); console.log(`Thread ${i} got pool #${pool.getInstanceId()}`); return pool; })() ); } const pools = await Promise.all(promises); // Check: are all pools the same instance? const uniquePools = new Set(pools.map(p => p.getInstanceId())); console.log(`Unique pools created: ${uniquePools.size}`); // EXPECTED (if safe): 1 // ACTUAL (with race condition): could be 2, 3, or more! }7f:Tba2,/** * DANGEROUS: Race condition in lazy initialization * This code is broken when called from multiple threads */ public class DatabaseConnectionPool { private static DatabaseConnectionPool instance = null; private static AtomicInteger creationCount = new AtomicInteger(0); private List connections = new ArrayList<>(); private int instanceId; private DatabaseConnectionPool() { this.instanceId = creationCount.incrementAndGet(); System.out.println("Creating connection pool #" + instanceId + "..."); // Expensive: create 10 database connections for (int i = 0; i < 10; i++) { connections.add(createConnection()); } System.out.println("Pool #" + instanceId + " ready with " + connections.size() + " connections"); } private Connection createConnection() { // Simulate connection establishment (1 second each) try { Thread.sleep(1000); } catch (InterruptedException e) {} return new Connection(); } /** * BROKEN: Race condition between check and assignment * * Problem: The gap between "if (instance == null)" and * "instance = new DatabaseConnectionPool()" allows multiple * threads to pass the check simultaneously */ public static DatabaseConnectionPool getInstance() { // DANGER ZONE: This check-then-act is NOT atomic if (instance == null) { // Multiple threads can reach here simultaneously! instance = new DatabaseConnectionPool(); } return instance; } public Connection getConnection() { return connections.get(ThreadLocalRandom.current().nextInt(connections.size())); } public int getInstanceId() { return instanceId; } // Demonstration of race condition public static void main(String[] args) throws InterruptedException { List threads = new ArrayList<>(); Set observedIds = ConcurrentHashMap.newKeySet(); // Launch 10 threads simultaneously for (int i = 0; i < 10; i++) { final int threadId = i; Thread t = new Thread(() -> { DatabaseConnectionPool pool = DatabaseConnectionPool.getInstance(); System.out.println("Thread " + threadId + " got pool #" + pool.getInstanceId()); observedIds.add(pool.getInstanceId()); }); threads.add(t); } // Start all threads at once for (Thread t : threads) { t.start(); } // Wait for completion for (Thread t : threads) { t.join(); } System.out.println("Unique pools created: " + observedIds.size()); // EXPECTED (if safe): 1 // ACTUAL (with race condition): could be 2, 3, or more! } }80:Ta57,""" DANGEROUS: Race condition in lazy initialization This code is broken when called from multiple threads """ import threading import time import random class DatabaseConnectionPool: _instance = None _creation_count = 0 def __init__(self): DatabaseConnectionPool._creation_count += 1 self.instance_id = DatabaseConnectionPool._creation_count print(f"Creating connection pool #{self.instance_id}...") # Expensive: create 10 database connections self.connections = [] for i in range(10): self.connections.append(self._create_connection()) print(f"Pool #{self.instance_id} ready with {len(self.connections)} connections") def _create_connection(self): # Simulate connection establishment (1 second each) time.sleep(1) return object() # Placeholder for connection @classmethod def get_instance(cls) -> 'DatabaseConnectionPool': """ BROKEN: Race condition between check and assignment Problem: The gap between "if _instance is None" and "_instance = DatabaseConnectionPool()" allows multiple threads to pass the check simultaneously """ # DANGER ZONE: This check-then-act is NOT atomic if cls._instance is None: # Multiple threads can reach here simultaneously! cls._instance = cls() return cls._instance def get_connection(self): return random.choice(self.connections) def get_instance_id(self) -> int: return self.instance_id def demonstrate_race_condition(): """Demonstration of race condition""" threads = [] observed_ids = set() lock = threading.Lock() def get_pool(thread_id: int): pool = DatabaseConnectionPool.get_instance() print(f"Thread {thread_id} got pool #{pool.get_instance_id()}") with lock: observed_ids.add(pool.get_instance_id()) # Reset for demonstration DatabaseConnectionPool._instance = None DatabaseConnectionPool._creation_count = 0 # Launch 10 threads simultaneously for i in range(10): t = threading.Thread(target=get_pool, args=(i,)) threads.append(t) # Start all threads at once for t in threads: t.start() # Wait for completion for t in threads: t.join() print(f"Unique pools created: {len(observed_ids)}") # EXPECTED (if safe): 1 # ACTUAL (with race condition): could be 2, 3, or more! if __name__ == "__main__": demonstrate_race_condition()81:T88f,/** * Thread-safe but inefficient lazy initialization * Correct, but pays synchronization cost on every access */ class ConfigurationService { private static instance: ConfigurationService | null = null; private static mutex = new Mutex(); // Hypothetical mutex private config: Map; private constructor() { console.log("Loading configuration from remote service..."); // Simulate expensive network call this.config = this.fetchConfigFromRemote(); } private fetchConfigFromRemote(): Map { // Simulate 2-second network delay return new Map([ ["database.url", "postgres://localhost:5432/app"], ["cache.size", "1000"], ["log.level", "DEBUG"], ]); } /** * CORRECT but SLOW: Synchronize the entire method * * Every call to getInstance() must acquire the lock, even when * the instance has already been created. This is wasteful. */ public static async getInstance(): Promise { // PERFORMANCE PROBLEM: Lock acquired on EVERY call await ConfigurationService.mutex.acquire(); try { if (ConfigurationService.instance === null) { ConfigurationService.instance = new ConfigurationService(); } return ConfigurationService.instance; } finally { ConfigurationService.mutex.release(); } } public get(key: string): string | undefined { return this.config.get(key); } } /** * Performance Analysis: * * First call: * - Acquire lock: ~1μs * - Check null: ~1ns * - Create instance: ~2000ms * - Release lock: ~1μs * - Total: ~2000ms (acceptable) * * Subsequent calls (the problem): * - Acquire lock: ~1μs * - Check null: ~1ns * - Return instance: ~1ns * - Release lock: ~1μs * - Total: ~2μs (should be ~1ns!) * * In a hot path called 1 million times/second: * - With lock: 1,000,000 × 2μs = 2 seconds of lock contention * - Without lock: 1,000,000 × 1ns = 1 millisecond * * That's a 2000x slowdown! */82:T7e0,/** * Thread-safe but inefficient lazy initialization * Correct, but pays synchronization cost on every access */ public class ConfigurationService { private static ConfigurationService instance = null; private Map config; private ConfigurationService() { System.out.println("Loading configuration from remote service..."); // Simulate expensive network call this.config = fetchConfigFromRemote(); } private Map fetchConfigFromRemote() { // Simulate 2-second network delay try { Thread.sleep(2000); } catch (InterruptedException e) {} Map config = new HashMap<>(); config.put("database.url", "postgres://localhost:5432/app"); config.put("cache.size", "1000"); config.put("log.level", "DEBUG"); return config; } /** * CORRECT but SLOW: Synchronize the entire method * * Every call to getInstance() must acquire the lock, even when * the instance has already been created. This is wasteful. */ public static synchronized ConfigurationService getInstance() { // PERFORMANCE PROBLEM: Lock acquired on EVERY call if (instance == null) { instance = new ConfigurationService(); } return instance; } public String get(String key) { return config.get(key); } } /** * Performance Analysis: * * First call: * - Acquire lock: ~1μs * - Check null: ~1ns * - Create instance: ~2000ms * - Release lock: ~1μs * - Total: ~2000ms (acceptable) * * Subsequent calls (the problem): * - Acquire lock: ~1μs * - Check null: ~1ns * - Return instance: ~1ns * - Release lock: ~1μs * - Total: ~2μs (should be ~1ns!) * * In a hot path called 1 million times/second: * - With lock: 1,000,000 × 2μs = 2 seconds of lock contention * - Without lock: 1,000,000 × 1ns = 1 millisecond * * That's a 2000x slowdown! */83:T6f6,""" Thread-safe but inefficient lazy initialization Correct, but pays synchronization cost on every access """ import threading import time class ConfigurationService: _instance = None _lock = threading.Lock() def __init__(self): print("Loading configuration from remote service...") # Simulate expensive network call self.config = self._fetch_config_from_remote() def _fetch_config_from_remote(self) -> dict: # Simulate 2-second network delay time.sleep(2) return { "database.url": "postgres://localhost:5432/app", "cache.size": "1000", "log.level": "DEBUG", } @classmethod def get_instance(cls) -> 'ConfigurationService': """ CORRECT but SLOW: Synchronize the entire method Every call to get_instance() must acquire the lock, even when the instance has already been created. This is wasteful. """ # PERFORMANCE PROBLEM: Lock acquired on EVERY call with cls._lock: if cls._instance is None: cls._instance = cls() return cls._instance def get(self, key: str) -> str | None: return self.config.get(key) """ Performance Analysis: First call: - Acquire lock: ~1μs - Check null: ~1ns - Create instance: ~2000ms - Release lock: ~1μs - Total: ~2000ms (acceptable) Subsequent calls (the problem): - Acquire lock: ~1μs - Check null: ~1ns - Return instance: ~1ns - Release lock: ~1μs - Total: ~2μs (should be ~1ns!) In a hot path called 1 million times/second: - With lock: 1,000,000 × 2μs = 2 seconds of lock contention - Without lock: 1,000,000 × 1ns = 1 millisecond That's a 2000x slowdown! """71:{"json":{"id":"seed_ff34c8be9eddd962a414fc556a0cf78e","slug":"double-checked-locking","category":"System Design (LLD)","topic":"Concurrency Patterns","title":"Double-Checked Locking Pattern","description":"Master the Double-Checked Locking pattern for efficient lazy initialization in concurrent environments. Learn the subtle pitfalls, memory model considerations, and safe implementation strategies that distinguish robust concurrent code from unsafe implementations.","difficulty":"ADVANCED","estimatedMinutes":55,"pages":[{"id":"seed_3a517144641bc3bf6d28848a32c7c7b6","title":"Problem: Lazy Initialization in Concurrent Context","order":0,"content":[{"id":"opening-context","title":"The Initialization Dilemma","content":[{"data":{"content":"In concurrent programming, few design challenges are as deceptively simple yet profoundly treacherous as **lazy initialization**. The concept appears straightforward: delay the creation of an expensive resource until first use, then cache it for subsequent requests. In single-threaded code, this is trivial. In multi-threaded code, it becomes a minefield of subtle bugs that can elude detection for months or years.\n\nThe Double-Checked Locking pattern emerged as a seemingly elegant solution to this problem—a way to achieve thread-safe lazy initialization with minimal synchronization overhead. Yet this pattern became infamous for its broken implementations, leading luminaries like Brian Goetz to label certain versions as \"fundamentally and irreparably broken\" in some programming languages.\n\nUnderstanding why lazy initialization is problematic in concurrent contexts—and why early solutions failed—is essential before we can appreciate the safe implementation strategies that exist today."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand why lazy initialization creates race conditions in concurrent environments, why naive locking solutions are insufficient, and what performance concerns drive engineers toward optimized patterns like Double-Checked Locking.","variant":"info"},"type":"callout"}]},{"id":"understanding-lazy-init","title":"Understanding Lazy Initialization","content":[{"data":{"content":"$79"},"type":"text"},{"data":{"fileName":"lazy-initialization-basic.ts","languages":[{"code":"$7a","label":"TypeScript","value":"typescript"},{"code":"$7b","label":"Java","value":"java"},{"code":"$7c","label":"Python","value":"python"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Info","title":"The Single-Threaded Simplicity","content":"In single-threaded code, the lazy initialization pattern shown above is completely correct. The null check and assignment happen sequentially with no possibility of interference. The complexity emerges only when multiple threads may execute this code simultaneously.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"multi-threaded-problem","title":"The Multi-Threaded Problem","content":[{"data":{"content":"When multiple threads execute the lazy initialization code concurrently, a **race condition** emerges. The \"check-then-act\" sequence that works perfectly in single-threaded code becomes fundamentally broken.\n\nConsider what happens when two threads—let's call them Thread A and Thread B—simultaneously call `getInstance()` when the instance hasn't been created yet:"},"type":"text"},{"data":{"rows":[["T1","Checks: instance == null? → true","(not yet executed)","null"],["T2","(context switch)","Checks: instance == null? → true","null"],["T3","(waiting)","Creates new ExpensiveResource()","null → initializing"],["T4","(waiting)","Assigns to instance","Instance #1"],["T5","Creates new ExpensiveResource()","(finished)","Instance #1 → initializing"],["T6","Assigns to instance","(finished)","Instance #2 (overwrites #1!)"],["T7","Returns Instance #2","Returns Instance #1","Instance #2"]],"caption":"Race Condition Timeline in Lazy Initialization","headers":["Time","Thread A","Thread B","instance State"]},"type":"table"},{"data":{"content":"$7d"},"type":"text"},{"data":{"fileName":"race-condition-demonstration.ts","languages":[{"code":"$7e","label":"TypeScript","value":"typescript"},{"code":"$7f","label":"Java","value":"java"},{"code":"$80","label":"Python","value":"python"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"The Check-Then-Act Anti-Pattern","content":"The pattern of checking a condition and then acting on it is fundamentally unsafe in concurrent code unless the entire sequence is atomic. Between the check and the act, another thread can change the condition, invalidating the decision.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"why-not-eager-init","title":"Why Not Just Eager Initialize?","content":[{"data":{"content":"A natural question emerges: if lazy initialization creates race conditions, why not simply initialize eagerly? Create the resource at class loading time, and there's no race condition at all.\n\nThis is often the correct answer. Eager initialization is simpler, safer, and should be preferred when possible. However, there are legitimate cases where it's impractical:"},"type":"text"},{"data":{"items":["**Runtime-Dependent Configuration** — The resource requires configuration that's only available after startup. A database connection pool can't be created until the database URL is loaded from a configuration service that itself must start first.","**Optional Features** — In a large application with dozens of optional subsystems, eagerly initializing all of them wastes significant startup time and memory. A reporting module used by 1% of users shouldn't delay startup for everyone.","**Costly Resources That Might Never Be Used** — A machine learning model that takes 30 seconds to load shouldn't be loaded at startup if there's a 50% chance the user's session never requires it.","**Breaking Circular Dependencies** — When class A depends on B and B depends on A, at least one must be lazily initialized to break the cycle.","**Testing Flexibility** — Lazy initialization allows tests to substitute mock implementations before the real resource is created. Eager initialization creates the resource before tests can intercept.","**Memory Constraints** — On memory-limited devices or in serverless environments billed by memory usage, delaying allocation until necessary can be essential."],"title":{"icon":"Target","text":"Legitimate Cases for Lazy Initialization","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"left":[{"data":{"items":["The resource is always (or almost always) used","Initialization is fast (< 100ms)","All dependencies are available at startup","Startup time is not a critical constraint","You want the simplest, safest code path"],"title":{"icon":"CheckCircle","text":"When to Use Eager Initialization","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["The resource is expensive to create (> 1 second)","The resource may not be used in most executions","Dependencies aren't available at class load time","Startup time is critical (< 100ms cold start)","Memory usage must be minimized until needed"],"title":{"icon":"AlertCircle","text":"When Lazy Initialization May Be Needed","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Lightbulb","title":"Default to Eager, Optimize to Lazy","content":"Eager initialization should be your default choice. Only move to lazy initialization when you have measured evidence that eager initialization creates a problem. Premature optimization—especially in concurrency—creates bugs.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"naive-synchronization","title":"The Naive Synchronization Solution","content":[{"data":{"content":"The obvious solution to the race condition is synchronization: ensure only one thread can execute the initialization code at a time. This is correct, but it introduces a significant performance problem."},"type":"text"},{"data":{"fileName":"naive-synchronized-init.ts","languages":[{"code":"$81","label":"TypeScript","value":"typescript"},{"code":"$82","label":"Java","value":"java"},{"code":"$83","label":"Python","value":"python"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**The performance problem is clear**: we need synchronization only during the first call (when the instance is created). Every subsequent call—potentially millions of them—pays the synchronization overhead even though the instance already exists and is immutable.\n\nThis is the fundamental tension that led to the invention of Double-Checked Locking:\n\n**The Goal**: Synchronize only when necessary (during creation), then bypass synchronization entirely for subsequent reads.\n\n**The Challenge**: Doing this correctly requires understanding subtle memory model semantics that aren't obvious from the code structure alone."},"type":"text"}],"titleType":"number","titleNumber":4},{"id":"performance-impact","title":"Performance Impact Analysis","content":[{"data":{"content":"To understand why engineers sought an optimization like Double-Checked Locking, we need to quantify the performance impact of different approaches."},"type":"text"},{"data":{"rows":[["Eager Initialization","Paid at startup","~1 nanosecond","None","✓ Safe"],["Unsynchronized Lazy","~N milliseconds","~1 nanosecond","Race condition!","✗ Broken"],["Synchronized Lazy","~N milliseconds + lock","~1-10 microseconds","High (serialized)","✓ Safe"],["Double-Checked Locking","~N milliseconds + lock","~1 nanosecond","Low (lock-free reads)","Depends on impl"]],"caption":"Performance Comparison of Initialization Strategies","headers":["Approach","First Access","Subsequent Access","Contention Under Load","Correctness"]},"type":"table"},{"data":{"content":"**Real-World Impact Numbers**\n\nConsider a service that accesses a configuration singleton 100,000 times per second (not unrealistic for a busy application server):"},"type":"text"},{"data":{"rows":[["Unsynchronized read","1 ns","100 μs","None (but broken!)"],["Synchronized read","2 μs","200 ms","600 million"],["DCL (properly implemented)","~2 ns","200 μs","~200 thousand"]],"headers":["Approach","Time per Access","Total Time/Second","CPU Cycles Wasted"]},"type":"table"},{"data":{"content":"The synchronized approach wastes **20% of a CPU core** just on lock acquisition. In high-throughput systems, this is the difference between needing 5 servers and needing 6.\n\n**Lock Contention Amplifies the Problem**\n\nThe microseconds-per-access figure assumes uncontended lock acquisition. Under contention (multiple threads trying to acquire the lock simultaneously), performance degrades dramatically:\n\n- 2 threads contending: 2-3x slowdown\n- 4 threads contending: 4-6x slowdown \n- 16 threads contending: 10-30x slowdown\n\nOn a 16-core server handling concurrent requests, naive synchronization can become a devastating bottleneck."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Optimization Trap","content":"These numbers might tempt you to always use Double-Checked Locking. Resist this temptation! Most applications don't access singletons 100,000 times per second. For most use cases, the simple synchronized approach is perfectly adequate and far safer.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"summary","title":"Summary: The Problem Space","content":[{"data":{"content":"We've established the problem that Double-Checked Locking attempts to solve:"},"type":"text"},{"data":{"type":"ordered","items":["**Lazy initialization defers expensive resource creation** until first use, saving startup time and memory for resources that may not be needed.","**In multi-threaded code, lazy initialization creates race conditions** — the check-then-act pattern allows multiple threads to create redundant instances.","**Naive synchronization solves correctness but destroys performance** — acquiring a lock on every access can be 1000x+ slower than unsynchronized reads.","**Eager initialization is often the best solution** — but not always applicable when dependencies are unavailable at startup or resources are expensive and rarely used.","**The performance gap between synchronized and unsynchronized access** motivates the search for patterns that synchronize only when necessary."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next**\n\nThe next page introduces the Double-Checked Locking pattern itself — the structure that attempts to synchronize only during initialization while allowing lock-free reads afterward. We'll see both why the pattern is attractive and why naive implementations are dangerously broken."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the problem space that motivates Double-Checked Locking: the tension between thread-safe lazy initialization and efficient subsequent access. Next, we'll explore the DCL pattern structure and why its correct implementation requires deep understanding of memory models.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":6}],"isLocked":false},{"id":"seed_d7b4d1af848273c62932cf55295a338f","title":"Solution: Double-Checked Locking Pattern","order":1,"content":null,"isLocked":true},{"id":"seed_2d7d6d96e4e6a7574b4dfa5a29d412c5","title":"Memory Model Considerations","order":2,"content":null,"isLocked":true},{"id":"seed_c7d2c56a2eff262e51461e7aaae52431","title":"Safe Implementation Strategies","order":3,"content":null,"isLocked":true}]}}