这是一个创建于 1079 天前的主题，其中的信息可能已经有所发展或是发生改变。
试过了 parallelStream 和多个 CompletableFuture 的 join ，发现性能差别不是很大。大神们还有啥好的实践方法麽？
第 1 条附言 · 2021-11-26 08:50:27 +08:00
踩了个坑，涉及到网络 io 的时候，还要注意下 http 连接池的配置，尤其是 maxTotal 和 defaultMaxPerRoute ，这玩意和线程池配置不当，容易卡在获取连接那。。。
 |
1
cxshun 2021-11-25 09:25:56 +08:00
ParallelStream 实际上底层也是维护自己的 ForkjoinPool ，如果你说的多个，多到超过 CPU 核数，那可能定义自己的 ForkjoinPool 去提交 ParallelStream 会更合适点。
如果觉得 ParallelStream 那种 WorkSteal 的方式对你不大适用，那直接使用多线程就行了。 PS：性能差别本来这两种就是类似的。但如果你发现并行和串行差别不大，那就要考虑是不是业务提供方性能不行。 |
 |
2
awalkingman 2021-11-25 09:28:04 +08:00
自己维护个线程池，异步并发去请求多个接口。用 parallelStream 和 CompletableFuture 貌似都是全局的池子
|
 |
3
tairan2006 2021-11-25 09:31:57 +08:00
CompletableFuture 可以注入自定义的线程池
|
 |
4
admol 2021-11-25 09:32:56 +08:00
CompletableFuture 可以指定自定义的线程池
|
 |
5
luxinfl OP |
|
6
luxinfl OP @cxshun 现在采用的就是多个 CF 的写法，然后一起 join ，等待所有接口调用完毕才走到下一步。提供方的接口性能确实也不好。我也怀疑是不是网络时延太高，h 都是 http 调用
|
 |
8
chengyulong 2021-11-25 09:52:23 +08:00
提供方接口如果性能不好 就是搞再多的异步也不好使,考虑换对接方式吧
|
 |
9
sagaxu 2021-11-25 09:53:49 +08:00 via Android
看看总耗时比最耗时的接口长多少，接口耗时是没办法的
|
 |
10
ixx 2021-11-25 10:07:33 +08:00
差别不大可能是请求处理时间本身就很快
|
 |
11
golangLover 2021-11-25 10:39:37 +08:00 via Android
你以前好像已经问过了吧
|
|
12
luxinfl OP |
|
13
luxinfl OP @golangLover 发过类似的，仅仅是使用方法
|
 |
14
fdgdbr 2021-11-25 10:47:07 +08:00
@luxinfl #12 虽然我觉得异步的方式不会引起耗时增加，但是你这么怀疑的话，那就用同步的方式依次调用，把每次调用的耗时都打出来，不就能验证你的怀疑了
|
 |
15
yidinghe 2021-11-25 11:00:37 +08:00 via Android
问楼主个不相干的问题，为什么要把“如何”打成“如果”？这是拼音容易打错还是五笔容易打错？
|
 |
16
OkabeRintaro 2021-11-25 15:10:45 +08:00
@yidinghe 语音输入吧
|
 |
19
ainimuyan 2021-11-26 14:22:50 +08:00
|
Select Language