生产问题之CompletableFuture默认线程池踩坑，请务必自定义线程池

最新推荐文章于 2025-09-30 10:40:41 发布
转载 最新推荐文章于 2025-09-30 10:40:41 发布 · 4.7k 阅读 · 11 ·
CC 4.0 BY-SA版权
原文链接：https://www.cnblogs.com/blackmlik/p/16098938.html
文章标签：

#java #服务器

文章讲述了Java中的CompletableFuture在不同CPU核心数的机器上是否会使用默认的ForkJoinPool线程池，以及其决策逻辑。当CPU核心数-1大于1时，CompletableFuture会使用默认线程池，否则每个任务将创建新线程，可能导致资源耗尽。作者建议在使用CompletableFuture时务必自定义线程池，因为默认线程池可能不适用于IO密集型任务，且核心线程数有限。

1|0前言

先说结论，没兴趣了解原因的可以只看此处的结论

CompletableFuture是否使用默认线程池的依据，和机器的CPU核心数有关。当CPU核心数-1大于1时，才会使用默认的线程池，否则将会为每个CompletableFuture的任务创建一个新线程去执行。

即，CompletableFuture的默认线程池，只有在双核以上的机器内才会使用。在双核及以下的机器中，会为每个任务创建一个新线程，等于没有使用线程池，且有资源耗尽的风险。

因此建议，在使用CompletableFuture时，务必要自定义线程池。因为即便是用到了默认线程池，池内的核心线程数，也为机器核心数-1。也就意味着假设你是4核机器，那最多也只有3个核心线程，对于CPU密集型的任务来说倒还好，但是我们平常写业务代码，更多的是IO密集型任务，对于IO密集型的任务来说，这其实远远不够用的，会导致大量的IO任务在等待，导致吞吐率大幅度下降，即默认线程池比较适用于CPU密集型任务。

2|0背景

最近接到一个工作任务，由于我们之前的下单接口速度过慢，光是下单接口需要1500ms左右，因此需要做一些优化，在梳理完业务逻辑后，发现有一些可以并行查询或者异步执行的地方。于是打算采用CompletableFuture来做异步优化，提高执行速度。代码示例如下

//查询用户信息 CompletableFuture<JSONObject> userInfoFuture = CompletableFuture .supplyAsync(() -> proMemberService.queryUserByOpenIdInner(ordOrder.getOpenId())); //查询积分商品信息 CompletableFuture<JSONObject> integralProInfoFuture = CompletableFuture .supplyAsync(() -> proInfoService .getIntegralInfoCache(ordOrderIntegral.getProId())); //查询会员积分信息 CompletableFuture<Integer> integerFuture = CompletableFuture .supplyAsync(() -> proMemberService .getTotalIntegralByOpenId(ordOrder.getOpenId()));

3|0经过

于是一顿操作，优化完毕，执行速度从1500ms下降到300ms左右，在经过本地和测试环境后，上线生产。众所周知，CompletableFuture在没有指定线程池的时候，会使用一个默认的ForkJoinPool线程池，也就是下面这个玩意。

public static ForkJoinPool commonPool() { // assert common != null : "static init error"; return common; }

等发了生产之后看日志打印的线程号，却发现了一个极其诡异的事情。明明是同一套代码，生产环境的没有用到默认的线程池。而测试环境和本地环境都使用了默认的ForkJoinPool线程池，

这是测试和本地环境打印的线程日志

这是生产环境打印的线程日志

从日志打印的线程编号可以看到，测试和本地环境都是从ForkJoinPool中取工作线程，但是生产环境却是为每个任务创建了一个全新的线程。这是一个很危险的行为，假如这是一个并发比较高的接口，并且该接口使用了比较多的CompletableFuture来并行的执行任务。在高并发的时候，为每个任务都创建一个子线程，就会存在线程资源被耗尽的可能性，从而导致服务器崩溃。

那这是为什么呢？明明是同一套代码，在不同的机器上却有不同的线程使用情况。

4|0原因

在带着疑问翻阅了CompletableFuture的源码之后，终于找到了原因：【是否使用默认的ForkJoinPool线程池，和机器的配置有关】

我们点进supplyAsync方法的源码

public static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier) { return asyncSupplyStage(asyncPool, supplier); }

