Java+Moshi环境下REST API串行调用性能优化方案咨询

现有代码全部使用OkHttp同步阻塞execute()方法执行请求，6次请求完全串行执行，叠加每次HTTP请求的往返开销、TCP连接开销，导致整体耗时偏高。已知两组任务内部串行依赖，组间无依赖，除开多线程执行一组的方案外，还有以下更优的客户端侧优化方案：

1. 采用异步非阻塞调用+任务编排 #

当前使用的OkHttp本身支持异步enqueue()调用，不需要额外开辟线程阻塞等待响应，结合CompletableFuture编排两组依赖链，能最大化利用CPU资源，避免线程阻塞浪费：

• 第一组依赖链：创建用户→生成仓库→转移仓库，内部强依赖必须串行
• 第二组依赖链：查询当前用户组织→创建组织内团队→添加团队成员，仅需要用户名参数，可和第一组完全并行执行

示例异步改造代码如下：

// 改造同步方法为异步返回CompletableFuture
private CompletableFuture<Optional<User>> createUserAccountAsync(CreateUserOption account, String tokenValue) {
    CompletableFuture<Optional<User>> future = new CompletableFuture<>();
    log.debug(":::: createUserAccount : {}", account.toString());

    String postBody = createUserOptionJsonAdapter.toJson(account);
    okhttp3.RequestBody body = okhttp3.RequestBody.create(postBody, okhttp3.MediaType.parse("application/json"));
    Request request = new Request.Builder()
        .url(apiBaseurl + "/admin/users")
        .header("User-Agent", "OkHttp Headers.java")
        .addHeader("Accept", MediaType.APPLICATION_JSON.toString())
        .addHeader("Authorization", "token " + tokenValue)
        .post(body)
        .build();

    client.newCall(request).enqueue(new Callback() {
        @Override
        public void onFailure(Call call, IOException ioe) {
            log.error(ioe.getMessage());
            future.complete(Optional.empty());
        }

        @Override
        public void onResponse(Call call, Response response) throws IOException {
            try {
                if (!response.isSuccessful()) {
                    log.error(response.code() + " - " + response.message());
                    future.complete(Optional.empty());
                    return;
                }
                User user = giteaUserJsonAdapter.fromJson(response.body().string());
                future.complete(Optional.of(user));
            } finally {
                response.close();
            }
        }
    });
    return future;
}

// 两组任务并行编排
// 第一组串行任务
CompletableFuture<Boolean> group1 = createUserAccountAsync(createUserOption, tokenValue)
    .thenCompose(userOpt -> {
        if (userOpt.isEmpty()) return CompletableFuture.completedFuture(false);
        return generateRepoAsync(generateRepoOption, templateOwner, templateName, tokenValue);
    })
    .thenCompose(repoOpt -> {
        if (repoOpt.isEmpty()) return CompletableFuture.completedFuture(false);
        return transferRepoAsync(transferRepoOption, repoOpt.get().getOwner().getLogin(), repoOpt.get().getName(), tokenValue)
            .thenApply(transferOpt -> transferOpt.isPresent());
    });

// 第二组串行任务，和第一组并行执行
CompletableFuture<Void> group2 = getOrganizationsOfCurrentUserAsync(tokenValue)
    .thenAccept(orgs -> {
        if (orgs.isEmpty()) return;
        createTeamInOrganizationAsync(new CreateTeamOption("t-" + username), orgs.get(0).getUsername(), tokenValue)
            .thenAccept(teamOpt -> {
                if (teamOpt.isPresent()) {
                    addTeamMemberAsync(teamOpt.get().getId(), username, tokenValue);
                }
            });
    });

// 等待两组任务完成
CompletableFuture.allOf(group1, group2).join();
return group1.get();

2. HTTP连接复用优化 #

• 确保全局使用单例OkHttpClient实例，不要每次请求新建客户端，OkHttp默认自带连接池，会自动复用TCP连接，省去每次请求的TCP握手开销，同机部署场景下优化效果尤其明显
• 可根据业务调用量级手动调整连接池参数，比如调大maxIdleConnections（最大空闲连接数）、延长keepAliveDuration（连接存活时间），适配高频调用场景

// 自定义连接池示例
ConnectionPool pool = new ConnectionPool(20, 5, TimeUnit.MINUTES);
OkHttpClient client = new OkHttpClient.Builder()
    .connectionPool(pool)
    .connectTimeout(3, TimeUnit.SECONDS)
    .readTimeout(5, TimeUnit.SECONDS)
    .build();

3. 减少冗余开销 #

• 固定请求头（比如Accept: application/json、Authorization公共前缀、User-Agent）可以通过OkHttp全局拦截器统一添加，不用每次请求重复设置，减少冗余代码同时降低重复对象创建开销
• Moshi的序列化/反序列化适配器提前预缓存为全局单例，不要每次请求动态创建适配器
• 开启OkHttp的响应缓存，对于GET类的幂等请求（比如查询组织列表），如果返回结果不常变，可以配置本地缓存，避免重复请求服务端

4. 失败重试与超时优化 #

• 给OkHttp配置合理的连接超时、读取超时时间，避免异常请求卡住整条链路
• 给幂等接口（比如查询组织、添加成员）配置自动重试机制，减少偶发网络波动导致的整体流程失败重跑的开销

5. 接口合并（如有服务端修改权限） #

如果可以协调服务端新增批量接口，把组内串行的3次调用合并成一个批量处理接口，直接把单组的3次HTTP往返开销降到1次，是收益最高的优化方案。

内容的提问来源于stack exchange，提问作者vic