ryeguy，我目前正在开发一个类似的应用程序，我的线程数设置为15。不幸的是，如果我把它增加到20，它就崩溃了。所以，是的，我认为处理这个问题的最好方法是测量您当前的配置是否允许多于或少于X个线程。

这个问题已经讨论得很透彻了，我还没有机会阅读所有的回答。但是，在查看可以在给定系统中和平共存的并发线程数量的上限时，有几件事需要考虑。

Thread Stack Size : In Linux the default thread stack size is 8MB (you can use ulimit -a to find it out). Max Virtual memory that a given OS variant supports. Linux Kernel 2.4 supports a memory address space of 2 GB. with Kernel 2.6 , I a bit bigger (3GB ) [1] shows the calculations for the max number of threads per given Max VM Supported. For 2.4 it turns out to be about 255 threads. for 2.6 the number is a bit larger. What kindda kernel scheduler you have . Comparing Linux 2.4 kernel scheduler with 2.6 , the later gives you a O(1) scheduling with no dependence upon number of tasks existing in a system while first one is more of a O(n). So also the SMP Capabilities of the kernel schedule also play a good role in max number of sustainable threads in a system.

现在，您可以调整堆栈大小以合并更多线程，但随后必须考虑线程管理的开销(创建/销毁和调度)。 您可以对给定进程和给定线程强制CPU Affinity，将它们绑定到特定的CPU上，以避免CPU之间的线程迁移开销，并避免冷现金问题。

请注意，一个人可以根据自己的意愿创建数千个线程，但是当Linux耗尽VM时，它只是随机地开始杀死进程(因此线程)。这是为了防止实用程序配置文件被刷爆。(效用函数表示给定资源数量的系统范围效用。在这种情况下，CPU周期和内存的资源不变，效用曲线会随着任务数量的增加而变平)。

我相信windows内核调度器也会做一些这样的事情来处理资源的过度使用

[1] http://adywicaksono.wordpress.com/2007/07/10/i-can-not-create-more-than-255-threads-on-linux-what-is-the-solutions/

正如帕克斯所说，衡量，而不是猜测。这就是我为DNSwitness所做的事情，结果令人惊讶:理想的线程数比我想象的要高得多，大约15,000个线程才能获得最快的结果。

当然，这取决于很多东西，这就是为什么你必须衡量自己。

在Combien de fils d'exécution ?中的完整测量(仅法语)。

我已经编写了大量多线程应用程序。我通常允许由配置文件指定潜在线程的数量。当我针对特定客户进行调优时，我将数值设置得足够高，以至于所有CPU核心的利用率都相当高，但还没有高到遇到内存问题(当时这些是32位操作系统)。

换句话说，一旦你达到某个瓶颈，比如CPU、数据库吞吐量、磁盘吞吐量等，添加更多的线程不会提高整体性能。但在达到这一点之前，请添加更多线程!

请注意，这是假设系统是专门为你的应用程序，你不需要很好地发挥(避免饥饿)其他应用程序。

在大多数情况下，您应该允许线程池处理这个问题。如果您发布一些代码或提供更多细节，可能更容易看到是否有某些原因导致线程池的默认行为不是最好的。

你可以在这里找到更多关于如何工作的信息:http://en.wikipedia.org/wiki/Thread_pool_pattern

和CPU内核一样多的线程是我经常听到的。