Improper Instantiation Anti-Pattern Explained

TL;DR

Improper instantiation occurs when applications repeatedly create expensive objects instead of reusing them, causing memory pressure, garbage collection storms, and CPU waste. The antipattern manifests in tight loops creating database connections, heavyweight objects instantiated per request, and missing object pooling. Fix it by implementing connection pools, singleton patterns for stateless services, and object reuse strategies—reducing GC overhead by 60-80% in typical production systems.

Cheat Sheet: Profile heap allocation rates → Identify hot paths creating expensive objects → Apply pooling (connections, threads), singleton (stateless services), or lazy initialization (heavyweight one-time setup) → Monitor GC pause times and allocation rates.

The Problem It Solves

Modern applications frequently create objects that are expensive to instantiate—database connections requiring TCP handshakes and authentication, HTTP clients with SSL context initialization, XML parsers loading schemas, or domain objects with complex validation logic. When developers treat these like lightweight primitives and instantiate them repeatedly (in request handlers, tight loops, or per-transaction code paths), the application burns CPU cycles on construction overhead and floods the heap with short-lived objects. This triggers frequent garbage collection pauses that can exceed 100ms in JVM applications or cause memory fragmentation in .NET, directly impacting user-facing latency. At Stripe, engineers discovered that instantiating a new Kafka producer per payment event (instead of reusing a singleton) caused 200ms P99 latency spikes during traffic bursts—the producer’s metadata fetch and connection establishment dominated request time. The real pain isn’t just the CPU cost of object construction; it’s the cascading effect on garbage collection. When you create 10,000 database connection objects per second (each allocating buffers, socket handles, and internal state), you’re not just wasting cycles—you’re forcing the GC to scan and reclaim massive object graphs every few seconds, causing stop-the-world pauses that make your P99 latency unpredictable. This antipattern is insidious because it doesn’t fail loudly; it degrades gracefully until you hit a traffic threshold where GC overhead crosses 30% of CPU time and your system falls off a performance cliff.

Improper Instantiation: Object Creation in Loop vs Reuse

graph TB
    subgraph Antipattern: Creating Objects in Loop
        Request1["Request 1"] --> Create1["new DBConnection()"]
        Request2["Request 2"] --> Create2["new DBConnection()"]
        Request3["Request 3"] --> Create3["new DBConnection()"]
        Create1 --> Overhead1["50ms TCP + Auth<br/>64KB buffers"]
        Create2 --> Overhead2["50ms TCP + Auth<br/>64KB buffers"]
        Create3 --> Overhead3["50ms TCP + Auth<br/>64KB buffers"]
        Overhead1 & Overhead2 & Overhead3 --> Heap["Heap Pressure<br/>6.4MB/sec allocation"]
        Heap --> GC["Frequent GC Pauses<br/>100-200ms stop-the-world"]
    end
    
    subgraph Solution: Object Pool Reuse
        Pool["Connection Pool<br/>(20 pre-warmed connections)"]
        Req1["Request 1"] --"1. Checkout"--> Pool
        Pool --"2. Return existing connection<br/><1ms"--> Req1
        Req2["Request 2"] --"1. Checkout"--> Pool
        Pool --"2. Return existing connection<br/><1ms"--> Req2
        Req3["Request 3"] --"1. Checkout"--> Pool
        Pool --"2. Return existing connection<br/><1ms"--> Req3
        Pool --> Startup["One-time cost at startup<br/>1 second total"]
        Pool --> NoGC["Minimal GC pressure<br/>~0 allocation/sec"]
    end

Creating database connections per request causes 50ms overhead and 6.4MB/sec heap allocation (100 req/sec), triggering frequent GC pauses. Connection pooling eliminates construction overhead and reduces allocation to near-zero, paying the cost once at startup.

Solution Overview

