在java中，应用程序中CPU核心数与线程数之间的关系是什么？
我是java multithreading编程的新手。 我想到的问题是我可以根据CPU核心数运行多少个线程。 如果我运行线程超过CPU核心将是机器运行应用程序的开销。 例如，当我们的服务器机器有一个运行2个线程的服务器软件（主线程+开发人员线程）时，当更多的并发客户端与服务器建立套接字连接时，它是否会成为服务器的开销？
谢谢。
系统可以同时执行的线程数（当然）与系统中的核心数相同。
系统上可以存在的线程数受可用内存的限制（每个线程需要一个堆栈和操作系统用来管理线程的结构），并且可能存在操作系统允许的线程数限制（这取决于在OS体系结构上，某些操作系统可能会使用固定大小的表，一旦完整，就不能创建更多的线程。
通常，今天的计算机可以处理数百到数千个线程。
系统中存在比核心使用更multithreading的原因是：大多数线程将不可避免地花费大量时间等待某些事件（例如：字处理器等待用户在键盘上键入）。 操作系统管理它以这种方式等待的线程不消耗CPU时间。
这取决于线程正在做什么。 CPU只能同时执行X事务，其中X是它拥有的核心数。 这意味着X线程最多可以在任何时候处于活动状态 – 但是其他线程可以等待轮到它们，CPU会在适当的时刻处理它们。
您还应该考虑很多时候线程正在等待响应，或者等待数据加载，或者网络消息到达等等，所以实际上并没有尝试做任何事情。 这些空闲/等待线程对系统的负载非常小。
不要担心获得比CPU核心更多的线程; 实际上并不在你的手中，而是在操作系统中。
假设JVM通过OS线程映射你的java线程（这些天很平常），它取决于你的操作系统的线程管理。 在那里，您依赖于内核实现的智能程度，以便从内核中获得性能。
你必须记住的是你的设计必须是可持续的。 例如，应用程序服务器构建在充满工作线程的线程池上。 唤醒这些线程以满足请求。 你想为每个请求一个线程吗？ 然后你肯定会有一个问题 – 请求可以成千上万地到达服务器，这可能是内核管理的问题。 实际上线程池大小应该是有限的（在1和X之间，甚至可以在实时中轻松更改），线程应该从并发队列中获得工作（java为您提供了一些优秀的类），并且每个队列都按顺序处理请求。
我希望能得到帮助
它背后的想法是不要让你的CPU睡眠，也不要加载它太多，以至于它在线程切换中浪费了大部分时间。
在IBM的论文中，它有助于检查调整池的大小
背后的想法是，它取决于任务的性质，如果它的所有内存计算任务都可以使用N + 1个线程（N个核心数（包括超线程））。
要么
考虑到CPU的100％利用率，我们需要进行应用程序分析并找出典型请求的等待时间（WT），服务时间（ST）以及我们可以拥有的大约N *（1 + WT / ST）个最佳线程数量。
线程少于CPU可能意味着您没有使用系统中的所有CPU。 如果CPU是您的瓶颈，拥有更multithreading可能会提高吞吐量。
拥有比CPU更多的线程会带来开销，如果CPU是你的瓶颈，这可能会损害性能。 但是，如果网络IO是您的瓶颈，这种开销是值得付出的代价，因为它通常允许您处理更多连接。 例如，您可以使用自己的线程拥有1000个TCP连接。
最佳性能将是当核心数（ NOC ）等于线程数（ NOT ）时，因为如果NOT> NOC则处理器应该切换上下文或OS将尝试执行该工作，这是足够昂贵的操作。 但是你必须明白，在Web服务器上不可能有NOC = NOT，因为你无法预测同时会有多少客户端。 看一下负载均衡概念，以最佳方式解决此问题。