Đồng thờiConcurrency

Read-Write Lockaka Readers-Writer Lock, Shared-Exclusive Lock, RWMutex

Cho nhiều người đọc cùng lúc, nhưng người ghi thì phải độc quyền.Many readers at once, but a writer gets exclusive access.

Độ khóDifficulty: VừaMedium
Mức phổ biếnUsage: Mức phổ biếnUsage 3/5
Thời gian đọcReading time: ~9 phút đọc~9 min read

Thảo luậnDiscussion

Ví dụ đời thườngReal-life analogy

Bảng tỷ giá điện tử ở quầy ngân hàng: cả chục khách có thể cùng nhìn bảng một lúc, không ai cản ai. Nhưng khi nhân viên cập nhật tỷ giá mới, họ kéo rèm che bảng lại — không ai được nhìn bảng đang sửa dở (thấy USD giá mới, EUR giá cũ). Cập nhật xong, rèm mở, mọi người lại cùng xem.The exchange-rate board at a bank counter: a dozen customers can look at it at once without bothering each other. But when a clerk updates the rates, they draw a curtain over the board — nobody may see a half-updated board (USD new, EUR old). Once done, the curtain opens and everyone reads again.

Vấn đề và giải phápProblem and solution

Không có patternWithout the pattern

App ví điện tử giữ bảng tỷ giá trong bộ nhớ: mỗi giây hàng nghìn request đọc để quy đổi, còn 5 phút mới có một lần cập nhật. Không khoá gì thì bị data race — đọc phải map đang ghi dở, Go còn có thể crash 'concurrent map read and map write'. Dùng một Mutex thường thì an toàn nhưng các request ĐỌC phải xếp hàng lần lượt dù chẳng ai sửa gì — lãng phí CPU nhiều lõi.A wallet app keeps exchange rates in memory: thousands of requests per second read them for conversions, while an update happens once every 5 minutes. No locking → a data race — reading a map mid-write, and Go may even crash with 'concurrent map read and map write'. A plain Mutex is safe, but READ requests queue one by one even though nobody is changing anything — wasting your multi-core CPU.

Với Read-Write LockWith Read-Write Lock

Dùng khoá đọc-ghi: khoá ĐỌC là khoá chia sẻ (nhiều reader giữ cùng lúc), khoá GHI là khoá độc quyền (chờ mọi reader rời đi và chặn reader mới). Làm phần I/O chậm (gọi API ngân hàng) BÊN NGOÀI khoá, chỉ giữ khoá ghi trong tích tắc để hoán đổi dữ liệu. Với nhiều trường hợp, cách đơn giản hơn là copy-on-write: thay nguyên một snapshot bất biến bằng atomic reference.Use a read-write lock: the READ lock is shared (many readers hold it together), the WRITE lock is exclusive (it waits for all readers to leave and blocks new ones). Do the slow I/O (calling the bank API) OUTSIDE the lock, and hold the write lock only for an instant to swap the data. Often an even simpler option is copy-on-write: replace a whole immutable snapshot through an atomic reference.

Thành phần tham giaParticipants

Shared data: Dữ liệu đọc nhiều ghi ít (cache, config, bảng giá).Read-mostly data (cache, config, price tables).
Read lock: Khoá chia sẻ: nhiều reader cùng giữ được.Shared lock: many readers can hold it together.
Write lock: Khoá độc quyền: chỉ một writer, không reader nào.Exclusive lock: one writer, zero readers.
Readers / Writer: Goroutine/thread đọc (request) và goroutine/thread ghi (job làm mới định kỳ).Reading goroutines/threads (requests) and the writing one (a periodic refresh job).

Sơ đồ và luồng thực thiDiagram and execution flow

Dùng Tự chạy hoặc phím mũi tên để đi qua từng bước gọi giữa các object. Console hiển thị output tương ứng của chương trình.Use Autoplay or the arrow keys to step through each call between objects. The console shows the matching program output.

1Request #1 và #2 cùng RLock và đọc song song — khoá đọc là chia sẻ.Requests #1 and #2 both RLock and read in parallel — the read lock is shared.

← →

console

1readers=2 · USD=25,410 · EUR=27,350

implementsimplementsextendsextendsgọi / dùngcalls / usestạo racreatesgửi qua channelsends via channel1thứ tự chạy (bấm để nhảy bước)execution order (click to jump)

Code: Java Spring Boot ⇄ GoCode: Java Spring Boot ⇄ Go

