คุณจะ synchronize การเข้าถึงสถานะที่แชร์ร่วมกันอย่างไร?

Question

Accepted Answer

**Synchronization** ประสานการเข้าถึงสถานะที่แชร์ร่วมกันและแก้ไขค่าได้ (shared mutable state) ของเธรดต่าง ๆ เพื่อไม่ให้การดำเนินการสลับสับเปลี่ยนกันอย่างอันตราย ป้องกัน **race condition** Java มีกลไกหลายแบบ ตั้งแต่คีย์เวิร์ด `synchronized` ที่มีอยู่ในตัว ไปจนถึง lock แบบชัดเจนและ atomic แบบไม่ใช้ lock

## synchronized — การกีดกันแบบเด็ดขาด (intrinsic lock)

```java
class BankAccount {
    private double balance;

// synchronized method — acquires the object's lock; only ONE thread at a time
    public synchronized void withdraw(double amount) {
        if (balance >= amount) {
            balance -= amount;   // protected — no interleaving
        }
    }
    // synchronized block — finer-grained, lock on a specific object
    public void deposit(double amount) {
        synchronized (this) {
            balance += amount;
        }
    }
}
```

`synchronized` รับประกันว่ามีเพียงเธรดเดียวที่รันโค้ดส่วนที่ถูกป้องกันได้ในแต่ละช่วงเวลา (mutual exclusion) และให้ **visibility** ด้วย คือการเปลี่ยนแปลงโดยเธรดหนึ่งจะมองเห็นได้โดยเธรดอื่น (มันข้าม memory barrier)

## volatile — visibility โดยไม่มี atomicity

```java
private volatile boolean running = true;   // guarantees VISIBILITY across threads

public void stop() { running = false; }     // other threads see the change immediately
public void run() { while (running) { ... } } // without volatile, might never see false
```

`volatile` รับประกันว่าการอ่าน/เขียนตัวแปรจะมองเห็นได้ข้ามเธรด แต่ **ไม่ได้** ทำให้การดำเนินการแบบประกอบ (เช่น `count++`) เป็น atomic ใช้มันสำหรับ flag แบบง่าย ไม่ใช่สำหรับการ read-modify-write

## คลาส Atomic — atomicity แบบไม่ใช้ lock

```java
AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();        // atomic ++ without locking (uses CPU CAS instructions)
counter.compareAndSet(5, 10);     // atomic conditional update
```

คลาส Atomic ให้การดำเนินการที่ thread-safe โดยไม่ต้องใช้ lock มักเร็วกว่า `synchronized` สำหรับ counter/accumulator แบบง่าย

## Lock แบบชัดเจน — ควบคุมได้มากกว่า

```java
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // critical section
} finally {
    lock.unlock();   // ALWAYS unlock in finally
}
// ReadWriteLock allows many concurrent readers but exclusive writers
```

`ReentrantLock` มีคุณสมบัติที่ `synchronized` ไม่มี: `tryLock()` (ไม่บล็อก), การรอแบบมีกำหนดเวลา, ความเป็นธรรม (fairness) และการแยก read-write

## อันตรายที่ต้องจัดการ

```text
⚠️ Deadlock — two threads each hold a lock the other needs → both stuck forever
   (avoid by always acquiring locks in a consistent order)
⚠️ Performance — over-synchronizing serializes everything, killing concurrency
   (synchronize the SMALLEST necessary section)
⚠️ Forgetting to unlock (with explicit Locks) → use try/finally
```

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

Synchronization เป็นสิ่งจำเป็นต่อความถูกต้องเมื่อใดก็ตามที่มีหลายเธรดเข้าถึงสถานะที่แชร์ร่วมกันและแก้ไขค่าได้ หากไม่มีมัน race condition จะทำให้ข้อมูลเสียหายและเกิดความล้มเหลวเป็นช่วง ๆ ที่แทบจะดีบักไม่ได้

การรู้จักเครื่องมือและการรับประกันที่แม่นยำของแต่ละตัวเป็นสิ่งสำคัญยิ่ง: `synchronized` (mutual exclusion + visibility), `volatile` (visibility เท่านั้น ไม่ใช่ atomicity ซึ่งเป็นความเข้าใจผิดที่พบบ่อย), คลาส atomic (ไม่ใช้ lock สำหรับการดำเนินการง่าย ๆ) และ Lock แบบชัดเจน (การควบคุมขั้นสูง)

ที่สำคัญพอกันคือการเข้าใจอันตราย ทั้ง **deadlock** และการ over-synchronization ที่กระทบประสิทธิภาพ รวมถึงวินัยในการ synchronize ให้น้อยที่สุดและสอดคล้องกัน

นี่เป็นความรู้แกนหลักที่มีความเสี่ยงสูงสำหรับ Java ฝั่งเซิร์ฟเวอร์ที่ทำงานแบบ concurrent และเป็นหัวข้อสัมภาษณ์เชิงลึกที่แยกแยะนักพัฒนาที่สามารถเขียนโค้ดแบบหลายเธรดได้อย่างถูกต้องออกมา