Cooperative cancellation — interrupt và InterruptedException

TL;DR: Java không có cách nào kill một thread từ bên ngoài một cách an toàn — Thread.stop() đã deprecated từ 1.2 và ném UnsupportedOperationException từ Java 20. Thay vào đó là cooperative cancellation: bên ngoài chỉ yêu cầu dừng, thread đích tự chọn điểm dừng an toàn. Cơ chế là interrupt status — một lá cờ mỗi thread. interrupt() chỉ set cờ, không dừng gì; thread CPU-bound phải tự check isInterrupted(), còn blocking method (sleep, join, take) khi bị interrupt sẽ ném InterruptedException và xóa cờ. Bắt được exception đó chỉ có hai cách hợp lệ: ném lại (throws), hoặc khôi phục cờ bằng Thread.currentThread().interrupt(). Catch rỗng làm tín hiệu hủy biến mất — thread pool gọi shutdown sẽ chờ mãi.

TicketFlow đang load sơ đồ ghế thì admin bấm shutdown — làm sao dừng thread seats-loader giữa chừng? Đây là câu hỏi mà mọi bài sau của module đều quay về mỗi khi chữ InterruptedException xuất hiện. Câu trả lời của Java không phải "kill nó đi", mà là một mô hình hợp tác tinh tế hơn — và pattern xử lý đúng chỉ hơn pattern sai đúng một dòng code, nhưng đó là khác biệt giữa shutdown trong 1 giây và phải kill -9.

1. Vì sao không thể kill một thread?

Câu trả lời của Java: không có cách nào kill một thread từ bên ngoài một cách an toàn. Method Thread.stop() bị deprecated từ Java 1.2, và từ Java 20 mọi lời gọi ném UnsupportedOperationException. Lý do khai tử: kill một thread tại một điểm tùy ý nghĩa là lock nó đang giữ bị nhả ra trong khi dữ liệu được lock bảo vệ đang sửa dở — invariant vỡ, mọi thread khác nhìn thấy trạng thái hỏng. Một thread bị stop giữa chừng book() có thể để lại số vé đã trừ nhưng booking chưa ghi.

Thay vào đó, Java chọn cooperative cancellation — hủy có hợp tác: bên ngoài chỉ yêu cầu dừng, còn thread đích tự quyết định đâu là điểm dừng an toàn (sau khi xong record hiện tại, sau khi nhả lock, sau khi đóng file). Một bên gửi tín hiệu, bên kia định kỳ kiểm tra và thoát có trật tự.

flowchart LR
    A["Thread khac goi<br/>t.interrupt()"] -->|"set co"| B["interrupt status = true"]
    B --> C{"Thread dich dang lam gi?"}
    C -->|"chay CPU-bound"| D["tu check isInterrupted()<br/>o diem dung an toan"]
    C -->|"block trong sleep/join/take"| E["method nem<br/>InterruptedException + xoa co"]
    D --> F["don dep -> ket thuc run() co trat tu"]
    E --> F

    style B fill:#FCD34D
    style F fill:#6EE7B7

2. interrupt() chỉ set một lá cờ

Mỗi thread mang một bit trạng thái gọi là interrupt status — lá cờ "có ai đó đã yêu cầu tôi dừng". Ba method xoay quanh nó:

Trước khi xem code, tự trả lời:

interrupt() không có quyền lực gì lên thread không thèm kiểm tra cờ. Một vòng lặp tính toán thuần chạy tiếp như chưa hề có cuộc gọi interrupt — cờ được set nhưng không ai đọc:

// Vong lap nay KHONG dung duoc bang interrupt() -- no khong bao gio nhin co
while (true) {
    crunchNumbers();
}

// Phien ban hop tac: kiem tra co moi vong lap
while (!Thread.currentThread().isInterrupted()) {
    crunchNumbers();
}
// thoat vong lap -> don dep -> ket thuc run() co trat tu

Với công việc CPU-bound, bạn phải tự cài điểm kiểm tra cờ ở chỗ dừng được an toàn. Tần suất là một trade-off: check dày thì phản hồi hủy nhanh, check thưa thì hủy trễ.

3. InterruptedException: khi blocking method nhìn cờ hộ bạn

Còn thread đang ngủ thì sao — đang sleep(), join(), hay take() trên blocking queue (bài 15)? Chúng không chạy vòng lặp nào để check cờ, nên blocking method của JDK làm hộ: thread đang block trong chúng mà bị interrupt thì method ném InterruptedException để nó tỉnh dậy ngay, đồng thời — chi tiết hay bị bỏ qua — xóa luôn interrupt status.

Vì sao là checked exception? Vì "bị yêu cầu hủy giữa chừng" không phải bug mà là tình huống bình thường mọi blocking method đều có thể gặp, và người gọi bắt buộc phải có chính sách đối phó. Checked exception ép bạn viết chính sách đó ra thành code — cách JDK nói: "method này biết chờ, nên nó cũng phải biết bị hủy."