Cùng một bài toán, hai ngôn ngữ. Rê chuột hoặc focus vào chú thích (số màu cam) để làm nổi bật dòng code tương ứng.Same problem, two languages. Hover or focus an annotation (orange number) to highlight its line.

JavaSpring Boot 3 · Java 21Spring Boot 3 · Java 21

package com.wallet.fx;

import java.math.BigDecimal;
import java.util.HashMap;
import java.util.Map;
import java.util.Optional;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

@Component
public class ExchangeRateCache {
    private final ReadWriteLock lock = new ReentrantReadWriteLock();1
    private final Map<String, BigDecimal> rates = new HashMap<>();2
    private final FxClient fx;

    public ExchangeRateCache(FxClient fx) {
        this.fx = fx;
    }

    public Optional<BigDecimal> rate(String currency) {
        lock.readLock().lock(); // many readers at the same time3
        try {
            return Optional.ofNullable(rates.get(currency));
        } finally {
            lock.readLock().unlock();
        }
    }

    @Scheduled(fixedRate = 300_000)
    public void refresh() {
        Map<String, BigDecimal> fresh = fx.fetchAll(); // slow I/O OUTSIDE the lock4
        lock.writeLock().lock(); // exclusive: waits for readers to leave
        try {
            rates.clear();
            rates.putAll(fresh);
        } finally {
            lock.writeLock().unlock();
        }
    }
}

GoGo 1.23 · thư viện chuẩnGo 1.23 · standard library

package fx

import (
	"context"
	"sync"
)

type RateTable struct {
	mu    sync.RWMutex // must not be copied: always use *RateTable1
	rates map[string]float64
}

func (t *RateTable) Get(currency string) (float64, bool) {
	t.mu.RLock() // shared: many readers in parallel2
	defer t.mu.RUnlock()
	r, ok := t.rates[currency]
	return r, ok
}

type FetchFunc func(context.Context) (map[string]float64, error)

func (t *RateTable) Refresh(ctx context.Context, fetch FetchFunc) error {
	fresh, err := fetch(ctx) // network call OUTSIDE the lock3
	if err != nil {
		return err
	}
	t.mu.Lock() // exclusive: waits for active readers, blocks new ones4
	t.rates = fresh
	t.mu.Unlock()
	return nil
}

Khác biệt chính giữa Java và GoKey differences between Java and Go

01Java: ReentrantReadWriteLock cho phép reentrant (thread giữ khoá đọc lấy tiếp khoá đọc) và hạ cấp ghi → đọc. Go: sync.RWMutex KHÔNG reentrant — RLock lồng nhau có thể deadlock khi có writer chờ.Java: ReentrantReadWriteLock is reentrant (a thread holding a read lock can take it again) and supports downgrading write → read. Go: sync.RWMutex is NOT reentrant — nested RLock can deadlock when a writer is waiting.
02Cả hai đều KHÔNG cho nâng cấp đọc → ghi: đang giữ khoá đọc mà xin khoá ghi là tự chờ chính mình mãi mãi.Neither allows upgrading read → write: requesting the write lock while holding the read lock waits on yourself forever.
03Java dùng try/finally để unlock; Go dùng defer mu.RUnlock(). Go không có synchronized — mọi khoá đều là giá trị tường minh trong struct.Java unlocks in try/finally; Go uses defer mu.RUnlock(). Go has no synchronized — every lock is an explicit value inside a struct.
04Thay thế không khoá: Java có volatile + collection bất biến, ConcurrentHashMap, StampedLock (optimistic read). Go có atomic.Pointer[T] và sync.Map (chỉ cho vài tình huống đặc thù).Lock-free alternatives: Java has volatile + immutable collections, ConcurrentHashMap, StampedLock (optimistic reads). Go has atomic.Pointer[T] and sync.Map (only for specific cases).

Ứng dụng thực tếReal-world usage

