Guarded block với wait/notify trên Java Monitor Pattern

TL;DR: Khi đã có synchronized, câu hỏi kế là rải khóa ở đâu. Java Monitor Pattern trả lời: gói toàn bộ state mutable vào một object, canh bằng một private final Object lock duy nhất, để mọi method chạm state đều giữ cùng khóa — khi ấy chứng minh class an toàn là việc cục bộ, không phải đọc cả chương trình. Bước xa hơn là chờ một điều kiện: wait/notify gắn với intrinsic lock của mỗi object cho phép một thread nhả khóa và treo tới khi thread khác báo điều kiện đã đổi — guarded block. Hai luật sống còn: luôn kiểm điều kiện trong vòng while (spurious và stolen wakeup), và mặc định notifyAll thay vì notify.

1. Java Monitor Pattern gói state lại thế nào?

BookingService v0 của TicketFlow là check-then-act trên state dùng chung: đọc số vé đã bán, kiểm còn chỗ, rồi ghi tăng. Với concert-01 chỉ còn một chỗ, hai thread cùng chạy có thể cùng thấy còn chỗ rồi cùng bán — hai vé cho một ghế, phá invariant "không vượt capacity". Bài Atomicity đã chỉ ra đổi HashMap thành ConcurrentHashMap không cứu được, vì cụm compound action vẫn không nguyên tử.

Đẩy nguyên tắc đóng gói tới tận cùng cho ra một mẫu gọn: Java Monitor Pattern. Gói toàn bộ state mutable vào bên trong đối tượng, canh bằng một khóa, sao cho mọi method chạm state đều giữ cùng khóa đó. Khi ấy có đúng một nơi áp đặt kỷ luật đồng bộ, và ta kết luận class an toàn mà không phải đọc cả chương trình. Đây chính là lời giải đúng cho BookingService, và là bước v1 trong capstone — Monitor Pattern quây cả cụm vào một khóa:

public class BookingService {
    private final Object lock = new Object();
    @GuardedBy("lock") private final Map<String, Event> events = new HashMap<>();
    @GuardedBy("lock") private final Map<String, Integer> sold = new HashMap<>();

    public Booking book(String eventId, String userId) {
        synchronized (lock) {
            Event event = events.get(eventId);
            if (event == null) throw new IllegalArgumentException("Không có sự kiện: " + eventId);
            int current = sold.getOrDefault(eventId, 0);          // check ...
            if (current >= event.capacity()) throw new SoldOutException(eventId);
            sold.put(eventId, current + 1);                       // ... roi act, cung mot khoi
            return new Booking(eventId, userId, current + 1);
        }
    }

    public int soldCount(String eventId) {                        // reader cung PHAI khoa
        synchronized (lock) {
            return sold.getOrDefault(eventId, 0);
        }
    }
}

Kịch bản xen kẽ ở v0 không còn: nếu A đã vào, B phải chờ tới khi A ghi xong và nhả khóa; B vào sau đọc current = 1, thấy 1 >= 1, và đúng đắn ném SoldOutException. Cách nói chặt hơn: book đã khóa có một linearization point — thời điểm ghi sold bên trong khối — trước đó chưa khách nào giữ chỗ, sau đó chỗ đã thuộc booking này, không tồn tại trạng thái "ở giữa" mà thread khác quan sát được.

Để ý hai chi tiết. Thứ nhất, soldCount cũng synchronized trên cùng lock, vì reader không khóa có thể đọc giá trị cũ. Thứ hai, dùng private final Object lock thay vì khóa trên this: khóa trên this cho bất kỳ code bên ngoài nào cầm tham chiếu BookingService cũng synchronized trên nó, vô tình tham gia — đúng hoặc sai — vào chính sách khóa của ta, thậm chí gây deadlock; chính kỹ thuật client-side locking ở bài Delegation & concurrent collections khai thác cánh cửa này một cách cố ý. Một lock riêng tư đóng kín chính sách đồng bộ trong đúng một file; @GuardedBy("lock") ghi lại biến nào canh bởi khóa nào — một dòng rẻ hơn nhiều so với một đêm truy lỗi race condition trên production.

2. wait/notify: chờ một điều kiện mà không đốt CPU?

Đôi khi một thread không chỉ cần loại trừ lẫn nhau mà còn cần chờ một điều kiện thành đúng trước khi tiếp: worker chờ hàng đợi có việc, consumer chờ buffer có dữ liệu. Mẫu này gọi là guarded block - khối được canh bởi một điều kiện. Cách ngây thơ là quay vòng bận:

// PHAN VI DU — quay vong ban, dot CPU vo ich
synchronized (lock) {
    while (!conditionHolds()) { /* lap suong, giu khoa, chan ca nguoi khac */ }
    doWork();
}

Cách này vừa đốt CPU vừa tệ hơn: nó giữ khóa trong lúc quay, nên thread duy nhất có thể làm điều kiện thành đúng lại không vào được. Cơ chế đúng là wait/notify, gắn liền với intrinsic lock của mỗi object.

wait() làm ba việc nguyên tử với nhau: nhả khóa đang giữ, đưa thread vào trạng thái chờ, treo nó ở đó. Khi thread khác gọi notify()/notifyAll() trên cùng object, thread đang chờ được đánh thức, giành lại khóa, rồi chạy tiếp từ ngay sau wait. Nhả khóa khi chờ là điểm mấu chốt — nó cho thread khác cơ hội vào và thay đổi điều kiện. Cả ba wait/notify/notifyAll chỉ được gọi khi đang giữ khóa của chính object đó, nếu không ném IllegalMonitorStateException.

