接口逻辑中会调用 6,7 次外部接口查询数据，然后再把结果汇总。现在用的是 parallelStream 来分别调用这几个外部接口，但是效果貌似不太好。还有什么其他方法可以并行调用的？

之前用的 list.parallel.xxx 没有用自定义 ForkJoinPool ，改成自定义线程池后，貌似变好了些

Reactor 挺适合这种场景的

并行调用耗时就是最慢的那个接口, 这个角度没啥可优化的点了.

有点太复杂了，不太适合吧。我应用场景就是并发调用接口

实现不太一样吧，有时候还会碰到从连接池获取连接超时。。

主要是测试压测有个时延要求，p95 要到 50ms ，但是这个服务需要调用多个外部接口。没什么优化经验。。用了 parallelStream ，增大的连接池的 defaultMaxPerRoute 。效果不是太好，就在想是不是 parallelStream 有什么缺陷

建议不要用 parallelStream ，ForkJoinPool 是全局共用的。。

如果定义那个 ForkJoinPool 有啥问题么

你如果可以保证没有别人用 parallelStream ，那可以。要不然这种在 parallel 中进行 io 调用的，是可能会导致阻塞的

这种情况下，可以尝试自己定义线程池，然后用 CompletableFuture.supplyAsync ，配合 CompletableFuture.allOf(...).join() 等待线程结束获取结果。建议改完后压一波试试

Fibers + Channel

分布式

CompletableFuture?

多线程加阻塞同步器，怕并发太大可以塞信号量

这个用的是 forkjoin 公共线程池，你系统用的多，就可能排队阻塞

自定义线程池+CountDownLatch ，说到底总耗时还是取决于最慢的那个接口的响应时间。

可以自定义 ForkJoinPool

forkJoinPool.execute(e -> {
someList.parallelStream()
})

用 parallelStream 都会自定义 ForkJoinPool 吧，问题不大

先做好日志确认一下，确认是否「总用时~=耗时最长的外部服务」，如果是的话，就没什么优化的空间了，如果不是再排查吧，按理说这么做没问题。

查数据就是并发+缓存，没啥别的办法。

除非提前调用直接查 不然并行调用还是会以最慢的接口时间
如果因为网络或者机器位置的关系找运维给你加代理网关会好很多

这个没办法解决的，外部接口的调用时间在于别人服务器对你的响应时间。

提前聚合

最直接的解 CompletableFuture ，这玩意写起来贼恶心。
比较优雅的解 Kotlin 协程

无解，就算你的六七个接口都没有互相依赖，全并行一起请求外部，
访问外部来回 rtt 也是要耗时的，外部接口再稍微慢一点你的 p95 就到不了 50ms 了
除非把机房搬外部接口提供方机房旁边，不然跨一下地域轻轻松松就过 50ms 了，不过你这个 case 还有 6 ，7 次外部接口，也不知道是不是同一个提供商，不是的话机房都搬不动了

随便搜了一下时延的经验值
腾讯云：

北京到上海：38ms
上海到广州：40ms
北京到广州：53ms

com.jd.platform
asyncTool
1.4.1-SNAPSHOT

可以看一下这个，前段无意中发现的。
还没仔细看，貌似不错。

CompletionService 或者 CompletableFuture 挺好用的，还可以自己传入 ThreadPoolExecutor

p95 要到 50ms ， 你先确定下你依赖的那几个接口能到这个速度吗

项目里面真的好多 paralleStream 都没有自定义线程池。每个 parallel 都自定义一个是不是不太好
奇怪的是，每个并发流时间都不高，但是最终却很高，怀疑是用了共享线程池的缘故
我用的 CompletableFuture 然后自定义线程池，但是用了 get()方法,感觉就和 Future 差不多的样子

＃26 原理是差不多的，都是异步同时请求接口，而不是串行。只不过这种方式可以将任务丢进线程池，而不是每次 new 线程跑。
不过这种方式是否能满足你需求也是母鸡的。。毕竟这种聚合接口的耗时要看你依赖接口的

之前看过 linkedin/parseq ，看起来还行，没用过

现在改用 CompletableFuture 试试会不会好，实际用起来，感觉并发流不太好。

试试 nodejs(