JDK: ConcurrentHashMap, CopyOnWriteArrayList, StampedLockJDK: ConcurrentHashMap, CopyOnWriteArrayList, StampedLock
Spring dùng ConcurrentHashMap khắp nơi (cache bean metadata); CopyOnWriteArrayList cho danh sách listener — đọc nhiều, ghi cực hiếm.Spring uses ConcurrentHashMap everywhere (bean metadata caches); CopyOnWriteArrayList for listener lists — many reads, very rare writes.
Go stdlib và thư việnGo stdlib and libraries
net/http ServeMux, registry của database/sql driver, và nhiều cache nội bộ dùng sync.RWMutex; encoding/json cache thông tin struct bằng sync.Map (ghi một lần, đọc mãi).net/http ServeMux, the database/sql driver registry and many internal caches use sync.RWMutex; encoding/json caches struct info in a sync.Map (write once, read forever).
Config / feature flag nóngHot config / feature flags
Feature flag đọc trên mọi request, cập nhật khi admin bấm nút — điển hình cho RWMutex hoặc snapshot atomic.Feature flags read on every request and updated when an admin clicks a button — a textbook RWMutex or atomic snapshot case.
Bảng giá, tỷ giá, danh mục sản phẩmPrice lists, FX rates, product catalogs
Sàn thương mại điện tử giữ cây danh mục trong RAM, đồng bộ lại vài phút một lần từ DB.E-commerce platforms keep the category tree in RAM and resync it from the DB every few minutes.

Khi nào dùng và khi nào khôngWhen to use it, and when not

Nên dùng khiUse it when

Dữ liệu dùng chung đọc nhiều gấp bội so với ghi.Shared data that is read far more often than written.
Đoạn đọc đủ dài (duyệt cấu trúc, tính toán) để việc cho reader chạy song song thực sự có lợi.The read section is long enough (walking a structure, computing) for parallel readers to actually pay off.
Cần cập nhật tại chỗ một phần dữ liệu lớn mà copy-on-write sẽ quá tốn kém.You need in-place updates to a large structure where copy-on-write would be too expensive.

Không nên dùng khiAvoid it when

Đoạn găng chỉ vài nano giây (đọc một field) — RWMutex nặng hơn Mutex thường, có khi còn chậm hơn; dùng atomic.The critical section is a few nanoseconds (reading one field) — an RWMutex is heavier than a plain Mutex and may be slower; use atomics.
Ghi thường xuyên ngang ngửa đọc — Mutex đơn giản hơn và nhanh tương đương.Writes are about as frequent as reads — a plain Mutex is simpler and just as fast.
Dữ liệu nằm trên nhiều instance — khoá trong bộ nhớ không đồng bộ được giữa các process; cần DB/Redis.Data spans multiple instances — an in-memory lock can't coordinate processes; use the DB/Redis.

Ưu điểmPros

Reader chạy song song thật sự trên nhiều lõi CPU.Readers truly run in parallel across CPU cores.
Vẫn đảm bảo không ai thấy dữ liệu đang sửa dở.Still guarantees nobody sees half-modified data.
Thay thế gần như 1-1 cho Mutex khi profile cho thấy reader tranh chấp khoá.A near drop-in replacement for a Mutex when profiling shows readers contending.

Nhược điểmCons

Phức tạp hơn Mutex, dễ deadlock khi nâng cấp khoá hoặc RLock lồng nhau.More complex than a Mutex; easy to deadlock with lock upgrades or nested RLock.
Chi phí quản lý cao hơn, không có lợi khi đoạn đọc quá ngắn.Higher bookkeeping cost, no gain when the read section is tiny.
Writer giữ khoá lâu (I/O bên trong) sẽ làm đứng toàn bộ reader.A writer holding the lock too long (I/O inside) freezes every reader.

Anti-pattern: lỗi thường gặpAnti-pattern: common mistake

Nâng cấp khoá đọc lên khoá ghi — tự deadlockUpgrading a read lock to a write lock — self-deadlock

Đang giữ RLock rồi gọi Lock: Lock chờ mọi reader nhả khoá, mà chính goroutine này là một reader đang chờ Lock → treo vĩnh viễn. Thêm nữa, I/O chậm nằm trong khoá ghi. Cách đúng: RUnlock trước, gọi API ngoài khoá, rồi Lock và kiểm tra lại (double-check) trước khi ghi.Holding RLock and then calling Lock: Lock waits for every reader to release, but this goroutine is a reader waiting on Lock → hangs forever. On top of that, slow I/O sits under the write lock. The fix: RUnlock first, call the API outside any lock, then Lock and re-check (double-check) before writing.

func (t *RateTable) GetOrLoad(cur string) float64 {
	t.mu.RLock()
	defer t.mu.RUnlock()
	if r, ok := t.rates[cur]; ok {
		return r
	}
	t.mu.Lock() // ❌ still holding RLock → waits for itself forever
	defer t.mu.Unlock()
	t.rates[cur] = loadFromBank(cur) // ❌ slow I/O under the write lock
	return t.rates[cur]
}

