当尝试确定 Java 数据处理服务器中的任务应如何分解时，我需要知道对于 ExecutorService 来说有多少 Future 过多。
据我了解，ExecutorServices 拥有一个重量级线程池，可以像处理绿色线程一样处理 Future，这意味着在 Future 之间执行上下文切换的成本非常小。这是真的吗？
我应该向 ExecutorService 提交数百万个 Future(使用池中固定数量的线程)吗？
我是否可以期望将许多非常短暂的 Future(10 毫秒)提交到 Executor 服务中而不会出现严重的性能下降？
最佳答案
您正在混淆 Future ，它表示具有 Thread 的异步操作的可能结果它代表对 Callable 执行处理的能力(至少在 Executor 的情况下)。
没有什么可以阻止您调用 submit在线程池上数百万次并获得一个巨大的列表 Future供你等待的对象。如果应用程序继续运行，您甚至不需要等待它们完成，并且您不需要处理结果。
但是。
如果您创建所有这些作业，它们将需要内存来保存其状态。如果该内存在某种程度上是作业输入的一部分，或者是执行作业的结果，那么您将向所有这些任务提交堆空间。你不能永远这样做。从本质上讲，如果您要将大量工作放入后台运行的进程中，您需要考虑某种限制。
关于java - 在 Java 中，多少个 Future 才算太多？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/63941131/