我有一个程序启动并创建一个内存数据模型，然后创建一个（命令行指定的）线程数，以针对输入集和该数据模型运行多个字符串检查算法。工作分为沿输入字符串集的线程，然后每个线程迭代相同的内存中数据模型实例（永远不会再次更新，因此没有同步问题）。
我在具有2个四核处理器的Windows 2003 64位服务器上运行它，并且从查看Windows任务管理器时，他们没有被淘汰，（他们看起来也不像他们被特别征税）我用10个线程运行。这是正常行为吗？
看来7个线程在相似的时间内完成了相似的工作量，所以你建议用7个线程运行吗？
我应该用更多的线程来运行吗？...虽然我认为这可能是有害的，因为JVM会在线程之间进行更多的上下文切换。
或者，我应该用更少的线程运行吗？
或者，什么是我可以用来衡量这个的最佳工具？...一个分析工具会帮助我在这里 - 实际上，是几个更好地检测瓶颈的假设之一（假设我有一个）比其余的？
注意，服务器也在运行SQL Server 2005（这可能相关也可能不相关），但是当我运行程序时，该数据库上没有发生任何事情。
另请注意，线程只进行字符串匹配，它们不进行任何I / O或数据库工作或者他们可能需要等待的任何其他内容。
答案 0 :(得分：5)
我的猜测是你的应用程序在内存访问方面存在瓶颈，即你的CPU内核花费大部分时间等待从主内存中读取数据。我不确定剖析器能够很好地诊断出这种问题（剖析器本身可能会大大影响行为）。您可以通过让代码在非常小的数据集上重复多次操作来验证猜测。
如果这个猜测是正确的，你唯一可以做的就是（除了获得具有更多内存带宽的服务器之外）是尝试增加内存访问的位置以更好地利用缓存;但取决于可能无法实现的应用程序的详细信息。由于内核共享缓存，因此使用更多线程可能会导致性能下降。
答案 1 :(得分：2)
如果没有看到实际的代码，很难给出适当的建议。但是要确保线程没有锁定共享资源，因为这自然会阻止它们尽可能高效地工作。另外，当你说他们没有做任何io时，他们是不是在阅读输入或写输出？这也可能是一个瓶颈。
关于cpu密集型线程，运行比实际内核更多的线程通常没有好处，但是在这样一个不受控制的环境中同时运行其他大型应用程序，你可能最好只是测试你的通往最佳线程数的方法。