Mô hình ánh xạ thread — user, kernel và platform thread

TL;DR: Thread được hỗ trợ ở hai cấp: user thread (quản lý ở user space bởi thư viện) và kernel thread (do hệ điều hành lập lịch trực tiếp). User thread ánh xạ xuống kernel thread theo ba mô hình: many-to-one (nhiều user thread dùng chung một kernel thread — rẻ nhưng không chạy song song và một blocking call chặn cả process), one-to-one (mỗi user thread một kernel thread — song song thật nhưng thread đắt), và many-to-many (multiplex, cân bằng hai phía). Java platform thread theo one-to-one nên mỗi thread là một OS thread — không hề rẻ; đó là lý do tồn tại thread pool và virtual thread (gần với many-to-many).

Bài 01 — Process và Thread đã trả lời thread là gì và vì sao nó nhẹ hơn process. Nhưng "nhẹ" tới đâu còn tuỳ một chi tiết chưa mở: một thread ở tầng ngôn ngữ thực sự ánh xạ xuống đâu trong hệ điều hành? Câu trả lời quyết định thread rẻ hay đắt, và chạy được song song hay không.

1. User thread và kernel thread

Thread được hỗ trợ ở hai cấp độ. User thread quản lý ở user space, thường bởi một thread library; kernel có thể không biết đến từng user thread. Kernel thread do hệ điều hành quản lý trực tiếp, scheduler của OS lập lịch thẳng cho chúng. Hầu hết hệ điều hành hiện đại — Windows, Linux, macOS — đều hỗ trợ kernel thread.

Câu hỏi quan trọng: user thread ánh xạ xuống kernel thread như thế nào? Ba mô hình phổ biến là many-to-one, one-to-one và many-to-many — chúng giải thích vì sao runtime như JVM phải cân bằng giữa "thread rẻ" và "thread chạy được song song".

2. Ba mô hình ánh xạ user thread lên kernel thread

Hàng trên trong sơ đồ là user thread (user space), hàng dưới là kernel thread (kernel space). Chú ý số kernel thread ở đáy mỗi mô hình: đó là số "ghế" thực sự mà OS scheduler nhìn thấy.

flowchart TB
  subgraph M1["Many-to-one (M:1)"]
    direction TB
    A1["User thread 1"] --> AK1["Kernel thread"]
    A2["User thread 2"] --> AK1
    A3["User thread 3"] --> AK1
  end
  subgraph O1["One-to-one (1:1)"]
    direction TB
    B1["User thread 1"] --> BK1["Kernel thread 1"]
    B2["User thread 2"] --> BK2["Kernel thread 2"]
    B3["User thread 3"] --> BK3["Kernel thread 3"]
  end
  subgraph MN["Many-to-many (M:N)"]
    direction TB
    C1["User thread 1"] --> CK1["Kernel thread 1"]
    C2["User thread 2"] --> CK1
    C3["User thread 3"] --> CK2["Kernel thread 2"]
    C4["User thread 4"] --> CK2
  end
  style AK1 fill:#FCD34D
  style BK1 fill:#6EE7B7
  style BK2 fill:#6EE7B7
  style BK3 fill:#6EE7B7
  style CK1 fill:#C4B5FD
  style CK2 fill:#C4B5FD

2.1 Many-to-one

Nhiều user-level thread ánh xạ vào một kernel thread duy nhất. Ưu điểm: quản lý thread rất nhanh, vì phần lớn thao tác nằm ở user space, không cần kernel can thiệp. Nhược điểm rất lớn: một thread gọi blocking system call thì cả process bị block — kernel chỉ thấy một kernel thread, không biết còn user thread khác muốn chạy; và vì chỉ có một kernel thread, các user thread không thể chạy song song trên nhiều core. Java đời đầu từng dùng mô hình tương tự qua Green Threads, nay ít dùng vì không khai thác được multicore.

2.2 One-to-one

Mỗi user thread ánh xạ tới một kernel thread. Concurrency tốt hơn many-to-one: một thread bị block vì system call thì các thread khác vẫn chạy, và nhiều thread chạy song song được trên multicore. Nhược điểm: mỗi user thread cần một kernel thread, nên tạo quá nhiều thread thì hệ thống chịu chi phí lớn về bộ nhớ, scheduling và context switching.