Dễ nhầm vớiEasily confused with

Read-Write Lock vs Semaphore

Semaphore cho tối đa N người dùng tài nguyên, không phân biệt đọc/ghi. RW lock phân biệt: đọc không giới hạn số người, ghi thì độc quyền.A semaphore allows up to N users of a resource, regardless of read/write. An RW lock distinguishes: unlimited readers, exclusive writers.

Bài tập áp dụngExercise

Viết GetOrLoad(cur) ĐÚNG cho RateTable: nếu tỷ giá có sẵn thì trả về (chỉ dùng khoá đọc); nếu chưa có thì gọi loadFromBank(cur) ngoài khoá rồi ghi vào map, đảm bảo không deadlock và không ghi đè khi hai goroutine cùng tải một đồng tiền.Write a CORRECT GetOrLoad(cur) for RateTable: if the rate exists, return it (read lock only); otherwise call loadFromBank(cur) outside any lock and store it, without deadlocks and without clobbering when two goroutines load the same currency.

Kiểm tra kiến thứcKnowledge check

Câu 1 / 6Question 1 of 6

Điều nào ĐÚNG về khoá đọc-ghi?Which is TRUE about a read-write lock?

Phím 1–4 để chọn đáp án, Enter để kiểm tra.Press 1–4 to choose an answer, Enter to check.

Thẻ ghi nhớFlashcards

Ôn tập ngắt quãng (spaced repetition): thẻ được lặp lại sau 1 → 3 → 7 → 14 → 30 ngày để củng cố trí nhớ dài hạn.Spaced repetition: cards are repeated after 1 → 3 → 7 → 14 → 30 days to build long-term memory.

Dùng trong bài toánUsed in problems

3 bài toán Backend dùng pattern này3 backend problems use this pattern

Pattern liên quanRelated patterns

Semaphore Producer-Consumer Proxy Singleton

Thảo luậnDiscussion

Read-Write Lockaka Readers-Writer Lock, Shared-Exclusive Lock, RWMutex

Cho nhiều người đọc cùng lúc, nhưng người ghi thì phải độc quyền.Many readers at once, but a writer gets exclusive access.

VừaMedium

Mức phổ biếnUsage 3/5

~9 phút đọc~9 min read

package com.wallet.fx; import java.math.BigDecimal; import java.util.HashMap; import java.util.Map; import java.util.Optional; import java.util.concurrent.locks.ReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock; import org.springframework.scheduling.annotation.Scheduled; import org.springframework.stereotype.Component; @Component public class ExchangeRateCache { private final ReadWriteLock lock = new ReentrantReadWriteLock();1 private final Map<String, BigDecimal> rates = new HashMap<>();2 private final FxClient fx; public ExchangeRateCache(FxClient fx) { this.fx = fx; } public Optional<BigDecimal> rate(String currency) { lock.readLock().lock(); // many readers at the same time3 try { return Optional.ofNullable(rates.get(currency)); } finally { lock.readLock().unlock(); } } @Scheduled(fixedRate = 300_000) public void refresh() { Map<String, BigDecimal> fresh = fx.fetchAll(); // slow I/O OUTSIDE the lock4 lock.writeLock().lock(); // exclusive: waits for readers to leave try { rates.clear(); rates.putAll(fresh); } finally { lock.writeLock().unlock(); } } }

package fx import ( "context" "sync" ) type RateTable struct { mu sync.RWMutex // must not be copied: always use *RateTable1 rates map[string]float64 } func (t *RateTable) Get(currency string) (float64, bool) { t.mu.RLock() // shared: many readers in parallel2 defer t.mu.RUnlock() r, ok := t.rates[currency] return r, ok } type FetchFunc func(context.Context) (map[string]float64, error) func (t *RateTable) Refresh(ctx context.Context, fetch FetchFunc) error { fresh, err := fetch(ctx) // network call OUTSIDE the lock3 if err != nil { return err } t.mu.Lock() // exclusive: waits for active readers, blocks new ones4 t.rates = fresh t.mu.Unlock() return nil }

func (t *RateTable) GetOrLoad(cur string) float64 { t.mu.RLock() defer t.mu.RUnlock() if r, ok := t.rates[cur]; ok { return r } t.mu.Lock() // ❌ still holding RLock → waits for itself forever defer t.mu.Unlock() t.rates[cur] = loadFromBank(cur) // ❌ slow I/O under the write lock return t.rates[cur] }