Vì sao exception lại xóa cờ? Vì tín hiệu interrupt đã được giao tận tay bạn dưới dạng exception; cờ đã xong nhiệm vụ đưa tin. Từ đây quyền quyết định nằm ở code của bạn: kết thúc luôn, hoặc khôi phục lại cờ để tầng trên còn nhìn thấy tín hiệu. Nếu cờ không bị xóa, một vòng lặp có sleep sẽ ném InterruptedException mãi mãi ở mọi vòng sau dù bạn đã xử lý xong.

4. Pattern xử lý đúng — và pitfall nuốt interrupt

Quy tắc chỉ có hai nhánh, tùy vị trí của bạn trong call stack.

Nhánh 1 — lan truyền: method không đủ thẩm quyền quyết định "hủy thì làm gì" (code thư viện, code tầng giữa) thì khai báo throws InterruptedException, để exception đi lên:

// Tang giua: khong tu quyet -- day trach nhiem len caller
public SeatMap loadSeatMaps() throws InterruptedException {
    return seatMapQueue.take();   // co the block, co the bi interrupt
}

Nhánh 2 — khôi phục cờ: nếu không thể throw (đang trong Runnable.run(), trong vòng lặp worker), xử lý tại chỗ rồi dựng lại lá cờ vừa bị xóa. Thử tự điền dòng còn thiếu trước khi xem đáp án:

public void run() {
    while (!Thread.currentThread().isInterrupted()) {
        try {
            SeatMap map = seatMapQueue.take();
            process(map);
        } catch (InterruptedException e) {
            /* ... buoc khoi phuc tin hieu huy ... */
        }
    }
    closeResources();   // diem thoat co trat tu
}

Dòng cần điền là Thread.currentThread().interrupt() — gọi interrupt() lên chính thread hiện tại để dựng lại lá cờ vừa bị blocking method xóa. Nhờ đó vòng lặp while kế tiếp thấy isInterrupted() trả true và thoát có trật tự:

} catch (InterruptedException e) {
    Thread.currentThread().interrupt();   // restore flag -> vong while thay co va thoat
}

Pitfall phổ biến nhất toàn bộ Java concurrency là nuốt interrupt bằng catch rỗng:

// SAI -- nuot tin hieu huy: co da bi xoa, khong restore, khong throw
try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    // bo trong "cho het warning"
}

Sau catch rỗng, tín hiệu hủy biến mất khỏi vũ trụ: cờ đã bị xóa khi exception ném ra, bạn không khôi phục, không ai phía trên còn cách nào biết từng có yêu cầu dừng — thread pool gọi shutdown sẽ chờ mãi mãi. Bản đúng chỉ hơn đúng một dòng Thread.currentThread().interrupt(), nhưng đó là khác biệt giữa hệ thống shutdown được trong 1 giây và hệ thống phải kill -9.

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

• Bài 02 — Thread API và vòng đời: nền trực tiếp — sleep()/join() là các blocking method mà bài này dạy cách hủy; trạng thái TIMED_WAITING/WAITING là lúc interrupt phát huy tác dụng.
• Bài 15 — Blocking queue: take() ném InterruptedException — consumer loop dùng đúng pattern khôi phục cờ của bài này.
• Bài 17b — Vận hành pool production: shutdownNow() hủy worker bằng interrupt; nuốt InterruptedException trong task là lý do pool không bao giờ dừng.
• Bài 22 — Structured concurrency: nâng interrupt + join thủ công của bài này thành mô hình scope có cấu trúc, tự truyền hủy xuống task con.

6. 📚 Deep Dive

7. Tóm tắt

• Java không kill thread: Thread.stop() deprecated từ 1.2, ném UnsupportedOperationException từ Java 20 — kill tại điểm tùy ý làm vỡ invariant đang sửa dở.
• Cooperative cancellation: bên ngoài yêu cầu dừng, thread đích tự chọn điểm dừng an toàn.
• interrupt() chỉ set interrupt status; isInterrupted() đọc không xóa; Thread.interrupted() đọc và xóa cờ của thread hiện tại.
• Vòng lặp CPU-bound phải tự check isInterrupted() — interrupt vô tác dụng với thread không nhìn cờ.
• Blocking method (sleep, join, wait, take...) phản ứng với interrupt bằng cách ném InterruptedException và xóa cờ.
• InterruptedException là checked exception vì hủy là tình huống bình thường mà caller bắt buộc phải có chính sách.
• Xử lý InterruptedException chỉ có hai nhánh hợp lệ: rethrow, hoặc khôi phục cờ bằng Thread.currentThread().interrupt(). Không bao giờ catch rỗng.

8. Tự kiểm tra

Bài tiếp theo: Thread safety — khi nhiều thread cùng chạm vào dữ liệu