Thực hành đa luồng tốt nhất: bản Java — quy ước thời đại virtual thread

«Chúng tôi muốn song song hóa một việc batch nghiệp vụ bằng Java.» «Bộ nhớ đệm dùng chung trong ứng dụng web Spring thỉnh thoảng bị hỏng.» «Chúng tôi thừa kế một ứng dụng Swing cũ đầy new Thread.» — Java đã gắn đa luồng vào ngôn ngữ từ JDK 1.0, trưởng thành thành hộp công cụ java.util.concurrent, và với virtual thread ở JDK 21 đã viết lại một lần nữa sự hiểu biết thông thường của lập trình đồng thời. Chính vì bộ công cụ phong phú đến thế, công cụ bạn chọn trở thành chất lượng thiết kế.

Bài viết này là bản Java của loạt đa luồng trong thực tế. Dành cho nhà phát triển viết hệ thống nghiệp vụ, việc batch và ứng dụng máy chủ bằng Java, nó ánh xạ các nguyên tắc thiết kế đa luồng — đừng bao giờ tạo thread trực tiếp, giảm trạng thái dùng chung có thể đổi, kỷ luật khóa, thiết kế cách dừng trước mọi thứ khác — lên công cụ của Java (nhắm chủ yếu bản LTS, JDK 21 trở lên), và gom các lựa chọn thời đại virtual thread cùng các bẫy riêng của Java, dựa trên nguồn sơ cấp tính đến tháng 8 năm 2026. Được viết để đọc độc lập. Cùng nguyên tắc áp dụng cho ngôn ngữ khác nằm ở các bài đồng hành «bản .NET», «bản C++» và «bản C».

1. Kết luận trước

• Đừng viết new Thread trong mã nghiệp vụ — cùng quy tắc đó áp dụng ở Java. Giao tác vụ cho ExecutorService và để thư viện quản lý vòng đời thread.¹
• Đưa tác vụ chủ yếu chờ I/O sang virtual thread. Virtual thread, chính thức từ JDK 21, dùng một cái mỗi tác vụ và không bao giờ được gom vào pool. Giới hạn đồng thời bằng Semaphore, không bằng kích thước pool.²³
• Virtual thread là công cụ thông lượng, không phải công cụ làm tính toán nhanh hơn. Song song hóa CPU-bound vẫn là việc của thread nền tảng cỡ khoảng số lõi — pool cố định hoặc parallel stream, như trước.³
• Khóa trên đối tượng khóa private final, hoặc ReentrantLock riêng. synchronized(this) và khóa trên đối tượng phơi ra công khai có thể đụng mã ngoài. Nếu cần chiếm có thời hạn (tryLock), dùng ReentrantLock.
• JDK 21-23 có vấn đề chặn trong khối synchronized ghim virtual thread; JDK 24 (JEP 491) đã sửa. Phân biệt cảnh báo cũ với thực tế hiện nay.³⁴
• volatile bảo đảm tầm nhìn và thứ tự, không phải tính nguyên tử. Dùng AtomicInteger / LongAdder cho bộ đếm, và khóa cho trạng thái ghép.⁵
• Dừng hợp tác qua interruption là cách đúng duy nhất để dừng thread. Thread.stop / suspend / resume giờ ném UnsupportedOperationException. Đừng nuốt InterruptedException — khôi phục trạng thái hoặc ném lại.⁶
• Dừng ExecutorService bằng mẫu hai giai đoạn: shutdown → awaitTermination → shutdownNow. shutdownNow là best-effort (cài đặt chuẩn làm việc qua interruption), nên giả định tác vụ của bạn đáp interruption.¹
• UI của Swing thuộc riêng EDT (Event Dispatch Thread). Yêu cầu cập nhật từ thread khác qua SwingUtilities.invokeLater.⁷

2. Vì sao đa luồng khó — điều kiện đua, khóa chết, và mô hình bộ nhớ

Đun các vấn đề đa luồng đưa vào, bất kể ngôn ngữ, còn hai loại.

Điều kiện đua là lỗi mà kết quả phụ thuộc thứ tự nhiều thread tới một đoạn mã. Ví dụ cổ điển là bộ đếm dùng chung: biểu thức đơn count++ thực ra tách thành ba bước — đọc, cộng, ghi lại. Nếu hai thread vào ba bước này cùng lúc, lần tăng của một thread bị ghi đè và mất khi thread kia ghi lại. Kết quả đổi mỗi lần chạy, và không cách nào đoán được kết quả nào.

sequenceDiagram
    participant A as Thread A
    participant M as Biến dùng chung count
    participant B as Thread B
    Note over M: count = 10
    A->>M: Đọc (10)
    B->>M: Đọc (10)
    A->>A: Cộng cục bộ (11)
    B->>B: Cộng cục bộ (11)
    A->>M: Ghi lại (11)
    B->>M: Ghi lại (11)
    Note over M: Hai lần tăng đã xảy ra,<br/>nhưng count = 11 — lần tăng của Thread A bị mất

