อะไรจำกัด concurrency ในระดับ scale? อธิบาย contention, false sharing และ backpressure

Question

IT Interview Practice · Accepted Answer

**ในระดับ scale throughput ถูกจำกัดโดยจำนวน CPU น้อยกว่าที่ถูกจำกัดด้วย contention, ผลกระทบของ cache และ queue ที่ไม่จำกัด — การเพิ่ม thread เกินจุดหนึ่งกลับทำให้ช้าลง** ทั้งกฎของ Amdahl และ Universal Scalability Law ต่างทำนายสิ่งนี้: ต้นทุนการประสานงานจะครอบงำในที่สุด

## Contention

เมื่อหลาย thread แย่งชิง lock ตัวเดียวหรือ cache line เดียว พวกมันจะทำงานเป็นอนุกรมและใช้เวลารอแทนที่จะทำงาน ภายใต้ Universal Scalability Law contention บวกกับ **coherency cost** สามารถทำให้ throughput *ลดลง* เมื่อเกินจำนวน thread ที่เหมาะสม

**การบรรเทา**: shard/partition ข้อมูล, state แยกต่อ thread (thread-local, ตัวนับแบบ striped เช่น `LongAdder`), read-write lock หรือโครงสร้างแบบ lock-free

## False sharing

ตัวแปรอิสระสองตัวที่บังเอิญอยู่บน **cache line เดียวกันของ CPU** ทำให้ core ต่าง ๆ invalidate แคชของกันและกันทุกครั้งที่เขียน แม้ว่ามันจะไม่เคยแตะข้อมูลชุดเดียวกัน — เป็นการชะลอตัวที่เงียบและรุนแรง

```text
cache line (64B): [ counterA | counterB ]  ← two cores ping-pong the line
Fix: pad so each hot variable owns its own line
```

```java
@Contended long counterA;   // JVM pads to a separate cache line
```

## Backpressure

เมื่อผู้ผลิต (producer) เร็วกว่าผู้บริโภค (consumer) queue ที่ไม่จำกัดจะโตขึ้นจน OOM และ latency พุ่งทะยาน **Backpressure** ส่งสัญญาณให้ผู้ผลิตช้าลง: queue ที่มีขอบเขตซึ่งบล็อกหรือปฏิเสธ, การควบคุมการไหลแบบ credit-based หรือ `request(n)` ของ reactive-streams

```text
producer ──▶ [bounded queue full] ──▶ block/reject ──▶ producer slows
```

## ทำไมจึงสำคัญ

สิ่งเหล่านี้คือผลกระทบที่แยก "ทำงานได้บน 4 core" ออกจาก "ขยายได้ถึง 64 core" การออกแบบแบบไร้เดียงสาจะชนกำแพง: lock ทำให้เป็นอนุกรม, cache line กระแทกกันไปมา, queue พองโต การ shard เพื่อลด contention, การ pad เพื่อกำจัด false sharing และ backpressure เพื่อจำกัด queue คือคันโยกที่รักษา latency และ throughput ให้แข็งแรงภายใต้โหลดจริง

Contention

False sharing

Backpressure

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง