Scale मा, throughput CPU count भन्दा contention, cache effects, र असीमित queues ले बढी सीमित हुन्छ — एउटा बिन्दु नाघेपछि threads थप्दा कुरा ढिलो हुन्छ। Amdahl's र Universal Scalability Law दुवैले यो अनुमान गर्छन्: coordination खर्च अन्ततः हावी हुन्छ।
धेरै threads एउटै lock वा cache line का लागि लड्दा, तिनीहरू serialize हुन्छन् र काम गर्नुको सट्टा कुर्दै समय बिताउँछन्। Universal Scalability Law अन्तर्गत, contention र coherency खर्च ले optimal thread count नाघेपछि throughput सक्छ।
उपायहरू: डेटा shard/partition गर्नुहोस्, per-thread state (thread-local, LongAdder जस्ता striped counters), read-write locks, वा lock-free structures।
दुई स्वतन्त्र variables जुन संयोगले एउटै CPU cache line मा बस्छन्, हरेक write मा cores लाई एकअर्काको cache invalidate गराउँछन्, यद्यपि तिनीहरू कहिल्यै उही डेटा छुँदैनन् — एउटा मौन, क्रूर मन्दी।
cache line (64B): [ counterA | counterB ] ← two cores ping-pong the line
Fix: pad so each hot variable owns its own line
@Contended long counterA; // JVM pads to a separate cache line
Producers ले consumers लाई उछिन्दा, असीमित queue OOM नआउन्जेल बढ्छ र latency विस्फोट हुन्छ। Backpressure ले producers लाई ढिलो हुन संकेत गर्छ: block वा reject गर्ने bounded queues, credit-based flow control, वा reactive-streams request(n)।
producer ──▶ [bounded queue full] ──▶ block/reject ──▶ producer slows
यी नै "4 cores मा काम गर्छ" लाई "64 सम्म scale हुन्छ" बाट छुट्याउने प्रभावहरू हुन्। Naive designs पर्खालमा ठोक्किन्छन्: locks serialize हुन्छन्, cache lines thrash हुन्छन्, queues फुल्छन्। Contention घटाउन sharding, false sharing मार्न padding, र queues सीमित गर्न backpressure नै वास्तविक load मा latency र throughput स्वस्थ राख्ने levers हुन्।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्