Hình 1: Điều kiện đua cổ điển trong đó lần tăng trên bộ đếm dùng chung bị mất. Nếu thread khác xen vào ba bước của count++, lần ghi lại sau cùng ghi đè lần kia

Khóa chết là trạng thái hai thread mỗi bên chờ khóa bên kia đang giữ, nên không ai tiến được. Thread A giữ khóa 1 và chờ khóa 2; thread B giữ khóa 2 và chờ khóa 1 — chỉ vậy đủ để cả hai dừng mãi mãi.

flowchart LR
    A["Thread A<br/>đang giữ khóa 1"] -->|"chờ giải phóng khóa 2"| B["Thread B<br/>đang giữ khóa 2"]
    B -->|"chờ giải phóng khóa 1"| A

Hình 2: Chờ vòng của khóa chết. Khoảnh khắc các mũi tên chờ tạo vòng, mọi thread trong vòng đó dừng mãi mãi

Cả hai phụ thuộc thời điểm. Một sự xen kẽ chỉ hiện một lần trong hàng chục nghìn lần chạy trên máy phát triển có thể xảy ra mỗi ngày trên máy chủ sản xuất với số lõi và tải khác. «Ngừng tái hiện khi gắn trình gỡ lỗi» và «biến mất khi thêm ghi nhật ký» đều vì quan sát đổi thời điểm — hành vi cổ điển của lỗi đua. Đó chính là lý do mọi nguyên tắc trong bài này chỉ về hướng giảm chỗ cần đồng bộ, trước khi lo đồng bộ cho đúng.

2.1. Tiền đề riêng của Java — mô hình bộ nhớ và happens-before

Trên đó, điều riêng của Java là cách dữ liệu dùng chung được nhìn được định nghĩa bởi quan hệ happens-before trong Java Memory Model (JMM).

Đọc và ghi biến dùng chung không đồng bộ không trở thành «hành vi không xác định» kiểu C++, nhưng có thể hợp pháp dẫn tới giá trị cũ tiếp tục được thấy, hoặc các lần ghi xuất hiện lệch thứ tự. Lỗi nhất quán bộ nhớ mà «một vòng đang nhìn cờ boolean, nhưng giá trị thread khác đổi không bao giờ hiện» là hành vi JMM cho phép, không phải lỗi JVM.⁵ Công cụ chống điều này là các cơ chế tạo happens-before — synchronized, volatile, và các lớp trong java.util.concurrent. Dùng bộ sưu tập đồng thời đúng thì thư viện bảo đảm «quan hệ happens-before giữa thao tác cập nhật và lần lấy sau».⁸

Nói cách khác, hướng dẫn thực tế của Java có thể gói lại thế này: đừng khôn với biến dùng chung thô. Dùng công cụ trong java.util.concurrent để chia sẻ, và để thư viện tạo happens-before.

3. Cách tạo thread — ExecutorService và virtual thread

3.1. Tách tác vụ khỏi cách chạy

ExecutorService là thứ mang nguyên tắc «đừng tự tạo thread» ở Java. Nó tách việc (Runnable / Callable) khỏi cách thực thi — bao nhiêu thread, hàng đợi nào — và để việc tạo, tái sử dụng, hủy thread cho thư viện.¹

Từ JDK 21 trở đi, chọn cách chạy trở thành lựa chọn nhị phân đơn giản.²³

flowchart TB
    S["Tác vụ muốn chạy đồng thời"] --> Q1{"Điều gì dẫn dắt tác vụ?"}
    Q1 -->|"Chủ yếu chờ I/O<br/>gọi HTTP, DB, tệp"| VT["Virtual thread<br/>Executors.newVirtualThreadPerTaskExecutor<br/>một cái mỗi tác vụ, không bao giờ gom pool"]
    Q1 -->|"Tính toán CPU-bound"| PT["Pool cố định thread nền tảng<br/>Executors.newFixedThreadPool - khoảng bằng số lõi<br/>hoặc parallel stream"]
    VT --> LIMIT["Giới hạn đồng thời tới dịch vụ ngoài<br/>bằng Semaphore, không bằng kích thước pool"]

Hình 3: Chọn cách thực thi việc từ JDK 21. Kẻ đường trước — «đổi cách chờ I/O, song song hóa cho CPU» — rồi giao việc I/O-bound cho virtual thread và việc CPU-bound cho pool thông thường

