Search
Ask A Question
Answered
Avatar
0
Ngô Văn Hiếu Beginner
Asked At: 1783007412000 In: Java
Ngô Văn Hiếu Beginner Asked At: 1783007412000 In: Java
Hỏi về việc sử dụng Completablefuture trong dự án thực tế
Em chào anh Dũng và mọi người ạ!
Dạo gần đây em đang đọc phần về CompletableFuture trong cuốn Modern Java In Action. Sau khi tìm hiểu thì em thấy CompletableFuture khá hữu ích với các tác vụ liên quan đến I/O, chẳng hạn như gọi API từ các hệ thống bên ngoài.
Ví dụ, nếu cần gọi đồng thời hai API thì có thể viết như sau:
CompletableFuture<String> future1 =
        CompletableFuture.supplyAsync(api::callApi1);

CompletableFuture<String> future2 =
        CompletableFuture.supplyAsync(api::callApi2);
Theo cách hiểu của em, callApi1() và callApi2() sẽ được thực thi song song trên các thread khác. Nhờ vậy, thread xử lý request không phải chờ từng API hoàn thành rồi mới gọi API tiếp theo, nên tổng thời gian phản hồi có thể được rút ngắn đáng kể.
Tuy nhiên, em cũng nghĩ rằng cách này cần quản lý thread cẩn thận, chẳng hạn sử dụng thread pool phù hợp. Nếu mỗi request đều tạo quá nhiều thread mới thì có thể gây lãng phí tài nguyên, thậm chí ảnh hưởng đến hiệu năng hoặc độ ổn định của server.
Em có một vài thắc mắc muốn xin ý kiến mọi người:
  • Trong thực tế, CompletableFuture có được sử dụng nhiều để xử lý các tác vụ I/O như thế này không? Các dự án production có áp dụng phổ biến không ạ?
  • Khi sử dụng CompletableFuture thì thường sẽ phải đánh đổi những gì? Hiện tại em mới thấy khá nhiều lợi ích nên muốn nghe thêm góc nhìn từ mọi người.
  • Theo kinh nghiệm của anh Dũng và mọi người thì ưu điểm, nhược điểm và những lưu ý quan trọng khi áp dụng CompletableFuture trong thực tế là gì ạ?
Em cảm ơn anh Dũng và mọi người!
  • 1 Answer(s)
  • 456 Views
  • Answer
Remain: 5
1 Answer
Avatar
tvd12 Enlightened
Added an answer at: 1783768487000
tvd12 Enlightened
The Best Answer
Added an answer at: 1783768487000
Hello Hiếu, sorry em anh trả lời trễ.
Ở bên trong thì CompletableFuture sử dụng kiểu 
private static final Executor asyncPool = useCommonPool ?
        ForkJoinPool.commonPool() : new ThreadPerTaskExecutor();
Với code này thì Java core sẽ tự tính toán dùng thread thế nào cho hợp lý. Xem trong mã nguồn thì có vẻ như tối đa sẽ có 32.767 thread được tạo ra, đây là một số lượng thread rất lớn, nếu cần này thread được tạo ra cũng không phải là ý tưởng tốt vì có làm giảm hiệu quả của đa luồng. Vậy nên:
  1. Ưu điểm: Nếu các nghiệp vụ I/O của em xử lý rất nhanh thì CompletableFuture rất tuyệt vời, nó không cần chờ đợi tuần tự như vậy tốc độ có thể rất nhanh.
  2. Nhược điểm: Nhưng nếu nghiệp vụ I/O của em chậm, số lượng request call đồng thời tăng nhanh sẽ có hàng chục nghìn thread được ra, lúc này máy chủ sẽ đòi hỏi 1 lượng tài nguyên lớn để đáp ứng.
Theo anh thì cần phải giới hạn được số lượng thread, anh thường chỉ để tối đa vài trăm thread được sinh ra thôi nên rất ít khi anh dùng đến CompletableFuture.
  • 0
  • Reply
Đầu tiên cảm ơn anh đã phản hồi em ạ.
Từ câu trả lời của anh thì cho em hỏi thêm nếu gặp 1 task I/O mà cần xử lý đồng thời thì theo như em hiểu là chúng ta nên giới hạn số lượng thread tối đa trong thread pool, nếu đã giới hạn số lượng thread thì dùng cái CompletableFuture này vẫn ổn đúng không anh?
Tại vì em thấy trong 1 hệ thống microservice thì việc call 1 Api của service khác là 1 việc khá thường xuyên, mà việc gọi bất đồng bộ như này thì nó giúp giảm thời gian phản hồi của 1 request đáng kể (Theo em thì đây có thể là 1 trong các cách tối ưu thời gian phản hồi của 1 request chậm).
Em ví dụ việc giới hạn 200 thread.
ExecutorService executor =
    Executors.newFixedThreadPool(200);
CompletableFuture.supplyAsync(() -> callApi(), executor);
 –  Ngô Văn Hiếu 1783779415000
