Module 01 — Tổng kết & cheat sheet

TL;DR: Module 01 đi từ "vì sao race condition xảy ra" tới "tổ chức cả hệ thống concurrent thế nào", qua 22 bài và 5 phiên bản TicketFlow. Trang này gom tất cả thành một chỗ tra cứu nhanh: bảng chọn công cụ theo tình huống, glossary thuật ngữ, các pitfall hay gặp nhất kèm code sai → đúng, và checklist tự đánh giá. Bookmark nó — sáu tháng sau khi cần chọn giữa ReentrantLock và ConcurrentHashMap.compute, đây là trang để quay lại.

Đã đi qua những gì

Sợi chỉ xuyên suốt module là một hệ thống đặt vé. TicketFlow v0 mở màn ở bài thread safety với một BookingService chạy hoàn hảo đơn luồng nhưng oversell dưới tải, vì book là một cụm check-then-act không nguyên tử trên HashMap dùng chung. Ta thử né vấn đề bằng confinement (dồn đặt vé vào một thread duy nhất) và immutability (Event, Booking thành record), rồi nhận ra số vé đã bán vốn dĩ vừa shared vừa mutable — không né được, phải canh gác. v1 vá race bằng Java Monitor Pattern, sau đó thử các biến thể: bộ đếm AtomicInteger lock-free, ReentrantLock để có tryLock và timeout, read-write lock cho tồn kho đọc nhiều ghi ít. v2 chuyển hẳn sang delegation — ConcurrentHashMap.compute cho atomicity per-key — và dựng pipeline producer–consumer qua BlockingQueue với poison pill và interrupt để shutdown sạch. v3 nâng tầng kiến trúc: booking pool dựng tay từ ThreadPoolExecutor với queue bounded và CallerRunsPolicy làm backpressure, luồng validate → book → notify ghép bằng CompletableFuture, báo cáo đối soát chạy fork/join. Cuối cùng v4 đổi tầng request sang virtual thread — một thread mỗi request, thoải mái block ở I/O — và bọc fan-out kiểm tồn kho + xác thực thanh toán vào StructuredTaskScope với ScopedValue mang context. Công cụ đổi qua từng phiên bản, nhưng câu hỏi trung tâm thì không: dữ liệu nào đang shared, dữ liệu nào mutable, và ai đang canh gác nó.

flowchart LR
    V0["v0<br/>HashMap<br/>race oversell"] --> V1["v1<br/>monitor / atomic /<br/>explicit lock"]
    V1 --> V2["v2<br/>CHM compute +<br/>BlockingQueue"]
    V2 --> V3["v3<br/>ThreadPoolExecutor +<br/>CompletableFuture"]
    V3 --> V4["v4<br/>virtual thread +<br/>structured concurrency"]
    style V0 fill:#FCA5A5
    style V4 fill:#6EE7B7

🗺️ Cheat sheet

📖 Glossary module

⚠️ Pitfall tổng hợp

Bảy lỗi gây ra phần lớn sự cố concurrency trong code production — tất cả đều đã xuất hiện trong module, gom lại đây để soi code review.

1. Check-then-act trên collection "đã thread-safe" (bài 04, 13). Đổi HashMap thành ConcurrentHashMap không cứu được cụm thao tác.

// SAI — tung thao tac an toan, ca cum van race
if (sold.get(id) < cap) sold.put(id, sold.get(id) + 1);

// DUNG — compound action nguyen tu per-key
sold.compute(id, (k, v) -> v == null || v >= cap ? v : v + 1);

2. volatile cho read-modify-write (bài 05, 08). volatile chỉ cho visibility, không cho atomicity.

// SAI — hai thread cung cong van mat lan tang
private volatile long revenue;
revenue += amount;

// DUNG — contention cao thi LongAdder
private final LongAdder revenue = new LongAdder();
revenue.add(amount);

3. Quên unlock trong finally (bài 11). ReentrantLock không tự nhả như synchronized; một exception là khóa kẹt vĩnh viễn.

// SAI — exception giua chung lam moi thread sau cho mai mai
lock.lock();
doWork();
lock.unlock();

// DUNG
lock.lock();
try { doWork(); } finally { lock.unlock(); }

4. Nuốt InterruptedException (bài 02, 15, 17). Nuốt im lặng là xóa sổ một yêu cầu hủy — pool có thể không bao giờ tắt được.

// SAI — tin hieu huy bien mat
try { task = queue.take(); } catch (InterruptedException e) { }

// DUNG — khoi phuc co roi thoat co trat tu
try { task = queue.take(); }
catch (InterruptedException e) {
    Thread.currentThread().interrupt();
    return;
}

5. Pool với queue không giới hạn (bài 15, 17). Executors.newFixedThreadPool dùng LinkedBlockingQueue unbounded: pool không bao giờ từ chối, chỉ âm thầm tích nợ tới OOM.

// SAI — khong co tran nao cho queue
ExecutorService pool = Executors.newFixedThreadPool(10);

// DUNG — bounded queue + chinh sach khi cham tran
ExecutorService pool = new ThreadPoolExecutor(10, 10, 0, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(1_000), new ThreadPoolExecutor.CallerRunsPolicy());