The solution is strategic object lifecycle management: identify expensive-to-create objects and apply reuse patterns that match their characteristics. For stateless, thread-safe objects (HTTP clients, serializers, connection factories), use the singleton pattern to create once and share globally. For stateful resources that can’t be shared concurrently (database connections, file handles), implement object pooling where a fixed set of pre-initialized instances are checked out, used, and returned. For objects with expensive one-time setup but infrequent use, apply lazy initialization to defer construction until first access. The key insight is that object creation cost has two components: construction time (CPU) and memory pressure (GC impact). A database connection might take 50ms to establish (network + auth) and allocate 64KB of buffers—creating 100 per second means 5 seconds of CPU time and 6.4MB/sec of allocation pressure. By maintaining a pool of 20 pre-warmed connections, you pay the construction cost once at startup and eliminate ongoing allocation churn. Connection pooling libraries like HikariCP (Java) or Npgsql (C#) handle the complexity of pool sizing, health checks, and timeout management. For heavyweight stateless objects, a simple singleton with thread-safe lazy initialization (double-checked locking or static initialization) eliminates redundant construction. The pattern shifts cost from the hot path (per-request) to initialization time (startup or first use), trading a small upfront delay for consistent runtime performance.

Connection Pool Architecture with Lifecycle Management

graph LR
    subgraph Application Threads
        T1["Thread 1"]
        T2["Thread 2"]
        T3["Thread 3"]
        T4["Thread 4"]
    end
    
    subgraph Connection Pool Manager
        Available["Available Queue<br/>(Idle connections)"]
        Active["Active Set<br/>(In-use connections)"]
        Config["Pool Config<br/>min=10, max=100<br/>timeout=30s"]
    end
    
    subgraph Database
        DB1[("DB Connection 1")]
        DB2[("DB Connection 2")]
        DB3[("DB Connection 3")]
    end
    
    T1 --"1. Request connection"--> Available
    Available --"2. Checkout (move to Active)"--> Active
    Active --"3. Return connection"--> T1
    T1 --"4. Execute query"--> DB1
    T1 --"5. Return to pool"--> Active
    Active --"6. Validate (SELECT 1)"--> DB1
    Active --"7. Move to Available"--> Available
    
    T4 --"Request when pool full"--> Available
    Available -."Wait or timeout".-> T4
    
    Config --"Health check every 30s"--> Available
    Config --"Evict idle >5min"--> Available
    Config --"Max lifetime 30min"--> Active

Connection pool maintains separate queues for available and active connections. Threads checkout from available queue, use the connection, then return it after validation. Pool enforces min/max limits, health checks, and idle timeouts to manage lifecycle.

How It Works

Step 1: Profile allocation hotspots. Use heap profilers (JProfiler, dotMemory, or allocation profilers in production APM tools) to identify allocation rate by class. Look for objects created at rates exceeding 1000/sec or classes consuming >10% of allocation bandwidth. At Netflix, engineers use Flame Graphs filtered by allocation to spot constructors dominating heap churn—a single new HttpClient() in a request handler can show up as a massive tower in the graph.

Step 2: Classify object characteristics. For each expensive type, determine: (a) Is it thread-safe? (b) Does it hold mutable state? (c) What’s the construction cost (time + memory)? Thread-safe stateless objects (JSON serializers, regex patterns) are singleton candidates. Stateful but reusable objects (DB connections, byte buffers) need pooling. Objects with expensive setup but rare use (ML models, cryptographic contexts) need lazy initialization.

Step 3: Implement appropriate reuse pattern. For connection pooling, configure min/max pool size based on concurrency needs. A web service handling 1000 req/sec with 50ms DB query time needs ~50 concurrent connections (Little’s Law: L = λW). Set min pool size to handle baseline load (e.g., 20) and max to handle bursts (e.g., 100), with idle timeout to release excess connections. HikariCP’s default configuration (minimumIdle=10, maximumPoolSize=10) is often too conservative for production. For singletons, use thread-safe initialization: in Java, leverage static initialization or enum singletons; in C#, use Lazy<T> or static constructors. Avoid double-checked locking unless you understand memory model guarantees. For object pools, libraries like Apache Commons Pool provide generic pooling with validation, eviction policies, and metrics.

Step 4: Add lifecycle management. Pooled objects need health checks (is this connection still valid?) and cleanup (close resources on shutdown). Implement IDisposable (C#) or AutoCloseable (Java) to ensure proper resource release. Connection pools should validate connections before checkout (SELECT 1) and handle stale connections gracefully. Set appropriate timeouts: connection timeout (how long to wait for a pooled object), idle timeout (when to evict unused objects), and max lifetime (force refresh to avoid stale state).

Step 5: Monitor effectiveness. Track metrics: pool utilization (active/total connections), wait time (threads blocked waiting for pooled objects), allocation rate (objects/sec), and GC pause time. A healthy pool shows 60-80% utilization during peak load with <1ms wait time. If wait time spikes, increase max pool size. If utilization stays below 30%, reduce min pool size to free resources. GC pause time should drop by 50-70% after implementing pooling—if it doesn’t, you haven’t addressed the primary allocation hotspot.

Little’s Law: Sizing Connection Pool Based on Concurrency

graph TB
    subgraph Input Metrics
        Rate["Request Rate (λ)<br/>1000 req/sec"]
        Latency["Query Time (W)<br/>50ms average"]
    end
    
    subgraph Little's Law Calculation
        Formula["L = λ × W<br/>Concurrent Connections = 1000 × 0.05<br/>= 50 connections needed"]
    end
    
    subgraph Pool Configuration
        Min["minimumIdle = 20<br/>(baseline load)"]
        Max["maximumPoolSize = 100<br/>(burst capacity)"]
        Buffer["20% buffer above calculated<br/>50 × 1.2 = 60 typical"]
    end
    
    subgraph Monitoring Thresholds
        Healthy["✓ Healthy Pool<br/>60-80% utilization<br/><1ms wait time"]
        Contention["⚠ Contention<br/>>90% utilization<br/>>10ms wait time<br/>→ Increase max"]
        Underutilized["⚠ Underutilized<br/><30% utilization<br/>→ Reduce min"]
    end
    
    Rate & Latency --> Formula
    Formula --> Buffer
    Buffer --> Min
    Buffer --> Max
    Min & Max --> Healthy
    Max -."If exceeded".-> Contention
    Min -."If rarely used".-> Underutilized

Use Little’s Law (L = λW) to calculate required concurrent connections: 1000 req/sec × 50ms = 50 connections. Set min pool size for baseline (20), max for bursts (100), and monitor utilization to tune—healthy pools show 60-80% utilization with <1ms wait time.

Variants

Connection Pooling (HikariCP, c3p0): Pre-initialized pools of database connections with configurable size, timeout, and validation. Use when: You have stateful resources (DB connections, message queue sessions) that are expensive to create but can be reused across requests. Pros: Eliminates connection establishment overhead (50-200ms per connection), provides backpressure via pool exhaustion. Cons: Requires tuning (too small = contention, too large = resource waste), adds complexity for connection lifecycle management. Netflix uses HikariCP with dynamic pool sizing based on request rate—during traffic spikes, the pool expands to maxPoolSize, then contracts during idle periods.

Singleton Pattern (Lazy/Eager): Single instance of a class shared globally, initialized once. Use when: Object is thread-safe, stateless, and expensive to construct (HTTP clients, serializers, configuration). Pros: Zero allocation overhead after initialization, simple to implement. Cons: Can hide dependencies (global state), makes testing harder (shared mutable state), requires thread-safety guarantees. Stripe’s payment processing service uses singleton HTTP clients for external API calls—each client maintains a connection pool internally, so creating one per request would create nested pools and exhaust file descriptors.

Object Pooling (Apache Commons Pool, Microsoft.Extensions.ObjectPool): Generic pool for any expensive-to-create objects with checkout/return semantics. Use when: Objects are stateful but resettable (byte buffers, protocol encoders, worker threads). Pros: Flexible, works for any object type, provides metrics and monitoring. Cons: More complex than singletons, requires careful state reset between uses, can leak resources if objects aren’t returned. Uber’s trip matching service pools geospatial index objects—each index loads city map data (200MB) and takes 5 seconds to initialize, so pooling 10 instances eliminates repeated loading.

Flyweight Pattern: Share intrinsic state across many objects, store extrinsic state externally. Use when: You have thousands of similar objects differing only in a few fields (game entities, UI widgets). Pros: Massive memory savings (90%+ reduction), reduces GC pressure. Cons: Adds indirection, complicates object identity, requires careful separation of shared vs unique state. Twitter’s timeline service uses flyweight for tweet objects—common fields (user avatar URLs, timestamp formats) are shared, while unique fields (tweet ID, text) are stored per instance.

Object Reuse Patterns: Decision Tree

flowchart TB
    Start["Expensive Object to Create"] --> ThreadSafe{"Is it<br/>thread-safe?"}
    
    ThreadSafe -->|Yes| Stateless{"Is it<br/>stateless?"}
    ThreadSafe -->|No| Stateful["Stateful Object"]
    
    Stateless -->|Yes| Singleton["✓ Singleton Pattern<br/><br/>Examples:<br/>• HTTP clients<br/>• JSON serializers<br/>• Regex patterns<br/><br/>Init: Once at startup<br/>Memory: Single instance"]
    
    Stateless -->|No| Resettable{"Can state be<br/>reset between<br/>uses?"}
    
    Resettable -->|Yes| ObjectPool["✓ Object Pool<br/><br/>Examples:<br/>• Byte buffers<br/>• Protocol encoders<br/>• Worker threads<br/><br/>Init: Pre-allocate N instances<br/>Memory: N × object size"]
    
    Resettable -->|No| PerUse["✗ Create per use<br/>(no safe reuse)"]
    
    Stateful --> Reusable{"Can it be<br/>reused across<br/>requests?"}
    
    Reusable -->|Yes| ConnPool["✓ Connection Pool<br/><br/>Examples:<br/>• DB connections<br/>• Message queue sessions<br/>• File handles<br/><br/>Init: min pool size at startup<br/>Memory: Dynamic (min-max)"]
    
    Reusable -->|No| Frequency{"Used<br/>frequently?"}
    
    Frequency -->|No| Lazy["✓ Lazy Initialization<br/><br/>Examples:<br/>• ML models<br/>• Large config files<br/>• Admin tools<br/><br/>Init: On first access<br/>Memory: Deferred until needed"]
    
    Frequency -->|Yes| Eager["✓ Eager Initialization<br/><br/>Examples:<br/>• Critical path objects<br/>• Startup dependencies<br/><br/>Init: At application startup<br/>Memory: Immediate allocation"]

Decision tree for selecting the appropriate object reuse pattern based on thread-safety, state mutability, and usage frequency. Thread-safe stateless objects use singleton, stateful reusable resources use connection pooling, and resettable objects use generic object pools.

Trade-offs

Dimension: Memory vs Latency. Creating objects on-demand (Option A) uses minimal memory but incurs construction latency on every use. Pre-allocating pools (Option B) consumes memory upfront but eliminates per-request latency. Decision: If construction time >10ms or allocation rate >1000/sec, pool. If memory is constrained (<1GB heap) and construction is fast (<1ms), create on-demand.

Dimension: Simplicity vs Performance. Naive instantiation (Option A) is simple—just new Object() everywhere—but suffers performance degradation under load. Pooling/singleton patterns (Option B) add complexity (lifecycle management, thread-safety, configuration) but deliver predictable performance. Decision: Start simple, add pooling when profiling shows >20% CPU in object construction or GC pauses exceed SLA.

Dimension: Static vs Dynamic Sizing. Fixed-size pools (Option A) are predictable and prevent resource exhaustion but can cause contention during bursts. Dynamic pools (Option B) adapt to load but can grow unbounded and cause memory pressure. Decision: Use dynamic pools with hard max limits (e.g., min=10, max=100) and monitor utilization—if you frequently hit max, increase it; if you rarely exceed min, reduce max to free resources.

Dimension: Eager vs Lazy Initialization. Eager initialization (Option A) pays construction cost at startup, ensuring predictable runtime performance but increasing startup time. Lazy initialization (Option B) defers cost until first use, speeding startup but introducing latency jitter on first access. Decision: Eagerly initialize objects on critical path (DB connection pools, HTTP clients), lazily initialize rarely-used objects (admin tools, background jobs).

When to Use (and When Not To)

Apply improper instantiation fixes when: (1) Profiling shows >15% CPU time in object constructors or GC, (2) GC pause times exceed 50ms and correlate with allocation spikes, (3) You’re creating objects with network I/O (database connections, HTTP clients) or file I/O (parsers, serializers) in request handlers, (4) Heap allocation rate exceeds 100MB/sec in steady state, (5) You see “connection refused” or “too many open files” errors under load. Don’t over-apply: (6) Avoid pooling lightweight objects (strings, primitives, small DTOs)—pooling overhead exceeds construction cost, (7) Don’t use singletons for objects with mutable state unless you add synchronization (which kills performance), (8) Don’t pool objects that can’t be safely reset between uses (objects holding user session data, transaction contexts), (9) Don’t lazy-initialize objects on critical path if initialization takes >100ms—pay the cost at startup instead. Red flags: Creating database connections in loops, instantiating HTTP clients per request, parsing XML schemas on every document, creating thread pools in request handlers. At Google, a service was creating a new gRPC channel per RPC call—channels are expensive (TLS handshake, load balancer resolution) and meant to be long-lived. Switching to a singleton channel reduced P99 latency from 300ms to 15ms.

Real-World Examples

company: Stripe system: Payment Processing API implementation: Stripe’s payment processing service initially created a new Kafka producer per payment event to publish to audit logs. Under normal load (1000 payments/sec), this caused 200ms P99 latency spikes—each producer instantiation triggered metadata fetch from Kafka brokers (50ms) and connection establishment (30ms). Engineers refactored to use a singleton producer with a connection pool to brokers, reducing P99 to 20ms and cutting GC pause time from 150ms to 30ms. The singleton producer is initialized at startup with 10 pre-warmed connections to Kafka partitions. interesting_detail: They discovered that Kafka producer instantiation also triggered DNS lookups for broker hostnames, adding another 20ms. Caching DNS results in the singleton eliminated this overhead entirely.

company: Netflix system: Zuul API Gateway implementation: Netflix’s Zuul gateway was creating new HTTP connection pools per backend service call, causing file descriptor exhaustion (>10,000 open sockets) and 500ms connection timeouts during traffic spikes. They implemented a singleton connection pool manager (using Apache HttpClient’s PoolingHttpClientConnectionManager) with 200 max connections per route and 500 total connections. This reduced P99 latency from 800ms to 50ms and eliminated socket exhaustion errors. interesting_detail: They use dynamic pool sizing based on request rate—during peak hours (evening streaming), the pool expands to 500 connections; during off-peak, it contracts to 100 to free resources for other services on the same host.

company: Uber system: Geospatial Matching Service implementation: Uber’s trip matching service loads city map data (200MB geospatial index) to calculate driver-rider distances. Initially, each matching request loaded the index from disk, causing 5-second latency and 2GB/sec disk I/O. Engineers implemented an object pool of 10 pre-loaded index objects (one per CPU core), reducing latency to 50ms and eliminating disk I/O during steady state. The pool uses Apache Commons Pool with validation to detect corrupted indexes and reload them. interesting_detail: They added a warmup phase at startup where all pool objects are initialized and validated before accepting traffic, preventing cold-start latency spikes when the service restarts.

---

Interview Essentials

Mid-Level

Explain the difference between object pooling and singleton patterns—when would you use each? Walk through how connection pooling works: what happens when a thread requests a connection and the pool is exhausted? How do you size a connection pool? (Use Little’s Law: concurrent connections = request rate × query time.) Describe how improper instantiation causes GC pressure—why does creating many short-lived objects trigger frequent garbage collection? What metrics would you monitor to detect this antipattern? (Allocation rate, GC pause time, pool utilization.)

Senior

Design a connection pool implementation from scratch: what data structures would you use? (ConcurrentLinkedQueue for available connections, AtomicInteger for pool size tracking.) How do you handle connection validation and timeout? Explain the trade-offs between eager and lazy initialization for expensive objects—when would you choose each? How would you debug a production system with 200ms GC pauses? (Heap dump analysis, allocation profiling, identify top allocating classes.) Describe a scenario where object pooling made things worse—what went wrong? (Over-pooling lightweight objects, pool contention becoming the bottleneck.)

Debugging Production GC Pauses: Investigation Flow

sequenceDiagram
    participant Monitoring as Monitoring/APM
    participant Engineer as Engineer
    participant Profiler as Heap Profiler
    participant Code as Codebase
    participant Deploy as Deployment
    
    Monitoring->>Engineer: 1. Alert: P99 latency 500ms<br/>GC pause time 200ms
    Engineer->>Monitoring: 2. Check GC logs<br/>Young-gen collections every 2s
    Monitoring-->>Engineer: 3. Heap allocation rate:<br/>500MB/sec
    
    Engineer->>Profiler: 4. Attach heap profiler<br/>(JProfiler/dotMemory)
    Profiler->>Profiler: 5. Record allocation hotspots<br/>for 60 seconds
    Profiler-->>Engineer: 6. Top allocating classes:<br/>• DBConnection: 40%<br/>• HttpClient: 25%<br/>• XmlParser: 15%
    
    Engineer->>Code: 7. Analyze call stacks<br/>for DBConnection
    Code-->>Engineer: 8. Found: new DBConnection()<br/>in request handler loop
    
    Engineer->>Engineer: 9. Calculate ROI:<br/>1000 req/sec × 64KB = 64MB/sec<br/>Construction time: 50ms × 1000 = 50 CPU-sec/sec
    
    Engineer->>Code: 10. Implement connection pool<br/>HikariCP with min=20, max=100
    Code->>Deploy: 11. Deploy to canary<br/>(10% traffic)
    
    Deploy->>Monitoring: 12. Monitor metrics
    Monitoring-->>Engineer: 13. Results:<br/>• Allocation rate: 50MB/sec (-90%)<br/>• GC pause: 30ms (-85%)<br/>• P99 latency: 50ms (-90%)
    
    Engineer->>Deploy: 14. Gradual rollout to 100%
    Deploy->>Monitoring: 15. Validate at scale
    Monitoring-->>Engineer: 16. Success: Sustained improvement

Production debugging flow for GC pause issues: start with monitoring alerts, use heap profilers to identify allocation hotspots, analyze call stacks to find improper instantiation, calculate ROI of fixes, implement pooling, and validate with canary deployment before full rollout.

Staff+

You’re reviewing a microservice with 500ms P99 latency and 40% CPU time in GC. Walk through your investigation and remediation strategy. (Profile allocation hotspots, identify expensive constructors, calculate ROI of pooling vs code changes.) Design a dynamic connection pool that adapts to traffic patterns—how do you balance responsiveness vs resource efficiency? (Exponential backoff for pool growth, idle timeout for shrinkage, circuit breaker for pool exhaustion.) Explain how improper instantiation interacts with other antipatterns (chatty I/O, busy database)—how do you prioritize fixes? Discuss the architectural implications of singleton patterns in distributed systems—what are the failure modes? (Singleton becomes a single point of failure, state synchronization issues, testing challenges.)

Common Interview Questions

How do you detect improper instantiation in a running system? (Heap profilers, allocation rate metrics, GC logs showing frequent young-gen collections.)

What’s the difference between connection pooling and thread pooling? (Connection pools manage I/O resources, thread pools manage CPU resources—both prevent expensive creation overhead.)

When would you NOT use object pooling? (Lightweight objects where pooling overhead exceeds construction cost, objects that can’t be safely reset, memory-constrained environments.)

How do you size a connection pool for a database? (Little’s Law: pool size = request rate × query latency, add 20% buffer for bursts, monitor wait time and adjust.)

Explain the double-checked locking problem in singleton implementation. (Without proper memory barriers, partially-constructed objects can be visible to other threads—use volatile or static initialization instead.)

Red Flags to Avoid

Can’t explain why object creation is expensive (network I/O, memory allocation, initialization logic)—shows lack of understanding of construction cost.

Suggests pooling everything without considering trade-offs—over-engineering, doesn’t understand when simplicity is better.

Doesn’t mention GC impact when discussing improper instantiation—misses the primary performance problem.

Proposes fixed pool sizes without monitoring or dynamic adjustment—shows lack of production experience with load variability.

Can’t explain how to validate pooled objects or handle stale connections—doesn’t understand resource lifecycle management.

---

Key Takeaways

Improper instantiation causes performance degradation through two mechanisms: direct CPU cost of object construction (network I/O, initialization logic) and indirect GC pressure from heap allocation churn—fixing it can reduce GC pause time by 60-80%.

Apply reuse patterns based on object characteristics: singleton for thread-safe stateless objects (HTTP clients, serializers), connection pooling for stateful resources (DB connections, file handles), lazy initialization for expensive one-time setup (ML models, large data structures).

Size connection pools using Little’s Law (concurrent connections = request rate × query time) and monitor utilization—healthy pools show 60-80% utilization during peak load with <1ms wait time for checkout.

The antipattern is insidious because it degrades gracefully until you hit a traffic threshold where GC overhead crosses 30% of CPU time—profile allocation hotspots proactively, don’t wait for production incidents.

Avoid over-applying pooling: don’t pool lightweight objects (strings, primitives), don’t use singletons for mutable state without synchronization, and don’t lazy-initialize objects on critical path if initialization takes >100ms—pay the cost at startup instead.

---