Có một lưu ý phía CPU-bound. Executors.newFixedThreadPool giới hạn số thread, nhưng hàng đợi của nó không giới hạn. Trong dịch vụ sống lâu mà việc gửi luôn vượt xử lý, chỉ thread bị giới hạn bằng số lõi — tác vụ chất trong hàng đợi, và dữ liệu của chúng, tiếp tục ăn bộ nhớ. Ở kiểu bố trí đó, hoặc dùng ThreadPoolExecutor trực tiếp để cấu hình hàng đợi có biên cộng chính sách từ chối, hoặc đặt kiểm soát nhận vào như Semaphore phía gửi để có thể tạo áp lực ngược (cùng nguyên tắc với thảo luận hàng đợi ở mục 4).

3.2. Đừng dùng sai virtual thread

Virtual thread là thread nhẹ tách khỏi thread OS: trong thao tác chặn của JDK (I/O, khóa, ngủ và tương tự trong thư viện chuẩn) chúng nhả thread OS, vì thế một JVM có thể chạy hàng triệu. Tuy vậy, chúng không nhả cho mọi kiểu chặn. Nếu virtual thread chặn khi chạy mã gốc (JNI) hoặc hàm ngoài, nó vẫn bị ghim vào thread mang. Điều JDK 24 (JEP 491, dưới đây) sửa là việc ghim do synchronized; việc ghim ở biên gốc vẫn còn, nên chất số lớn virtual thread bằng thao tác chặn lâu qua trình điều khiển JNI hoặc API thiết bị sẽ cạn thread mang. Nhưng như hướng dẫn chính thức nhấn mạnh, chúng không phải «thread nhanh hơn». Tốc độ thực thi mã không đổi — thứ chúng cung cấp là quy mô (thông lượng).³

Có ba kỷ luật khi dùng.³

1. Đừng gom vào pool. Virtual thread rẻ và dùng một lần; «số tác vụ = số virtual thread» là trạng thái đúng. Đưa virtual thread vào newFixedThreadPool là sai — dùng dạng try (var executor = Executors.newVirtualThreadPerTaskExecutor()).
2. Giới hạn đồng thời bằng Semaphore. Diễn đạt ràng buộc như «nhiều nhất 10 kết nối đồng thời tới API ngoài» bằng semaphore, không bằng kích thước pool.
3. Đừng dùng cho việc CPU-bound. Thread nền tảng cỡ khoảng số lõi vẫn là công cụ đúng để song song hóa tính toán, như trước.

Lưu ý rằng thứ chạy trong virtual thread là mã đồng bộ thông thường. Thay vì viết lại mã như async/await của .NET, triết lý thiết kế sau virtual thread là cho bạn chạy mã thẳng «một thread mỗi yêu cầu», không đổi, ở quy mô khổng lồ.²

3.3. Hiểu lầm thường gặp — «không cần pool» chỉ áp dụng cho virtual thread

Đừng đọc kỷ luật «đừng gom vào pool» thành «Java không có pool thread (hoặc nó kém hiệu quả)». Thực tế ngược lại: pool của Java là phần chín của thư viện chuẩn từ JDK 5 (2004). Pool đa năng cấu hình tinh ThreadPoolExecutor (tạo qua các nhà máy Executors), ForkJoinPool ăn cắp việc (thể hiện chung commonPool() là đích thực thi mặc định của parallel stream và CompletableFuture), và ScheduledThreadPoolExecutor cho chạy định kỳ — những thứ này vẫn là nhân vật chính cho việc CPU-bound.

Pool về bản chất là tối ưu dựa trên «tạo và giữ thread OS đắt, nên dùng lại». Virtual thread xóa tiền đề này bằng cách đưa chi phí tạo gần không, nên không còn lý do dùng lại — hiểu chính xác không phải pool trở nên kém hiệu quả, mà thread đã nhẹ đủ để tối ưu pool không cần thiết. Và dưới virtual thread, bộ lập lịch JDK chạy một tập thread mang (thread OS) số lượng khoảng số lõi, như ForkJoinPool ăn cắp việc.² Nói cách khác, hình «xử lý khối lượng việc đồng thời khổng lồ bằng pool nhỏ thread OS» được giữ; chỉ việc quản lý pool đó chuyển từ tay nhà phát triển sang JVM. Công bằng mà nói Java tới cùng đích với async/await của .NET, thứ trả thread về pool tại điểm await, mà không đổi hình mã.

4. Giảm trạng thái dùng chung có thể đổi — phân vùng, bất biến, bộ sưu tập đồng thời, và hàng đợi

Tranh chấp chỉ sinh khi có cả «nhiều thread» và «dữ liệu dùng chung có thể đổi». Số thread do yêu cầu quyết định, nên thứ thiết kế cắt được là phần dùng chung. Có ba họ kỹ thuật — phân vùng, làm bất biến, và chuyển dữ liệu — và đây là cách viết chúng bằng Java.