Đầu tiên cảm ơn anh đã phản hồi em ạ.
Từ câu trả lời của anh thì cho em hỏi thêm nếu gặp 1 task I/O mà cần xử lý đồng thời thì theo như em hiểu là chúng ta nên giới hạn số lượng thread tối đa trong thread pool, nếu đã giới hạn số lượng thread thì dùng cái CompletableFuture này vẫn ổn đúng không anh?
Tại vì em thấy trong 1 hệ thống microservice thì việc call 1 Api của service khác là 1 việc khá thường xuyên, mà việc gọi bất đồng bộ như này thì nó giúp giảm thời gian phản hồi của 1 request đáng kể (Theo em thì đây có thể là 1 trong các cách tối ưu thời gian phản hồi của 1 request chậm).
Em ví dụ việc giới hạn 200 thread.
ExecutorService executor =
    Executors.newFixedThreadPool(200);
CompletableFuture.supplyAsync(() -> callApi(), executor);
 –  Ngô Văn Hiếu 1783779524000
Ừ, nếu em đã giới hạn số lượng thread thì dùng CompletableFuture ok em ạ. Tuy nhiên em nên tạo ra lớp wrap vì lần nào gọi cũng phải truyền cái executor trông nó không được tự nhiên, một số người thì hay quên em ạ.
  –  tvd12 1783905895000
Ask A Question
  • Question(s) 1.1K
  • Answer(s) 2.2K
  • Best answer(s) 137
  • User(s) 766

Related Questions

Recent Activities

Show All Activities

Top Members

Trending Tags

.net .net core .net oop #formatdate abstract class access app access token ai android ansible anti-flooding apache poi api app architecture artificial intelligence assembly async asyncawait atomicboolean authentication backend backend nestjs background bash script batch bean big project binding bitcoin blockchain blog boot-nodes branch btree bucket4j buffered build bundle c# c# .net cache caching callback career career path cast câu hỏi centos chat cloud cloud reliability combobox commit communication computer science concurrent config-css connection pool content-disposition contract controllerservice convert date to number cookie cors cosmos cosmos-sdk crawl data cron css database database migration datasource datastructure datetime deadlock debug decentralized exchange deep learning deploy contract design patterns design-pattern dev devops dex di distraction programing dns đồ án tốt nghiệp docker download draw.io du học dữ liệu lớn duration eclip editor elasticsearch email erc20 erc721 error estimation eth ethereum ethereum login excel excel-object-mapper exception exception handle exception handler executor export compliance extensions exyfox ezydata ezyfox ezyfox-boot ezyfox-server ezyfoxserver ezyhttp ezyjpa ezymq-kafka ezyplatform ezyredis facebook fe filter floating point flutter format json freetank front-end frontend fullstack fulltextsearch future gallery game game-box game-room game-server gateway get get file zip git glide go golang gorilla graduation thesis graphql grapql grpc guide h2 database handy terminal hazelcast hibernate hibernateconfig html http https hyperloglog image index indexing integration-test intellij interface io ioc ipfs isolate issue it java java core java spring java web javacore javascript javaw jenkins jetbrains job join jotform jpa jpql jquery js json json file json to object jsonproperty jsp jsp &amp; servlet junit-test jvm jwt kafka keep promise kerberos keycloak kotlin languague laravel library list load balancer load-balancing lock log log4j log4j-core login lỗi font lưu trữ machine learning macos mail mail template main map maria db markdown math maven merge mermaid message queue messaging metamask microservice microservices migration mobile model mongo monitoring mq msgpack multi-threading multiple tenant multithread multithreading mysql n naming naming convention nan netcore netty network networking nft nft game nginx nio node.js nodejs non-blocking io null odoo oop opensource optimize oracle orm otp message paginaiton pagination pancakeswap panic partition pdf pgpool phỏng vấn php plugin pointer postgresql postman pre private_key procedure profile programming programming-language project management promise properties push message android push notification push-noti python python unicode qr qrcode question queue rabbitmq react-native reactive reactjs reactjs download readmoretextview recyclerview redis refactor refresh token regex replica repository request resilence4j resource rest restful resttemplate roadmap room database ropssten ropsten round robin rust rxjava s3 schedule scheduled scheduled spring boot search security send email send mail serialization server servlet session shift jis singleton sjis slack smart contract soap socket socket server soft delete solution sosanh spring spring aop spring boot spring data jpa spring redis spring security spring websocket spring websocket cors spring-boot-test spring-jpa springboot springsecurity springwebflux mysql sql sql server sse ssl ssl email stackask storage stream stream api stress test stresstest structure trong spring boot study synchronize synchronized system environment variables tcp test thiết kế tầng trong dự án thread thread pool threadjava threadpool thymeleaf tomcat totp tracking location transaction transfer transfer git udp ui uniswap unit test unity upload upload file utf-8 file validate validate date vector video call vietqr view volatile vue vue cli vuejs watermark web web3 web3 client webassembly webflux webpack webrtc websocket windows 11 winforms wordpress work xss zip file zookeeper
0%

Media

Add New Media

Media Details

Uploaded On
File Name
File Type
File Size
Dimension