public class BookingQueue {
    private final Object lock = new Object();
    @GuardedBy("lock") private final Deque<Request> queue = new ArrayDeque<>();

    public void submit(Request r) {
        synchronized (lock) {
            queue.addLast(r);
            lock.notifyAll();                 // danh thuc worker dang cho
        }
    }

    public Request take() throws InterruptedException {
        synchronized (lock) {
            while (queue.isEmpty()) {         // while, KHONG phai if
                lock.wait();                  // nha khoa va cho; tinh day thi gianh lai
            }
            return queue.removeFirst();
        }
    }
}

Chữ ký take khai báo ném InterruptedException vì wait là blocking method: một thread treo vô hạn trong wait set cần đường thoát khi bị interrupt(), và đường đó là tỉnh dậy với InterruptedException — đúng cơ chế cooperative cancellation đã mổ ở bài Thread API và vòng đời.

sequenceDiagram
    participant A as Thread A (worker)
    participant M as Monitor cua lock
    participant B as Thread B (submitter)
    A->>M: giu lock, thay queue rong
    A->>M: wait() - nha lock, vao wait set
    Note over A: A treo, KHONG giu lock
    B->>M: gianh lock, addLast(request)
    B->>M: notifyAll() - A roi wait set, sang entry queue
    B->>M: roi khoi synchronized, nha lock
    M->>A: A tranh lai lock thanh cong
    A->>A: tinh day sau wait(), kiem lai dieu kien trong while

Chi tiết quan trọng nhất, cũng là lỗi kinh điển nhất: điều kiện phải kiểm trong vòng while, không bao giờ trong if. Hai lý do đều thật. Thứ nhất là spurious wakeup: đặc tả JVM cho phép một thread đang wait tỉnh dậy mà không ai notify — với if, thread chạy tiếp dù điều kiện chưa đúng; với while, nó kiểm lại, thấy vẫn sai, chờ tiếp. Thứ hai là quan sát đã cũ (stolen wakeup), còn phổ biến hơn — đừng nhầm với lost wakeup, tức khi notify xảy ra trước lúc thread kịp wait nên tín hiệu mất hẳn. Ở đây, giữa lúc một thread được đánh thức và lúc nó thực sự giành lại khóa, một thread thứ ba có thể chen vào làm điều kiện thành sai trở lại, ví dụ lấy mất phần tử nó định lấy. Vì giữa notify và lúc tỉnh dậy luôn có một quãng nhả-rồi-giành-lại khóa, trạng thái có thể đã đổi; while buộc kiểm lại sau khi đã cầm khóa nên không bao giờ hành động trên một quan sát đã cũ.

Còn lựa chọn notify với notifyAll. notify đánh thức một thread đang chờ (JVM chọn); notifyAll đánh thức tất cả để chúng cùng tranh khóa rồi tự kiểm điều kiện. notify rẻ hơn nhưng chỉ an toàn khi mọi thread chờ trên cùng object đều chờ đúng một điều kiện và đánh thức một thread là đủ. Nếu các thread chờ điều kiện khác nhau, notify có thể đánh thức nhầm một thread mà điều kiện chưa đúng — nó kiểm while rồi ngủ lại, còn thread thật sự nên chạy thì không bao giờ được gọi. Mặc định an toàn là notifyAll, chỉ hạ xuống notify khi đã chứng minh điều kiện đồng nhất.

Trong code thật hiếm khi nên tự viết wait/notify: java.util.concurrent từ Java 5 đã đóng gói các mẫu này thành building block đã kiểm chứng như BlockingQueue với put/take. Hiểu wait/notify vẫn cần để đọc được chúng từ bên trong.

3. Liên hệ các bài khác

• volatile & synchronized — synchronized là intrinsic lock mà cả Monitor Pattern lẫn wait/notify dựng lên trên; đọc trước bài này để hiểu cây cầu happens-before của khóa.
• Atomicity — race condition v0 của BookingService mà Monitor Pattern vá; nơi định nghĩa check-then-act và compound action.
• Thread API và vòng đời — wait ném InterruptedException; cơ chế interrupt và cooperative cancellation nằm ở đó.
• Blocking queues & producer-consumer — BlockingQueue của java.util.concurrent chính là guarded block wait/notify đã đóng gói sẵn, đúng-mọi-lần.
• Delegation & concurrent collections — kỹ thuật client-side locking dựa trên khóa public, và vì sao khóa private final của Monitor Pattern đóng lại cánh cửa đó.

4. Tóm tắt

• Java Monitor Pattern đóng gói state mutable sau một private final lock duy nhất, để mọi method chạm state đều giữ cùng khóa — bước v1 vá race condition của TicketFlow, và làm việc chứng minh an toàn thành cục bộ.
• Reader cũng phải khóa; book đã khóa có một linearization point nên không ai quan sát được trạng thái "ở giữa".
• Khóa trên private final Object thay vì this để đóng kín chính sách đồng bộ trong một file; khóa public mở cửa cho client-side locking mong manh.
• wait/notify mở rộng monitor để chờ một điều kiện: wait() nhả khóa rồi treo, notify/notifyAll đánh thức để giành lại khóa — rẻ hơn quay vòng bận vì không giữ khóa lúc chờ.
• Hai luật không được quên: luôn kiểm điều kiện trong vòng while (spurious + stolen wakeup), và mặc định notifyAll. Code thật nên dùng BlockingQueue thay vì tự viết.

5. Tự kiểm tra

Bài tiếp theo: Atomic & CAS — đồng bộ lock-free cho thao tác đơn