Java 同时调用 5000 个第三方接口并异步返回每个接口的执行结果，如何实现？

固件升级不是应该目标机器自己定时来检查是否有新固件版本吗？然后有新版本自己升级

消息队列放 5000 个任务，多台机器慢慢消费吧

异步要全程异步才有用，“每个接口的执行时间大概在 5 分钟以上”这个同步过程，注定了你在其他地方怎么异步都没作用。所以，在上面这个同步过程无法更改的情况下，全程同步反而会更节省资源。就简单的单线程或多线程依次同步执行即可。找个好点的机器，5000 个线程同时执行也不是问题。事实上这 5000 个线程因为绝大部分时间都是在等接口返回结果，消耗不了多少 CPU ，只是需要一些内存。

用个 NIO 实现的异步 http client 的做就行了吧，就像 webflux ，IO 异步调用不需要太多的线程

别用 java 干这事儿了，还是 go 一把梭了。java 的 nio 和 reactive 国内案例太少了，不知道实际效果怎么样，flink 、spark 、airflow 这些倒是有用 akka 做任务调度，也许可以试试。

1.关注下机房总带宽是否够，如果不够，你还是不能一次搞 5 千个并发
2.搞 manager+agnet 机器咯，manger 负责下发指令给 agent ，agent 负责 http 更新操作，理论上只要你 agent 够多，带宽够大，5 万个并发都不是问题。
最后，别想这么多，直接干，出问题再想办法解决。

如果是 C#的话，这个需求可太简单了。
const int length = 5000;
var tasks = new Task<HttpResponseMessage>[length];
for (int i = 0; i < length; i++)
{
tasks[i] = new HttpClient().GetAsync("https://www.baidu.com");
}

// 等待全部执行完
var responseArrays = await Task.WhenAll(tasks);
// 做余下处理就行了

可以尝试工作窃取算法处理

37 楼那个是通常的做法；然后，如果客户端做不到这点，你这里也无法做到 5000 个并发，就一批一批的做呗

这种活直接用 goroutine

让 5000 设备主动 pull 升级包就行了
你折腾啥并发
自己 pulll ，自己升级自己
启动时候给你 report 一下自己版本就行了

@litguy 确实 我感觉这种更好

用 Go 协程写个小工具就行

Janino
http://janino-compiler.github.io/janino/

The ShippingCost class demonstrates how easy it is to use Janino as an expression evaluator.
The ExpressionDemo class implements a command line-based test environment for the expression evaluator.
The ScriptDemo class implements a command line-based test environment for the script evaluator.
The ClassBodyDemo class implements a command line-based test environment for the class body evaluator.

shell 脚本就够用

@jorneyr 原来是这样的，你说得有道理，受教了。

@winglight2016 Netty：？？？我这是在哪里？

消息队列

就是自动升级主板 bios 吧，五分钟的升级不代表上传数据得花这么久时间呀，几秒钟传文件就完事了，然后轮询去检查固件更新是否完成，可以考虑分批次上传固件，检查更新状态单独处理，如果 java 不好处理可以使用 python 的协程网络库来单独处理固件上传的功能，其实这跟 python 爬虫很相似，都是并发的 tcp 客户端请求，netty 也能很好实现就能难度比较大。

@touchmii 上传固件包确实很快啊，但升级确实需要 3-5 分钟，现在是用 Java 的 CompletableFuture 并行处理的，已经基本实现功能了