可以看到这里使用了默认使用了一个asyncPool，点进这个asyncPool

//是否使用默认线程池的判断依据 private static final Executor asyncPool = useCommonPool ? ForkJoinPool.commonPool() : new ThreadPerTaskExecutor(); //useCommonPool的来源 private static final boolean useCommonPool = (ForkJoinPool.getCommonPoolParallelism() > 1);

其实代码看到这里就很清晰了，CompletableFuture是否使用默认线程池，是根据这个useCommonPool的boolean值来的，如果为true，就使用默认的ForkJoinPool，否则就为每个任务创建一个新线程，也就是这个ThreadPerTaskExecutor，见名知义。

那这个useCommonPool的布尔值什么情况下才为true，也就是什么时候才能使用到默认的线程池呢。即getCommonPoolParallelism（）返回的值要大于1，我们继续跟进这个getCommonPoolParallelism（）方法

//类顶SMASK常量的值 static final int SMASK = 0xffff; final int config; static final ForkJoinPool common; //该方法返回了一个commonParallelism的值 public static int getCommonPoolParallelism() { return commonParallelism; } //而commonParallelism的值是在一个静态代码块里被初始化的，也就是类加载的时候初始化 static { //初始化common，这个common即ForkJoinPool自身 common = java.security.AccessController.doPrivileged (new java.security.PrivilegedAction<ForkJoinPool>() { public ForkJoinPool run() { return makeCommonPool(); }}); //根据par的值来初始化commonParallelism的值 int par = common.config & SMASK; // report 1 even if threads disabled commonParallelism = par > 0 ? par : 1; }

总结一下上面三部分代码，结合在一起看，这部分代码主要是初始化了commonParallelism的值，也就是getCommonPoolParallelism（）方法的返回值，这个返回值也决定了是否使用默认线程池。而commonParallelism的值又是通过par的值来确定的，par的值是common来确定的，而common则是在makeCommonPool()这个方法中初始化的。

我们继续跟进makeCommonPool（）方法

