线程池默认多少个线程_我需要多少个线程？

线程池默认多少个线程

这取决于您的应用程序。但是，对于那些希望对如何从生产站点购买的所有昂贵内核中挤出大量资金的人，请多多包涵，我将阐明围绕多线程 Java应用程序的奥秘。

内容针对最典型的Java EE应用程序进行了“优化”，该应用程序具有Web前端，允许最终用户在应用程序内发起许多小交易。每个事务的很大一部分都在等待一些外部资源。例如从数据库或任何其他集成数据源返回的查询。但是大多数内容也与其他应用程序相关。例如繁重的计算建模应用程序或处理数据的批处理过程。 Multithreading

但是，让我们从基础开始。在我们描述的应用程序类型中，您倾向于有很多用户与您的应用程序进行交互。是成千上万同时活动的用户还是成千上万的用户–所有这些用户都希望应用程序及时响应他们。这就是您对操作系统设计人员感激的地方。在没有人想到HTTP协议之前，这些家伙就已经找到了解决这种需求的方法。

在您在软件中创建更多线程然后基础硬件可以同时执行的情况下，使用的解决方案很有用。在硬件级别上，您还具有线程。例如您CPU上的内核或具有超线程功能的虚拟化环境（如Intel）。无论如何，我们手头的应用程序很容易产生比基础硬件直接支持更多的软件线程。您的操作系统现在正在启动的内容类似于简单的循环调度。在此期间，每个软件线程轮流执行，称为时间片，以在实际硬件上运行。

时间分片允许所有线程进行。否则，很容易想象这样一种情况，其中一个用户发起了一项真正昂贵的任务，而为其他用户提供服务的所有其他线程却挨饿了。

因此，我们正在经历这个惊人的时间切片。那么将线程数设置为LARGE_NUMBER并完成该操作是否可行？显然没有。其中包括间接费用，实际上甚至包括几种间接费用。因此，为了在调整线程时做出明智的决定，让我们介绍一下由LARGE_NUMBER个线程一一导致的问题。

注册状态保存/恢复 。处理器寄存器确实包含很多状态。每当调度程序移至下一个任务时，哪个文件都会保存到缓存中。然后在时间到来时恢复。幸运的是，调度程序分配的时间片相对较大。因此，在多线程环境中，来往于注册表的保存/还原开销通常不会成为我们最卑鄙的敌人。

锁。当时间片被锁持有线程占用时，所有其他等待此特定锁的线程现在都必须等待。直到锁持有者得到另一片和释放锁的机会。因此，如果您正在进行大量同步，请检查线程在高负载下的行为。由于锁持有线程，您的同步代码有可能导致更多上下文切换。分析线程转储将是开始调查这一危险的好地方。

释放虚拟内存 。所有操作系统都利用交换到外部存储的虚拟内存。通过在需要时将内存中的最近最少使用（LRU）数据交换到磁盘驱动器。哪个好但是，如果您现在正在使用有限的内存运行应用程序，并且有很多线程在争夺将其堆栈和私有数据放入内存的空间，那么您可能会遇到问题。

在每个时间片回合中，您可能都有线程在外部存储中交换数据。这将大大降低应用程序的性能。尤其对于问题特别棘手的Java应用程序。每当您开始交换堆时，每次Full GC运行都将花费很长时间。一些专家建议关闭操作系统级别的交换功能。在Linux发行版中，您可以通过swapoff –a实现此目的。

但是，好消息是，过去几年该问题已大大减少。两者均具有广泛的64位OS部署，从而允许更大的RAM和SSD取代全球各地的传统旋转磁盘。但是要注意敌人，如果有疑问，请检查进程的页面进/出比例。

最后但并非最不重要的- 线程缓存状态 。在所有现代处理器中，您都在内核旁边构建了缓存，从而使操作完成速度比RAM中的数据快100倍。绝对很棒。但是不妙的是，当线程开始为这个极其有限的空间而战时。然后，负责清理的LRU算法再次开始清理缓存，为新数据腾出空间。这可能是其时间片中输入缓存的数据最后一个线程。因此，您的线程最终可能会从缓存中清除彼此的数据。再次造成了严重的问题。

如果您在Intel体系结构上运行，那么在这种情况下可能会帮助您的解决方案是Intel的VTune Performance Analyzer

因此，也许将LARGE_NUMBER个线程扔到您的应用程序配置中并不是最明智的选择。但是在配置线程数时可以给出什么提示？

首先，可以将某些应用程序配置为以等于基础硬件线程的线程数运行。那里的典型Web应用程序可能不是这种情况，但是肯定有很好的案例支持此策略。请注意，当您的线程在诸如关系数据库之类的外部资源后面等待时，这些线程将从循环调度中删除。因此，在典型的Java EE应用程序中，具有比基础硬件更多的线程并且仍在运行时不会出现锁争用或其他问题的情况并不少见。

接下来，将您的线程划分为用于不同目的的不同组是明智的。典型的情况是将计算线程与I / O线程分开。计算线程通常在大部分时间都处于繁忙状态，因此将其数量保持在底层硬件容量以下非常重要。另一方面，I / O线程（例如需要数据库往返的操作）大部分时间都在等待。因此，不会过于频繁地为争取资源做出贡献。因此，使I / O线程（方式）的数量大于支持您的应用程序的硬件线程的数量是安全的。

然后，应最小化线程的创建和销毁。由于这些操作往往很昂贵，因此请查看合并解决方案。您可能正在使用已经内置了线程池的Java EE基础结构，或者可以查看java.util.concurrent.ThreadPoolExecutor之类的解决方案。但是，当您有时需要增加或减少线程数时，也不要太害羞–只需避免在与下一个HTTP请求或JDBC连接一样可预测的事件上创建和删除它们。

作为最后的建议，我们将提供最重要的建议。测量。调整线程池的大小，并在负载下运行应用程序。测量吞吐量和延迟。然后进行优化以实现您的目标。然后再次测量。冲洗并重复。直到您对结果满意为止。

不要对CPU的性能做任何假设。如今，CPU中发生的魔力数量巨大。还要注意，虚拟化和JIT运行时优化也会增加额外的复杂性。但是这些将成为另一个话题。如果您订阅我们的Twitter feed ，将会及时收到通知。

在撰写本文时，以下资源被用作灵感来源：