Phân vùng. Với tổng hợp song song, thay vì mỗi thread ghi vào biến tổng dùng chung, để mỗi thread dựng kết quả bộ phận rồi gộp cuối. reduce / collect của parallel stream cung cấp đúng hình này như khung, và LongAdder nói dưới đây cũng là cài đặt chiến lược phân vùng — nội bộ tách thành ô để trải tranh chấp, và cộng khi đọc. Giảm tần suất ghi vào trạng thái dùng chung đến trước khi viết đồng bộ cho đúng.

Làm bất biến. Dựng dữ liệu bằng record và bộ sưu tập bất biến (List.copyOf / Map.copyOf) không bao giờ được viết lại sau khi tạo, rồi chia sẻ được mà không đồng bộ. Với cấu hình và dữ liệu gốc, mẫu chuẩn: khi cần thay, dựng đối tượng mới và đổi tham chiếu volatile. Tuy nhiên «trông chỉ đọc» và «là bất biến» là hai việc khác. Bộ truy cập của record trả tham chiếu thô của thành phần, và bản sao của List.copyOf cũng nông (không nhân đôi đối tượng phần tử), nên nếu phần tử có thể đổi, ai giữ bí danh cũng viết lại nội dung được, và tranh chấp còn. An toàn chia sẻ không đồng bộ chỉ khi toàn đồ thị đối tượng — kể cả phần tử — là bất biến. Nếu có phần tử có thể đổi, hoặc đưa bản sao sâu hoặc đẩy phần tử về record / kiểu bất biến luôn.

Dùng thao tác ghép trên bộ sưu tập đồng thời. Với mẫu «tạo nếu thiếu, rồi chèn» của ConcurrentHashMap, dùng computeIfAbsent. Phương thức này thực thi cả lần gọi một cách nguyên tử, và nếu khóa vắng, hàm ánh xạ được gọi đúng một lần trong lần gọi đó.⁸ Bảo đảm khác ConcurrentDictionary.GetOrAdd của .NET (nhà máy có thể chạy hơn một lần dưới tranh chấp) — điểm người chuyển giữa hai ngôn ngữ dễ lẫn. Tuy nhiên không phải «đúng một lần suốt đời khóa». Nếu hàm trả null hoặc ném, không có ánh xạ được đăng ký, và hàm chạy lại ở lần gọi sau (cũng vậy nếu mục bị xóa sau đăng ký). Nếu khởi tạo không chịu được tác dụng phụ trùng, thiết kế để hàm thành công và trả khác null. Giá của việc nguyên tử là một số cập nhật từ thread khác bị chặn trong lúc tính, nên giữ hàm ánh xạ ngắn, và đừng bao giờ cập nhật cùng bản đồ từ trong hàm (cập nhật đệ quy bị phát hiện có thể ném IllegalStateException).⁸

// Mẫu chuẩn của bộ đếm tần suất: computeIfAbsent + LongAdder
ConcurrentHashMap<String, LongAdder> freqs = new ConcurrentHashMap<>();
freqs.computeIfAbsent(key, k -> new LongAdder()).increment();

Chuyển dữ liệu qua hàng đợi. Đưa dòng dữ liệu giữa các thread qua BlockingQueue. Với ArrayBlockingQueue được cho dung lượng, put chặn khi đầy, tạo áp lực ngược tự nhiên — cùng hình với kênh có biên của bản .NET. Ngay cả thời đại virtual thread, thiết kế kẻ ranh rõ giữa nhà sản xuất và người tiêu thụ vẫn hiệu quả.

5. Kỷ luật khóa — synchronized và ReentrantLock

5.1. Khóa trên gì, và đừng làm gì khi đang giữ khóa

Nghĩ đơn vị khóa không phải «đoạn mã» mà là «dữ liệu». Ánh xạ một đối tượng khóa cho mỗi tập dữ liệu có thể đổi muốn bảo vệ, và lấy cùng khóa đó tại mọi chỗ chạm dữ liệu đó — thực tế lỗi đua thường là ánh xạ này đã vỡ ở đâu đó. Tránh synchronized(this) và synchronized(SomeClass.class), vì mã ngoài có thể khóa cùng đối tượng; thay vào đó, ghép dữ liệu muốn bảo vệ một-một với private final Object lock = new Object(); không bao giờ phơi ra ngoài.

Hai kỷ luật nữa trên đó. Thứ nhất, đừng làm gì chậm, hay gì chạm thế giới ngoài, khi đang giữ khóa. I/O, gọi listener, hoặc chạy mã không biết trong khi vẫn giữ khóa vừa kéo dài thời gian giữ vừa rủi ro bên được gọi cố lấy khóa khác, tạo chờ vòng từ hình 2. Thứ hai, cố định thứ tự chiếm nhiều khóa. Nơi lấy hai khóa trở lên, đặt quy tắc mọi thread lấy cùng thứ tự, và với chỗ không bảo đảm thứ tự được, chuẩn bị đường «bỏ và thử lại nếu không được» bằng tryLock(timeout) nói dưới đây.