2.3 Many-to-many và two-level

Nhiều user-level thread được multiplex lên một số kernel thread nhỏ hơn hoặc bằng, kết hợp ưu điểm của hai mô hình trước: developer tạo nhiều user thread, runtime ánh xạ chúng xuống số kernel thread phù hợp. Một thread bị block thì kernel vẫn schedule kernel thread khác, mà hệ thống vẫn chạy song song được trên nhiều core.

Đổi lại, many-to-many khó triển khai hơn (một scheduler hai tầng); khi số core tăng và chi phí kernel thread thành chấp nhận được, hầu hết hệ điều hành hiện đại nghiêng về one-to-one. Một biến thể là mô hình two-level: user thread vẫn multiplex lên nhiều kernel thread, nhưng một user thread cụ thể có thể bind trực tiếp vào một kernel thread.

3. Vì sao platform thread của Java không hề rẻ?

JVM không "giả lập" việc lập lịch thread tách biệt khỏi hệ điều hành. Với platform thread truyền thống, Java thread ánh xạ xuống native thread của OS theo đúng mô hình one-to-one — tạo một platform thread tức là tạo hoặc dùng một kernel thread tương ứng.

Nhờ đó Java thread tận dụng được parallelism trên multicore, nhưng cũng vì thế thread không hề miễn phí. Tạo quá nhiều platform thread gây ra:

• Tốn bộ nhớ cho stack của mỗi thread.
• Tăng chi phí context switching.
• Gây áp lực lên scheduler của hệ điều hành.
• Làm ứng dụng khó kiểm soát khi số request tăng cao.

Tạo platform thread trực tiếp:

Thread worker = new Thread(() -> {
    System.out.println("Run in platform thread");
});
worker.start();

Đơn giản, nhưng mỗi request lại tạo một thread mới không kiểm soát thì hệ thống nhanh chóng cạn tài nguyên lúc tải cao. Có hai hướng giải quyết, mỗi hướng có bài riêng:

• Thread pool / ExecutorService tách mô tả task khỏi quản lý thread: tái sử dụng một số cố định platform thread, nên kiểm soát được số lượng thread và giảm chi phí tạo/hủy. Chi tiết ở bài 17 — Executor và thread pool.
• Virtual thread phá quan hệ one-to-one: JVM multiplex rất nhiều virtual thread lên một nhúm nhỏ platform thread (gọi là carrier thread), nên tạo hàng loạt thread cho tác vụ blocking I/O mà không trả chi phí của chừng đó OS thread — đưa Java về gần mô hình many-to-many. Chi tiết ở bài 20 — Virtual threads.

Điểm cần nhớ: trần chi phí của platform thread đến thẳng từ mô hình one-to-one — đó là động lực chung cho cả hai hướng trên.

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

• Process và Thread — nền tảng: thread là gì, chia sẻ heap và giữ riêng stack; bài này xây tiếp trên đó để trả lời thread ánh xạ xuống OS ra sao.
• Executor và thread pool — hướng thứ nhất để thuần hoá chi phí platform thread: tái dùng thread qua pool thay vì tạo mới mỗi task.
• Virtual threads — hướng thứ hai: mô hình many-to-many nhắc ở mục 3 được khai triển đầy đủ, vì sao virtual thread cho phép hàng triệu Java thread trên một nhúm carrier thread.

5. 📚 Deep Dive

6. Tóm tắt

• Thread có hai cấp: user thread (user space) và kernel thread (do OS lập lịch). Cách chúng ánh xạ với nhau quyết định thread rẻ hay chạy được song song.
• Ba mô hình: many-to-one (rẻ, nhưng một blocking call chặn cả process và không dùng được multicore), one-to-one (song song thật, thread đắt), many-to-many (multiplex, cân bằng — nhưng phức tạp).
• Đa số OS hiện đại chọn one-to-one vì đơn giản và kernel thread đã đủ rẻ; many-to-many chủ yếu sống lại ở tầng runtime (virtual thread).
• Java platform thread theo one-to-one nên mỗi thread là một OS thread — không rẻ. Thread pool tái dùng thread; virtual thread bỏ quan hệ one-to-one, multiplex lên carrier thread (gần many-to-many).

7. Tự kiểm tra

Bài tiếp theo: Thread API và vòng đời — start, join, interrupt