当前位置 : 主页 > 编程语言 > java >

Java并发编程——CompletebaleFuture 异步回调的原理和使用

来源:互联网 收集:自由互联 发布时间:2023-02-04
CompletebaleFuture的底层原理是:Fork/joinPoll + Treiber stack(异步任务栈)+CAS,可以实现:创建较少的线程(减少线程上下文切换)执行较多的任务(不耗时的任务)   结论:当任务不是很耗时,多线

CompletebaleFuture的底层原理是:Fork/joinPoll + Treiber stack(异步任务栈)+CAS,可以实现:创建较少的线程(减少线程上下文切换)执行较多的任务(不耗时的任务)

 

结论:当任务不是很耗时,多线程的作用不大,反而性能上比不上单线程。而在多线程中,推荐CompletableFuture去创建任务、开启线程操作,性能比用Callable与FutureTask组合好很多。

同步调用的缺点

我们假设一个电子商城用户购买商品的场景: 创建订单前的验证方法。

/** * 验证订单是否合法 * * @param userId 用户id * @param itemId 商品id * @param discount 折扣 * @return */ public boolean verifyOrder(long userId, long itemId, double discount) { // 验证用户能否享受这一折扣,RPC调用 boolean verifyDiscount = discountService.verify(userId, itemId, discount); if(!verifyDiscount) { // 该用户无法享受这一折扣 return false; } // 获取商品单价,RPC调用 double itemPrice = storeService.getPrice(itemId); // 用户实际应该支付的价格 double realPrice = itemPrice * discount; // 获取用户账号余额,限定了只能使用余额购买,RPC调用 double balance = userService.getBalance(userId); return realPrice <= balance; }

这个方法里面涉及到了 3 个 rpc 调用,假设每个 rpc 调用都需要 10ms,那么 verifyOrder 这个方法总耗时将不低于 30ms。

 

在同步调用系统中,延迟同时会导致吞吐量的下降。如果只有一个线程,那么系统每秒的吞吐量将不会高于 1000ms / 30ms,也就是最多 33 qps。同步系统要提高吞吐量,唯一的办法就是加大线程数。同时启用 1,000 个线程,吞吐量理论值可以上升到 33,333 qps。不过实际使用中,这并不是完美的方案:增加线程数量会导致频繁的上下文切换,系统整体性能将会严重下降。

Future 的不足

为了解决同步系统的问题,Java 5 引入了 Future。有了 Future 后,上面的方法可以修改为:

/** * 验证订单是否合法 * * @param userId 用户id * @param itemId 商品id * @param discount 折扣 * @return */ public boolean verifyOrder(long userId, long itemId, double discount) { // 验证用户能否享受这一折扣,RPC调用 Future<Boolean> verifyDiscountFuture = discountService.verify(userId, itemId, discount); // 获取商品单价,RPC调用 Future<Double> itemPriceFuture = storeService.getPrice(itemId); // 获取用户账号余额,限定了只能使用余额购买,RPC调用 Future<Double> balanceFuture = userService.getBalance(userId); if(!verifyDiscountFuture.get()) { // 该用户无法享受这一折扣 return false; } // 用户实际应该支付的价格 double realPrice = itemPriceFuture.get() * discount; // 用户账号余额 double balance = balanceFuture.get(); return realPrice <= balance; }

CompletableFuture 才是王道

引入 CompletableFuture 后,我们可以使用如下形式:

/** * 验证订单是否合法 * * @param userId 用户id * @param itemId 商品id * @param discount 折扣 * @return */ public CompletableFuture<Boolean> verifyOrder(long userId, long itemId, double discount) { // 验证用户能否享受这一折扣,RPC调用 CompletableFuture<Boolean> verifyDiscountFuture = discountService.verify(userId, itemId, discount); // 获取商品单价,RPC调用 CompletableFuture<Double> itemPriceFuture = storeService.getPrice(itemId); // 获取用户账号余额,限定了只能使用余额购买,RPC调用 CompletableFuture<Double> balanceFuture = userService.getBalance(userId); return CompletableFuture .allOf(verifyDiscountFuture, itemPriceFuture, balanceFuture) .thenApply(v -> { if(!verifyDiscountFuture.get()) { // 该用户无法享受这一折扣 return false; } // 用户实际应该支付的价格 double realPrice = itemPriceFuture.get() * discount; // 用户账号余额 double balance = balanceFuture.get(); return realPrice <= balance; }); }

延迟降低为原来 1/3,同时吞吐量也不会因为延迟而降低。非常完美,简单高效,CompletableFuture 绝对称得上是大杀器。在 rpc 异步调用这个问题上,没什么比 CompletableFuture 更适合的解决方案了。CompletableFuture 是 Doug Lea 的又一力作,彻底解决了 Future 的缺陷,把 Java 带入了异步响应式编程的新世界。

 

参考: https://blog.csdn.net/jack_shuai/article/details/115304267

上一篇:Java并发编程——CompletableFuture源码解析
下一篇:没有了
网友评论