synchronized đủ cho «loại trừ ngắn và đơn giản». Chuyển sang ReentrantLock khi cần những điều sau.

• Chiếm có thời hạn qua tryLock(timeout) (đổi treo vĩnh viễn thành thất bại có thể ghi nhật ký và xử lý)
• Chính sách công bằng, nhiều Condition, hoặc khi muốn tách chiếm và nhả khóa sang phương thức khác

Khi dùng ReentrantLock, đừng phá mẫu try ngay sau lock() và unlock() trong khối finally (Java không có tương đương RAII của C++, nên mẫu này là toàn bộ kỷ luật).

5.2. Virtual thread và việc ghim — điều đổi ở JDK 24

Khi virtual thread mới được đưa vào (JDK 21-23), có ràng buộc chặn trong khối synchronized ghim virtual thread vào thread OS (không nhả thread OS được, mất lợi ích quy mô), và người ta khuyên thay chỗ chặn thường xuyên hoặc lâu bằng ReentrantLock.³ Ràng buộc đó được gỡ khi JEP 491 của JDK 24 viết lại cài đặt monitor, và synchronized không còn ghim virtual thread.⁴ Nếu bạn ở JDK 24 trở lên, thay synchronized máy móc như biện pháp chống ghim không còn cần. Đáng kiểm xem hướng dẫn cũ hơn của tổ chức còn kẹt ở cảnh báo thời JDK 21 không.

5.3. Nguyên tử và volatile nằm đâu

Cập nhật nguyên tử một biến do AtomicInteger / AtomicLong / AtomicReference đảm nhận (hoặc, với thống kê chỉ tăng ở tần suất cao, LongAdder chống tranh chấp). volatile bảo đảm tầm nhìn và thứ tự (happens-before), không phải tính nguyên tử của thao tác ghép.⁵ Cùng kết luận với bản .NET và C++ cũng đứng ở Java: dùng nguyên tử cho cờ và giá trị đơn, khóa cho trạng thái ghép, và đừng cố để volatile làm một mình.

6. Thiết kế cách dừng — interruption như ngôn ngữ chung

6.1. Phép tắc của interrupt

Dừng và hủy ở Java thống nhất quanh interruption. t.interrupt() đặt trạng thái interrupt của thread đích, và nếu đích bị chặn trong sleep / wait / join hoặc tương tự, nó ném InterruptedException để đánh thức ngay (lúc đó trạng thái interrupt bị xóa).⁶ Thread.stop / suspend / resume, cơ chế cưỡng bức của quá khứ, về bản chất không an toàn, nên gọi chúng giờ ra UnsupportedOperationException.⁶

flowchart TB
    OWNER["Người gọi dừng nó - gọi t.interrupt"] --> ST["Trạng thái interrupt được đặt"]
    ST --> A["Thread đang tính:<br/>thăm dò Thread.interrupted trong vòng"]
    ST --> B["Bị chặn trong sleep / wait / join:<br/>InterruptedException chạy và đánh thức ngay<br/>trạng thái bị xóa"]
    A --> E["Dọn và tự kết thúc"]
    B --> C{"Catch làm gì?"}
    C -->|"Tự kết thúc được"| E
    C -->|"Không kết thúc được - ví dụ trong thư viện"| R["Thread.currentThread.interrupt<br/>khôi phục trạng thái và để lại tín hiệu"]
    R --> E

Hình 4: Dừng hợp tác qua interruption. Nuốt InterruptedException làm tín hiệu dừng biến mất — một khi bắt, lựa chọn là «kết thúc» hoặc «khôi phục»

Chỉ một kỷ luật cần nhớ trong thực tế: đừng viết mã bắt InterruptedException rồi không làm gì. Nếu kết thúc được trong trách nhiệm của mình, kết thúc ở đó; nếu không, khôi phục trạng thái bằng Thread.currentThread().interrupt() và chuyển tín hiệu cho người gọi (xem FAQ).

6.2. Tắt hai giai đoạn của ExecutorService

API tắt của ExecutorService ngồi trên mô hình interruption. shutdown() ngừng nhận tác vụ mới và để tác vụ đã gửi chạy đến hoàn tất; shutdownNow() cố dừng tác vụ đang chạy. Như đặc tả giao diện đây là best-effort, và được ghi rõ rằng cài đặt chuẩn (như ThreadPoolExecutor) thường hủy qua Thread.interrupt() — nghĩa là tác vụ không đáp interruption sẽ không dừng ngay cả với shutdownNow, và nếu dùng cài đặt Executor tùy chỉnh, cần xem tài liệu nó hủy thế nào (có gửi interrupt không).¹ Mẫu dừng chuẩn tài liệu chính thức chỉ là mẫu hai giai đoạn sau.¹

