Java CompletableFuture: Chọn executor, xử lý lỗi và timeout không làm nghẽn common pool

Chào bạn Bảo Trâm, Không nên mặc định đẩy I/O blocking vào common ForkJoinPool. Hãy dùng ExecutorService được cấu hình theo loại tải, có giới hạn queue, số thread, tên thread và metric để quan sát. Tách pool cho CPU-bound và blocking I/O khi cần, đồng thời tránh tạo executor mới trên mỗi request. Xác định rõ timeout ở boundary của từng remote call và timeout cho toàn bộ use case. Dùng handle hoặc whenComplete cho quan sát, còn exception phải được unwrap và chuyển thành lỗi nghiệp vụ hoặc lỗi hạ tầng có ngữ cảnh rõ ràng. Đừng chỉ dùng exceptionally để im lặng trả giá trị mặc định. Khi ghép nhiều future, quyết định trước chính sách fail-fast hay chấp nhận partial result. Đảm bảo hủy hoặc bỏ kết quả công việc không còn cần thiết và luôn đo queue depth, active threads, timeout rate.

Về vấn đề này, tôi đồng ý rằng việc sử dụng chung ForkJoinPool cho các tác vụ I/O blocking có thể làm cạn kiệt các thread sẵn có và gây ra hiện tượng queue đầy. Việc định nghĩa các ExecutorService riêng biệt cho các tác vụ CPU-bound, I/O-blocking và các tác vụ ngắn, không có trạng thái là một phương pháp hay. Cách tiếp cận này cho phép bạn giới hạn số lượng thread, đặt tên cho chúng và giám sát các chỉ số như độ sâu queue, tỷ lệ timeout. Khi ghép nhiều Future, việc xác định rõ chính sách fail-fast so với việc chấp nhận kết quả một phần giúp giảm thiểu các lỗi ngầm định. Ngoài ra, việc unwrap các ngoại lệ thành các lỗi nghiệp vụ có ngữ cảnh rõ ràng giúp việc xử lý trở nên dễ dàng hơn. Bạn thường làm gì khi cần một pool xử lý đồng thời các tác vụ có độ trễ cao và các tác vụ có độ trễ thấp trong cùng một ứng dụng?

Tôi thường chỉ định một `ExecutorService` riêng biệt thay vì phụ thuộc vào `ForkJoinPool.commonPool()` khi sử dụng `supplyAsync` hoặc `thenApply` cho các tác vụ gọi API. Tạo một thread pool có kích thước cố định (ví dụ: `Executors.newFixedThreadPool(10)`) giúp bạn kiểm soát được tải công việc và tránh tình trạng cạn kiệt tài nguyên do các tác vụ bất đồng bộ gây ra. Đối với việc xử lý lỗi, hãy sử dụng ` exceptionallyCompose ` hoặc ` handle ` thay vì ném exception trực tiếp, đồng thời ghi lại dấu vết lỗi bên trong handler; điều này giúp luồng gọi không bị gián đoạn. Áp dụng timeout thông qua ` CompletableFuture.get(deadline) ` hoặc sử dụng ` completeOnTimeout ` để tránh tình trạng treo mãi mãi mà không làm gián đoạn pool. Bạn đã thử nghiệm việc điều chỉnh kích thước thread pool theo số lượng yêu cầu đồng thời chưa, hoặc kết hợp `ThreadPoolExecutor.CallerRunsPolicy` cho các công việc dự phòng chưa?

Tôi thường tránh sử dụng supplyAsync không có executor vì nó sẽ sử dụng common ForkJoinPool, điều này có thể gây ra tình trạng tắc nghẽn khi bạn có nhiều tác vụ song song. Hãy tạo một ThreadPoolExecutor riêng biệt với số luồng giới hạn phù hợp với số lượng API gọi đồng thời mà bạn cần (ví dụ: `Executors.newFixedThreadPool(10)`). Sử dụng nó khi khởi tạo các CompletableFuture: ```java CompletableFuture.supplyAsync(() -> callApi(...), executor) ``` Để thiết lập timeout mà không làm tắc nghẽn pool, hãy sử dụng `orTimeout` hoặc `completeOnTimeout` trên future; chúng sẽ hủy bỏ tác vụ nền nếu vượt quá thời gian chờ, giải phóng thread. Khi xử lý lỗi, hãy ưu tiên sử dụng `handle` thay vì `exceptionally` nếu bạn cần giá trị dự phòng, vì `handle` cho phép bạn truy cập kết quả hoặc ngoại lệ một cách rõ ràng. Đối với việc gộp lỗi từ nhiều future, bạn có thể sử dụng `CompletableFuture.allOf` kết hợp với `exceptionallyCompose` hoặc thu thập các ngoại lệ trong một danh sách. Bạn mong đợi bao nhiêu tác vụ đồng thời trong dịch vụ của mình, và độ trễ mục tiêu cho mỗi API là bao lâu? Điều này sẽ giúp xác định kích thước pool tối ưu.