6. CompletableFuture chạy I/O trên commonPool và nuốt exception (bài 18). *Async không truyền executor sẽ chiếm ForkJoinPool.commonPool() — vài task chờ DB là parallel stream toàn JVM vạ lây; pipeline không có stage lỗi thì task hỏng không một dòng log.

// SAI — blocking I/O tren commonPool, loi bien mat trong im lang
CompletableFuture.supplyAsync(() -> httpClient.fetch(url));

// DUNG — executor rieng cho I/O + dong chuoi bang noi tieu thu loi
CompletableFuture.supplyAsync(() -> httpClient.fetch(url), ioPool)
    .exceptionally(ex -> { log.error("fetch failed", ex); return fallback; });

7. Ôm khóa qua lời gọi I/O dài (bài 08, 21). Khóa để bảo vệ shared mutable state, không phải để serialize lời gọi mạng; trên Java 21 khối synchronized block còn ghim carrier của virtual thread.

// SAI — giu khoa suot mot round-trip mang
synchronized (lock) { return remoteApi.fetch(symbol); }

// DUNG — ReentrantLock, va thu hep khoa ve dung phan shared state
lock.lock();
try { return cache.get(symbol); } finally { lock.unlock(); }
// goi remoteApi.fetch ngoai khoa, roi cap nhat cache trong mot khoa ngan

✅ Self-assessment

Bạn đã đạt module này nếu tự tin tick đủ bảy ô — mỗi ô khớp một learning outcome của module:

• Giải thích được vì sao concurrency bug xảy ra: shared mutable state, atomicity vs visibility, và quan hệ happens-before của Java Memory Model.
  • Nếu chưa → đọc lại bài 03 — Thread safety, rồi bài 04 — Atomicity và bài 05 — Visibility cạnh nhau.
• Chẩn đoán được race condition trong code thật bằng cách trace các interleaving xui xẻo nhất và chỉ ra compound action không nguyên tử.
  • Nếu chưa → đọc lại bài 04 — Atomicity (read-modify-write, check-then-act) và tự vẽ timeline hai thread cho BookingService v0.
• Triển khai được class thread-safe theo bốn chiến lược: confinement, immutability, synchronization, và delegation.
  • Nếu chưa → đọc lại bài 06 — Confinement, bài 07 — Immutability, bài 08 — volatile & synchronized và bài 13 — Delegation.
• Chọn đúng cơ chế đồng bộ theo pattern truy cập và mức contention — volatile, synchronized, Atomic/LongAdder, ReentrantLock, ReadWriteLock/StampedLock hay ConcurrentHashMap.
  • Nếu chưa → đọc lại bài 10 — Atomic & CAS, bài 11 — ReentrantLock, bài 12 — ReadWriteLock & StampedLock, rồi dò ngược cheat sheet ở trên.
• Thiết kế được kiến trúc thực thi tách task khỏi thread: producer–consumer với BlockingQueue, thread pool có backpressure, pipeline async bằng CompletableFuture.
  • Nếu chưa → đọc lại bài 15 — Blocking queues, bài 17 — Executor và bài 18 — CompletableFuture.
• Trace được vòng đời một request trên virtual thread — mount/unmount, pinning — và quyết định khi nào di cư từ thread pool sang virtual thread cùng structured concurrency.
  • Nếu chưa → đọc lại bài 20 — Virtual threads, bài 21 — Pinning & di cư và bài 22 — Structured concurrency.
• Chọn đúng synchronizer (CountDownLatch, CyclicBarrier, Semaphore, Phaser) cho từng hình dạng điều phối tiến độ, và phân biệt điều phối tiến độ với bảo vệ dữ liệu.
  • Nếu chưa → đọc lại bài 16 — Synchronizers.

🚀 What's next

Module tiếp theo đổi trục: từ "nhiều thread tranh nhau CPU và bộ nhớ" sang "chương trình nói chuyện với thế giới bên ngoài". Module 02 — I/O & NIO bắt đầu từ stream I/O cổ điển, đi qua Path/Files, serialization và những rủi ro bảo mật của nó, để chuẩn bị nền cho NIO. Kiến thức concurrency vừa học sẽ quay lại liên tục ở đó — blocking I/O chính là lý do virtual thread tồn tại, và mô hình selector của NIO là câu trả lời khác cho cùng bài toán "một thread phục vụ nhiều kết nối".

📚 Tài liệu mở rộng

• Sách: Java Concurrency in Practice — Brian Goetz và cộng sự. Nguồn gốc của phần lớn khung khái niệm trong module (shared mutable state, bốn chiến lược, delegation); cũ về API nhưng chưa cũ về tư duy.
• Spec: JLS Chapter 17 — Threads and Locks — định nghĩa hình thức của Java Memory Model và happens-before; đọc sau khi đã vững bài 05 và 08.
• JEP: JEP 444 — Virtual Threads (final Java 21), JEP 491 — Synchronize Virtual Threads without Pinning (Java 24), JEP 505 — Structured Concurrency (preview, Java 25), JEP 506 — Scoped Values (final Java 25) — đọc phần Motivation của mỗi JEP là cách nhanh nhất hiểu "vì sao API này tồn tại".
• Blog: Inside.java — bài viết và podcast của chính team JDK về Loom, concurrency và JVM; lọc theo tag "Loom" để theo dòng tiến hóa virtual thread.

Bài đầu tiên của module kế: Stream I/O cổ điển