/** Đúng khi tắt xong. Đừng tiến tới giải phóng tài nguyên dùng chung khi còn sai. */
boolean shutdownAndAwaitTermination(ExecutorService pool) {
    pool.shutdown();                    // Giai đoạn 1: ngừng nhận tác vụ mới và chờ hoàn tất
    try {
        if (!pool.awaitTermination(60, TimeUnit.SECONDS)) {
            // Giai đoạn 2: yêu cầu hủy. Tác vụ bị hạ trước khi chạy
            // được trả về, nên đánh dấu Future của chúng đã hủy để đánh thức người gọi bị chặn ở get()
            pool.shutdownNow().forEach(r -> {
                if (r instanceof Future<?> f) f.cancel(false);
            });
            if (!pool.awaitTermination(60, TimeUnit.SECONDS)) {
                System.err.println("Pool did not terminate");
                return false;           // Tắt chưa xong. Báo ở dạng phân biệt được với thành công
            }
        }
        return true;
    } catch (InterruptedException ex) {
        pool.shutdownNow().forEach(r -> {
            if (r instanceof Future<?> f) f.cancel(false);
        });
        Thread.currentThread().interrupt();   // Khôi phục cả trạng thái interrupt của thread này
        return false;                   // Đường này cũng có thể để tắt chưa hoàn tất
    }
}

flowchart TB
    S["shutdown<br/>ngừng nhận tác vụ mới"] --> W1{"awaitTermination<br/>chờ hoàn tất"}
    W1 -->|"xong trong hạn"| DONE["Tắt xong"]
    W1 -->|"hết giờ"| NOW["shutdownNow<br/>gửi interrupt tới tác vụ đang chạy<br/>có đáp hay không tùy tác vụ"]
    NOW --> W2{"awaitTermination<br/>chờ lại"}
    W2 -->|"hoàn tất"| DONE
    W2 -->|"vẫn chưa xong"| LOG["Ghi là bất thường<br/>nghi tác vụ bỏ qua interrupt"]

Hình 5: Tắt hai giai đoạn của ExecutorService. Thiết kế theo giai đoạn «chờ lịch sự → yêu cầu qua interruption → nếu vẫn chưa xong, quan sát như bất thường»

Có một giới hạn khi hủy các Runnable mà shutdownNow() trả. Thứ trở về là đối tượng ngồi trong hàng đợi thực thi — với submit thường đó chính là FutureTask giao cho người gọi, nhưng với tác vụ gửi qua bao như ExecutorCompletionService, đó là bao trong hàng đợi, đối tượng khác với Future của người gọi. Ở cấu hình đó, việc hủy ở trên sẽ không hoàn tất Future của người gọi, nên thiết kế giữ danh sách Future của riêng lúc gửi và hủy chúng khi tắt (hoặc trả tác vụ bị hạ về chủ).

close() (AutoCloseable), có từ JDK 19, gói «gọi shutdown và chờ hoàn tất» thành dạng viết được bằng try-with-resources, và try (var executor = ...) kết hợp newVirtualThreadPerTaskExecutor của virtual thread là hình cơ bản hiện đại.¹ Tuy nhiên close() không thay mẫu hai giai đoạn ở trên. Vì nó chờ hoàn tất không thời hạn, nếu dù chỉ một tác vụ không đáp interruption hoặc không bao giờ xong, thread cố đóng nó chặn mãi mãi. Đó là công cụ phù hợp phạm vi tác vụ hữu hạn và được bảo đảm chạy đến hoàn tất (gửi ngay đó, chờ ngay đó); với chỗ như đường tắt ứng dụng, nơi muốn luôn xong trong thời gian có biên, dùng mẫu hai giai đoạn có thời hạn. Hủy tác vụ đơn lẻ cũng qua interruption, bằng Future.cancel(true).

7. Thread UI — EDT của Swing

Ứng dụng máy tính để bàn, bất kể ngôn ngữ hay khung, theo quy tắc UI thuộc riêng thread quản lý nó. Ở Swing, thread riêng đó là Event Dispatch Thread (EDT): phương thức thành phần Swing, theo quy tắc, không an toàn luồng, và chạm từ nhiều thread mời nhiễu thread và lỗi nhất quán bộ nhớ. Yêu cầu cập nhật màn hình từ thread khác qua SwingUtilities.invokeLater tới EDT, và ngược lại, vì chạy thao tác lâu trên EDT đóng băng UI, đẩy việc nặng ra thread thợ qua SwingWorker hoặc tương tự.⁷ JavaFX theo cùng hình: cập nhật UI được yêu cầu trên thread ứng dụng qua Platform.runLater.

8. Xác minh và gỡ lỗi — dump thread như vũ khí