private static ForkJoinPool makeCommonPool() { int parallelism = -1; if (parallelism < 0 && // default 1 less than #cores //获取机器的cpu核心数 将机器的核心数-1 赋值给parallelism 这一段是是否使用线程池的关键 //同时 parallelism也是ForkJoinPool的核心线程数 (parallelism = Runtime.getRuntime().availableProcessors() - 1) <= 0) parallelism = 1; if (parallelism > MAX_CAP) parallelism = MAX_CAP; return new ForkJoinPool(parallelism, factory, handler, LIFO_QUEUE, "ForkJoinPool.commonPool-worker-"); } //上面的那个构造方法，可以看到把parallelism赋值给了config变量 private ForkJoinPool(int parallelism, ForkJoinWorkerThreadFactory factory, UncaughtExceptionHandler handler, int mode, String workerNamePrefix) { this.workerNamePrefix = workerNamePrefix; this.factory = factory; this.ueh = handler; this.config = (parallelism & SMASK) | mode; long np = (long)(-parallelism); // offset ctl counts this.ctl = ((np << AC_SHIFT) & AC_MASK) | ((np << TC_SHIFT) & TC_MASK); }

总结一下上面两段代码，获取机器核心数-1的值，赋值给parallelism变量，再通过构造方法把parallelism的值赋值给config变量。

然后初始化ForkJoinPool的时候。再将config的值赋值给par变量。如果par大于0则将par的值赋给commonParallelism，如果commonParallelism的值大于1的话，useCommonPool的值就为true，就使用默认的线程池，否则就为每个任务创建一个新线程。另外即便是用到了默认线程池，池内的核心线程数，也为机器核心数-1。也就意味着假设你是4核机器，那最多也只有3个核心线程，对于IO密集型的任务来说，这其实远远不够的。

5|0解释

以上就是CompletableFuture中默认线程池使用依据的源码分析了。看完这一系列源码，就能解释文章一开头出现的那个问题。

因为我本地和测试环境机器的核心数是4核的，4减1大于1，所以在本地和测试环境的日志上可以看出，使用了默认的线程池ForkJoinPool，而我们生产环境是双核的机器。2减1不大于1，所以从生产环境的日志看出，是为每个任务都创建了一个新线程。

6|0总结

  • 使用CompletableFuture一定要自定义线程池
  • CompletableFuture是否使用默认线程池和机器核心数有关，当核心数减1大于1时才会使用默认线程池，否则将为每个任务创建一个新线程去处理
  • 即便使用到了默认线程池，池内最大线程数也是核心数减1，对io密集型任务是远远不够的，会令大量任务等待，降低吞吐率
  • ForkJoinPool比较适用于CPU密集型的任务，比如说计算。

生产环境的项目中java是如何定义，如何使用，如何关闭线程池的
北执南念的博客
06-25 143
生产环境的项目中java是如何定义，如何使用，如何关闭线程池的
【SpringBoot 3.x 第7节】还在为SpringBoot异步任务卡死而半夜爬起来重启服务器吗？揭秘线程池管理的那些“坑“与“术“！
**My Coding Family**
08-15 681
🏆本文收录于《滚雪球学Spring Boot》，专门攻坚指数提升，2025 年国内最系统+最强（更新中）。    本专栏致力打造最硬核 Spring Boot 从零基础到进阶系列学习内容，🚀均为全网独家首发，打造精品专栏，专栏持续更新中…欢迎大家订阅持续学习。 如果想快速定位学习，可以看这篇【SpringBoot教程导航帖】,你想学习的都被收集在内，快速投入学习！！两不误。
从用法到源码再到应用场景：全方位了解CompletableFuture及其线程池
Apple_Boy的博客
05-26 3887
JDK中的Future是什么可能大家都知道了，那呢？从英文看单词猜测应该也是和Future是Java 8引入的一个重要特性，它是Future接口的一个实现，但与传统的Future相比，提供了更强大、灵活的异步编程模型。支持非阻塞的链式调用、组合多个异步操作以及更优雅地处理异步计算的结果或异常。它允许你在异步操作完成时执行回调函数，且这些操作可以并行或串行执行，极大地提高了程序的并发能力和响应速度。使用// 创建一个完成的CompletableFuture// 运行异步计算// 异步执行的代码。
穿黑风衣的牛奶--生产问题之CompletableFuture默认线程池踩坑，请务必自定义线程池
勿忘初心
08-09 1740
使用CompletableFuture一定要自定义线程池CompletableFuture是否使用默认线程池和机器核心数有关，当核心数减1大于1时才会使用默认线程池，否则将为每个任务创建一个新线程去处理即便使用到了默认线程池，池内最大线程数也是核心数减1，对io密集型任务是远远不够的，会令大量任务等待，降低吞吐率ForkJoinPool比较适用于CPU密集型的任务，比如说计算。
java8 最优雅的多线程开发——CompletableFuture
最新发布
从对比中寻找伤害
09-30 946
CompletableFuture是Java 8引入的异步编程工具，支持任务编排和函数式处理。它提供runAsync()和supplyAsync()创建任务，join()/get()获取结果。为避免线程饥饿，建议为不同业务创建独立线程池而非使用默认的ForkJoinPool.commonPool()。CompletableFuture支持thenApply()、handle()等方法进行任务链式处理，以及thenCombine()、allOf()等组合多个任务。代码示例展示了如何用thenCombine()
记一次生产问题--CompletableFuture默认线程池
热门推荐
u011381576的博客
04-20 2万+
在jdk7中，我们使用线程池可能会使用ExecutorService，默认有四种方式 Executors.newSingleeThreadPool() Executors.newFixedThreadPool() Executors.newCacheThreadPool() Executors.newScheduledThreadPool() 在jdk8中，CompletableF...
CompletableFuture使用自定义线程池实现多任务结果聚合返回
老徐的博客只有干货
11-30 3764
/参数初始化//核心线程数量大小//线程池最大容纳线程数//阻塞队列//线程空闲后的存活时长//核心线程数//最大线程数//等待队列//线程前缀//线程池维护线程所允许的空闲时间,单位为秒// 线程池对拒绝任务(无线程可用)的处理策略@Autowired// 任务1，计算3秒// 任务2，计算2秒，得答案5// 任务3，计算3秒，得答案5// 写法1try {
记CompletableFuture默认线程池踩坑经历
不懂的博客
02-11 1422
在Java8开始引入了全新的类，它是Future接口的一个实现类。也就是在Future接口的基础上，额外封装提供了一些执行方法，用来解决Future使用场景中的一些不足，对处理能力提供了支持。当我们需要进行异步处理的时候，我们可以通过方法，传入一个具体的要执行的处理逻辑函数，这样就轻松的完成了CompletableFuture的创建与触发执行。相信大部分都用过这种方法执行过异步任务。
【踩坑记录】CompletableFuture.runAsync() 执行 Feign 调用的问题及原因分析
佳瑞的博客
07-23 1071
在 Spring Cloud 项目中，使用 CompletableFuture.runAsync() 执行 Feign 调用时，可能会遇到 ClassNotFoundException 或请求上下文丢失的问题，尤其是在 OpenJDK 11 + ForkJoinPool 环境下。
CompletableFuture异步业务 默认ForkJoinPool 导致类加载器加载类失败
一颗浑身披带雪花的松树---[雪松]
12-17 1101
通过解决困扰我同事与我这个问题；让我明白一个道理，如同最近在看《毛线---实践论与矛盾论》要解决实际问题只有深入实践并且注意矛盾的特殊性；因为每个开发场景可能与网上文章有相似【矛盾的普遍性】但是又有其自己开发与运行环境的【特殊性】；只有抓住特殊性并结合普遍性才能够找到解决问题的主要矛盾；并使得获得有效的方法论去解决实际问题。
面基线程池、CountDownLatch和Completablefuture组合使用
qq_37679639的博客
04-02 1117
线程池、CountDownLatch组合使用以及CompletableFuture的应用，代码示例
源码分析CompletableFuture使用默认线程池ForkJoinPool的弊端（cpu利用率低）
LX1232456的博客
08-23 2051
假如有20CompletableFuture任务并发执行时，都使用默认线程池ForkJoinPool，但cpu的核心数又小于3，那么就会新建20个线程（不使用默认线程池了），这20个线程相互竞争cpu资源和内存，很多线程都在等待，浪费了大量的性能在线程上下文切换上。
Java CompletableFuture线程池
勿忘初心
06-24 672
默认情况下 CompletableFuture 会使用公共的 ForkJoinPool 线程池，这个线程池默认创建的线程数是 CPU 的核数（也可以通过 JVM option:-Djava.util.concurrent.ForkJoinPool.common.parallelism 来设置 ForkJoinPool 线程池的线程数）。所以，强烈建议你要根据不同的业务类型创建不同的线程池，以避免互相干扰。
CompletableFuture指定ThreadPoolTaskExecutor自定义线程池
ALiangXiu的博客
05-27 8972
CompletableFuture指定ThreadPoolTaskExecutor自定义线程池 前言 用的是springboot 二、使用步骤 1.创建自定义线程池 代码如下： @Configuration public class asyncTaskExecutorConfig { //阻塞队列 private static final int workQueue = 20; //线程空闲后的存活时长 private static final int keepAliveTime
CompletableFuture 使用自定义线程池
kezhou的博客
02-20 2800
合到生产环境进行发布验证时，我们组的人都在进行功能验证，并发量增大，导致服务报错。对于一个 4 核的机器来说，最只有 3 个线程，对于IO密集型的任务来说，这其实远远不够用，从而导致大量的IO任务在等待，甚至服务挂掉。需求是修改一批数据，由于当时并没有提供批量修改的接口，所以只能循环去修改数据，又想到可以使用。虽然在处理 IO 密集型任务时，任务越多，CPU 效率越高，但也有一个限度。等于没有使用线程池，机器会为每个任务创建一个新线程，且会有资源耗尽的风险。）也使用的是默认的线程池，需要谨慎使用。
CompleteFuture自定义线程池
qq_45858458的博客
07-24 544
config// 配置核心线程数// 最大线程数// 队列大小// 名称前缀// rejection-policy: 当pool已经达到max size时，如何处理新任务：// CallerRunsPolicy: 不在新线程中执行任务，而是由调用者所在的线程来执行；// AbortPolicy: 拒绝执行新任务，并抛出RejectedExecutionException异常；// DiscardPolicy：丢弃当前将要加入队列的任务；
深入理解 CompletableFuture 的线程模型：默认 ForkJoinPool 与自定义线程池实战解析
努力分享一些人工智能、计算机视觉、影像等相关的知识干货！
06-11 1264
在 Java 并发编程中，`CompletableFuture` 提供了强大的异步任务编排能力，但其底层线程模型往往被忽视。默认使用的 `ForkJoinPool.commonPool()` 在高并发场景下可能引发线程争用、资源污染等问题。企业级应用中，正确理解 `CompletableFuture` 的执行线程机制、自定义 `Executor` 的使用规范、线程池配置建议与隔离策略，是保障系统稳定性与性能的关键。本篇文章将从源码机制、运行行为、真实案例出发，全面解析 CompletableFuture 中
CompletableFuture
qq_62775328的博客
04-13 969
CompletableFuture是基于Future模式的增强版，它不仅提供了Future的基本功能，还引入了函数式编程的特性，使得异步任务的编排和组合变得更加简单。CompletableFuture实现了Future和CompletionStage接口，其中CompletionStage接口用于描述异步计算的阶段，可以将多个计算步骤组合起来形成异步计算的流水线。
CompletableFuture 介绍及各个方法功能和参数介绍及各方法使用场景和容易踩坑的点，输出为md文档。尽可能的详细
09-17
<think> 我们正在编写关于CompletableFuture的详细文档，要求包含方法功能、参数、使用场景及易踩坑点。 根据用户要求，我们将以Markdown文档形式输出。 注意：用户提到了参考站内引用，但我们的引用内容主要涉及Elasticsearch查询语法（引用1）、Spring Security授权（引用2）、Resilience4j文档（引用3）和本地缓存（引用4），这些与CompletableFuture没有直接关系。因此，我们不需要在回答中强行引用它们。 但是，我们可以按照要求，在文档末尾生成相关问题。 以下是CompletableFuture的详细介绍文档： </think> # CompletableFuture 详解 ## 1. 核心概念 `CompletableFuture` 是 Java 8 引入的异步编程工具，继承自 `Future` 接口，提供了更强大的**异步任务编排能力**： - **非阻塞操作**：避免线程等待，提高资源利用率[^1] - **链式调用**：支持任务串联（thenApply）、并联（thenCombine） - **异常处理**：提供 `exceptionally` 等方法处理异步异常 - **组合操作**：支持 `allOf`/`anyOf` 等多任务组合 ## 2. 核心方法详解 ### 2.1 创建异步任务 ```java // 使用默认线程池 CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> { return "Result"; }); // 自定义线程池 ExecutorService customPool = Executors.newFixedThreadPool(4); CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> { return "Custom Pool"; }, customPool); ``` **参数**： - `Supplier<U>`：无参函数，返回结果 - `Executor` (可选)：自定义线程池 **场景**： - IO密集型任务（网络请求/文件读写） - 耗时计算（大数据处理） - 数据库查询操作 **易踩坑点**： ⚠️ 默认使用 `ForkJoinPool.commonPool()`，在高并发下可能导致资源耗尽 ✅ 推荐为不同业务类型指定独立线程池 ### 2.2 结果处理（链式调用） ```java CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> "42") .thenApply(Integer::parseInt) // 同步转换 .thenApplyAsync(num -> num * 2); // 异步转换 ``` **方法族**： | 方法 | 参数类型 | 说明 | |---------------------|---------------|--------------------------| | `thenApply` | Function<T,U> | 同步转换结果 | | `thenApplyAsync` | Function<T,U> | 异步转换（默认线程池） | | `thenCompose` | Function<T,CF>| 链式组合异步任务 | | `thenAccept` | Consumer<T> | 消费结果（无返回值） | **场景**： - 数据处理流水线（解析 → 转换 → 存储） - 服务调用链（A服务结果作为B服务的输入） **易踩坑点**： ⚠️ `thenApply` 在**前序任务线程**执行，可能阻塞主线程 ✅ IO操作使用 `thenApplyAsync` 避免阻塞 ### 2.3 异常处理 ```java CompletableFuture.supplyAsync(() -> { if (Math.random() > 0.5) throw new RuntimeException("Error"); return "Success"; }) .exceptionally(ex -> "Fallback") // 捕获异常返回默认值 .handle((res, ex) -> { // 同时处理结果和异常 return ex != null ? "Error" : res; }); ``` **方法族**： | 方法 | 说明 | |------------------|-----------------------------| | `exceptionally` | 捕获异常，返回替代值 | | `handle` | 同时处理结果和异常（BiFunction） | | `whenComplete` | 处理结果或异常（无返回值） | **场景**： - 服务降级（主服务失败时调用备选服务） - 日志记录（统一记录任务异常） **易踩坑点**： ⚠️ 未处理异常导致线程终止，错误日志丢失 ✅ 必须为每个异步链添加至少一个异常处理器 ### 2.4 多任务组合 ```java CompletableFuture<String> task1 = CompletableFuture.supplyAsync(...); CompletableFuture<String> task2 = CompletableFuture.supplyAsync(...); // 所有任务完成 CompletableFuture<Void> all = CompletableFuture.allOf(task1, task2); // 任一任务完成 CompletableFuture<Object> any = CompletableFuture.anyOf(task1, task2); // 结果合并 CompletableFuture<String> combined = task1.thenCombine(task2, (r1, r2) -> r1 + r2); ``` **方法族**： | 方法 | 说明 | |-------------------|--------------------------| | `allOf(CF...)` | 所有任务完成触发 | | `anyOf(CF...)` | 任一任务完成触发 | | `thenCombine` | 合并两个任务结果（BiFunction） | | `thenAcceptBoth` | 消费两个任务结果 | **场景**： - 聚合多个微服务结果 - 并行查询多个数据源 - 竞速操作（取最快响应） **易踩坑点**： ⚠️ `allOf` 返回 `CompletableFuture<Void>`，需手动获取子任务结果 ✅ 使用 Stream 收集结果： ```java CompletableFuture.allOf(task1, task2) .thenApply(v -> Stream.of(task1, task2) .map(CompletableFuture::join) .collect(Collectors.toList())); ``` ## 3. 高级特性 ### 3.1 超时控制 (Java 9+) ```java future.orTimeout(2, TimeUnit.SECONDS) // 超时抛出TimeoutException .completeOnTimeout("default", 2, TimeUnit.SECONDS); // 超时返回默认值 ``` ### 3.2 完成回调 ```java future.thenRun(() -> System.out.println("Done")) // 任务完成时触发 .thenRunAsync(() -> cleanResources()); // 异步清理资源 ``` ## 4. 性能优化建议 1. **线程池隔离**： ```java // CPU密集型 ExecutorService cpuPool = Executors.newWorkStealingPool(); // IO密集型 ExecutorService ioPool = Executors.newCachedThreadPool(); ``` 2. **避免阻塞**： ```java // 错误用法：阻塞调用线程 String result = future.get(); // 正确用法：异步回调 future.thenAccept(System.out::println); ``` 3. **资源释放**： ```java try (ExecutorService pool = Executors.newVirtualThreadPerTaskExecutor()) { CompletableFuture.runAsync(() -> {...}, pool); } // 自动关闭线程池 ``` ## 5. 典型应用场景 1. **微服务编排**： ```java CompletableFuture<User> userFuture = getUserAsync(id); CompletableFuture<Order> orderFuture = getOrdersAsync(id); userFuture.thenCombine(orderFuture, (user, orders) -> new UserProfile(user, orders) ); ``` 2. **批量异步处理**： ```java List<CompletableFuture<Void>> tasks = dataList.stream() .map(item -> CompletableFuture.runAsync( () -> process(item), bulkPool )) .collect(Collectors.toList()); CompletableFuture.allOf(tasks.toArray(new CompletableFuture[0])).join(); ``` 3. **超时熔断**： ```java CompletableFuture<String> serviceCall = remoteService.call() .orTimeout(500, TimeUnit.MILLISECONDS) .exceptionally(ex -> "Fallback"); ``` ## 6. 核心注意点 1. **线程泄漏**：未关闭自定义线程池导致OOM 2. **回调地狱**：过度嵌套降低可读性（可用`thenCompose`扁平化） 3. **异常传播**：中间步骤异常会跳过后续`thenApply` 4. **上下文丢失**：异步线程无法获取ThreadLocal值（需用`CompletableFuture`重载方法传递） 5. **死锁风险**：`get()`在异步任务内调用导致死锁 > 最佳实践：结合监控工具（如Micrometer）跟踪异步任务耗时和成功率[^2] [^1]: Java Concurrency in Practice [^2]: Resilience4j Circuit Breaker Documentation
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值