我的方法是否符合线程池方法

一如既往地没有细节，这取决于情况。

您是从磁盘加载对象还是在内存中创建对象？如果你从磁盘加载它们，那么它可能是IO绑定的，所以增加线程数量可能不会有多大帮助。

在您提到的注释中，您正在从数据库加载。我想，当你使用线程时，你会同时进行N个查询吗？可能值得研究一下数据库控制台，以了解它是如何处理许多并发查询的。

另一方面，如果对象是作为某个CPU绑定进程（例如计算pi）的结果创建的，那么增加线程数量的可能性可能比CPU数量更大，这可能不会提高性能（正如ronag在评论中指出的那样，由于上下文切换的增加，可能会损害性能）。

对象之间是否存在依赖关系？这将再次影响事情的发展。

如果您有一组独立的任务，希望以可配置的方式运行这些任务，则通常会使用线程池。听起来，使用线程池是运行具有各种线程设置的大量基准测试的好方法。您还可以配置线程的数量，这将有助于在不同的体系结构/系统上运行。

IME和您的IME，几个线程将加快这类任务的速度。我猜，由于更好地使用了现代控制器上可用的"智能"磁盘缓存，总体吞吐量得到了提高——磁盘/控制器空闲时间减少了，因为总是有线程想要读取某些内容。然而，在只加载了几个线程并且您已绑定到磁盘之后，回报就会递减。在一个稍微相似的应用程序中，我发现任何超过6个线程都没有提供额外的优势&只是占用了更多的内存。

我看不出这些线程的池化或其他方式会对性能产生什么影响——这只是一项必须完成的艰巨工作：（

告诉您的客户他们必须安装SSD

Rgds，Martin