Không thể kỳ vọng kiểm thử tìm lỗi đua. Kiểm thử thường đếm lần chạy mà tranh chấp tình cờ không xảy ra là thành công. Nghĩ phòng thủ ba lớp.

Tuyến đầu là thiết kế. Khi rà, kiểm bằng bảng: dữ liệu có thể đổi nào được chia sẻ, khóa nào bảo vệ từng mục (ánh xạ mục 5.1), thứ tự chiếm khóa có duy nhất không, khối catch nào đang nuốt InterruptedException không, và đường dừng (shutdown/interruption) có tới mọi tác vụ không.

Thứ hai, dùng dump thread cho tốt. Java có công cụ chuẩn bắt «trạng thái mọi thread tại khoảnh khắc đóng băng này»: jstack (hoặc jcmd <pid> Thread.print) in dấu vết ngăn xếp, và tùy chọn -l thêm thông tin khóa.⁹ Lưu ý định dạng dump truyền thống này dành cho thread nền tảng; không gồm virtual thread của ứng dụng. Khi lần yêu cầu bị chặn ở cấu hình dùng virtual thread (mục 3), dùng jcmd <pid> Thread.dump_to_file -format=json <file>, thứ dump được cả virtual thread.² Thủ tục cơ bản điều tra treo là lấy hai ba dump cách nhau vài giây và đối chiếu mỗi thread nhàn chờ khóa nào, và ai đang giữ khóa đó. Nếu ghi nhật ký hết giờ tryLock(timeout) (mục 5.2), còn có thể tự động hóa cò lấy dump.

Thứ ba, lắc dưới tải. Kiểm thử căng — chạy lâu với song song nhiều hơn số lõi, xáo thứ tự xử lý, chèn trễ nhân tạo — là cách thực tế tăng khả năng kéo «trúng» điều kiện đua trên máy phát triển. Chạy ít nhất một kiểm thử với khối lượng dữ liệu và số thread quy mô sản xuất trước phát hành.

9. Đồng thời Java đang đi đâu — Structured Concurrency

Nhìn nhanh nửa bước phía trước, để kết. Xây trên giả định virtual thread, Structured Concurrency (StructuredTaskScope) — thứ coi nhiều tác vụ con là một đơn vị việc và cấu trúc lan truyền thất bại cùng hủy — đang phát triển và, tính đến tháng 8 năm 2026, vẫn là tính năng xem trước. Nó được sửa thành dạng API dựa trên StructuredTaskScope.open() ở lần xem trước thứ năm của JDK 25 (JEP 505), và tiếp thành lần xem trước thứ sáu (JEP 525) ở JDK 26 hiện tại.¹⁰¹¹ Trong khi đó Scoped Values, chia sẻ ngữ cảnh bất biến giải quyết vấn đề của ThreadLocal, đã được chốt ở JDK 25.¹² Các nguyên tắc bài này — biên tác vụ rõ, chia sẻ bất biến, dừng hợp tác — cũng thẳng hướng các API mới này đang đi.

10. Tóm tắt — danh sách kiểm của Java

1. Còn new Thread nào trong mã nghiệp vụ không (đã dựng trên ExecutorService / virtual thread chưa)?
2. Việc I/O-bound và CPU-bound được đưa sang cơ chế thực thi khác nhau chưa (nhánh hình 3)?
3. Virtual thread không bị gom pool, và đồng thời được giới hạn bằng Semaphore chưa?
4. Dữ liệu dùng chung bất biến (record / List.copyOf), hay dựng trên công cụ của java.util.concurrent?
5. Không có synchronized(this) hay khóa trên đối tượng phơi ra công khai?
6. Đang dùng thao tác ghép của ConcurrentHashMap (computeIfAbsent, v.v.) và giữ hàm ánh xạ ngắn?
7. Không kỳ vọng tính nguyên tử từ volatile (bộ đếm dùng lớp Atomic / LongAdder)?
8. Không có dù một khối catch nuốt InterruptedException?
9. Dừng ExecutorService theo mẫu hai giai đoạn có thời hạn (và chỗ dùng close() giới hạn phạm vi bảo đảm hoàn tất tác vụ)?
10. Cập nhật UI Swing/JavaFX được gom trên EDT / thread ứng dụng?

Java là một trong những ngôn ngữ được trang bị công cụ đồng thời tốt nhất, và sự xuất hiện của virtual thread đã mở đường mở rộng mã đồng bộ thẳng mà không viết lại. Đó chính là lý do nắm đúng sự phân công giữa các công cụ — cái nào cho thông lượng, cái nào cho loại trừ, và tín hiệu dừng là gì — là bản chất thiết kế đa luồng ở Java.

Bài viết liên quan

• Thực hành đa luồng tốt nhất: bản .NET — điều cần quyết trước khi thêm thread
• Thực hành đa luồng tốt nhất: bản C++ — loại tai nạn bằng cấu trúc qua RAII và jthread
• Thực hành đa luồng tốt nhất: bản C — viết an toàn theo cách Win32 API
• A Practical Decision Table for C# async/await - Task.Run and ConfigureAwait

Lĩnh vực tư vấn liên quan

KomuraSoft LLC đảm nhận rà soát thiết kế đa luồng cho hệ thống nghiệp vụ và xử lý batch Java, điều tra nguyên nhân gốc các khiếm khuyết liên quan đồng thời như trạng thái dùng chung bị hỏng và triệu chứng «thỉnh thoảng không dừng / treo» (phân tích dump thread), và tư vấn kỹ thuật về việc áp dụng virtual thread.

• Tư vấn kỹ thuật và đánh giá thiết kế
• Điều tra lỗi và nguyên nhân
• Liên hệ với chúng tôi

Liên kết tham khảo

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Đã có virtual thread thì còn cần pool thread (ExecutorService) nữa không?

Tùy trường hợp dùng. Virtual thread là cơ chế để chạy số lượng rất lớn tác vụ bị chi phối bởi chờ I/O; chúng không làm mã nhanh hơn, chúng nâng thông lượng. Với công việc I/O-bound, dùng một virtual thread mỗi tác vụ (Executors.newVirtualThreadPerTaskExecutor) và đừng bao giờ gom virtual thread vào pool. Ngược lại, để song song hóa tính toán làm đầy CPU, một pool thread nền tảng giới hạn khoảng bằng số lõi (hoặc parallel stream) vẫn là công cụ đúng, như trước. Và nếu muốn giới hạn số kết nối đồng thời tới dịch vụ ngoài, khuyến nghị thời đại virtual thread là giới hạn bằng Semaphore chứ không bằng kích thước pool.

Nên dùng synchronized hay ReentrantLock?

Với loại trừ ngắn và đơn giản, synchronized là đủ và mã vẫn gọn. Chọn ReentrantLock khi cần các khả năng như chiếm có thời hạn qua tryLock, chính sách công bằng, hoặc nhiều Condition. Có lưu ý lịch sử khi kết hợp với virtual thread: JDK 21-23 có vấn đề là chặn trong khối synchronized ghim virtual thread vào thread OS của nó, nên người ta khuyên thay các chỗ chặn thường xuyên hoặc lâu bằng ReentrantLock. JDK 24 (JEP 491) viết lại cài đặt monitor và gỡ ràng buộc này. Từ JDK 24 trở đi không cần thay synchronized vì lý do ghim.

Thêm volatile có làm thứ gì đó an toàn luồng không?

Không. volatile của Java tạo quan hệ happens-before giữa ghi biến đó và đọc nó, bảo đảm tầm nhìn (rằng ghi mới nhất được các thread khác thấy) và thứ tự, nhưng không bảo đảm tính nguyên tử của thao tác ghép như «đọc, tính, ghi lại». Tăng bộ đếm volatile int bằng ++ từ nhiều thread thì các phép cộng bị mất. Dùng AtomicInteger / AtomicLong (hoặc LongAdder cho tổng hợp tần suất cao) cho bộ đếm, và khóa khi bảo vệ nhiều biến cùng lúc. volatile gần như chỉ phù hợp trong tình huống như cờ trạng thái đơn giản — nơi một thread ghi và các thread khác chỉ đọc.

Bắt InterruptedException rồi bỏ qua được không?

Không. Interruption là tín hiệu chuẩn của Java để dừng và hủy, và nuốt nó tạo ra một thread sẽ không dừng. Khi InterruptedException được ném, trạng thái interrupt đã bị xóa, nên nếu không tự hoàn thành công việc được, hãy khôi phục trạng thái bằng Thread.currentThread().interrupt() để để lại tín hiệu cho người gọi, hoặc ném lại ngoại lệ nguyên trạng. Khối catch rỗng không làm gì là nguyên nhân cổ điển của lỗi mà shutdown không có hiệu lực hoặc shutdownNow bị bỏ qua.

Không thể dừng thread bằng Thread.stop sao?

Không, không thể. Thread.stop về bản chất không an toàn (giải phóng khóa trong trạng thái không nhất quán, lộ đối tượng hỏng cho thread khác), nên đã bị loại bỏ lâu, và gọi nó trong Java hiện tại ném UnsupportedOperationException. Điều tương tự áp dụng cho Thread.suspend / resume. Cách hợp lệ duy nhất để dừng thread là dừng hợp tác qua interruption. Nếu dùng ExecutorService, shutdown chỉ ngừng nhận tác vụ mới và chờ hoàn tất — không gửi interrupt tới tác vụ đang chạy. Thứ cố dừng tác vụ đang chạy là shutdownNow, và đó là best-effort (cài đặt chuẩn làm việc qua interruption).

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.