V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
This topic created in 2790 days ago, the information mentioned may be changed or developed.
最近跟一个同事聊天时，同事说之前在某 BAT 大厂实习后台开发时，做一个接口如果用多线程，数量都是 4000 个线程起，我对此表示怀疑。因为据我的认知，线程数量一般开到 CPU 核心数最好，最好不要超过 2 倍 CPU 核心数。因此，想请教下给为大佬，实际生产中用到的高并发的情况，真的能开这么多线程吗？
 |
1
Tinet Sep 17, 2018
你确定他说的不是协程
|
 |
2
lirau Sep 17, 2018
|
 |
3
reus Sep 17, 2018
可能说的是集群分配给这个接口的数量吧，单机开这么多没意义。
|
 |
4
dingzs3 Sep 17, 2018
这个估计就是不靠谱的，单机如果线程数过多，会产生太多的上下文切换开销和调度的开销，还有就是如果 cpu 迁移导致的缓存失效代价。
|
 |
5
lhy360121 Sep 17, 2018
能。
和 cpu 核心数一致的或 2 倍的应该是进程，不是线程。 高配的机器可以开到几百或上千的线程。 还和开发语言和业务场景有过。 |
 |
6
chocotan Sep 17, 2018
看是 cpu 密集还是 io 密集
|
1 |
8
lhy360121 Sep 17, 2018
|
 |
9
georgetso Sep 17, 2018
 |
 |
10
xylophone21 Sep 17, 2018
粗略来说，你的认知没错，但有前提。
其前提是（类似） Nginx 中的那种异步模型，这种方式下，一个线程（进程）可以服务多个请求，由于每个线程实际上都很忙，所以超过 CPU 个数太多反而不好，增加上下文切换的消耗。这种方式性能很高，但代码写起来困难，因为相当于你手工处理了操作体统上下文切换的事情，但处理的不那么特化，只适应当前一种场景。 在这种模型出现之前，流行的是多线程 /进程模型，一个线程 /进程为一个连接服务，每个线程大多数时候都在等待 IO，所以开的比 CPU 核心数多的多也没关系，也不得不开。这样的代码写起来非常简单，因为操作系统帮你隔离了每个请求之间的上下文切换，但性能就差一些，因为这种上下文切换很重，很通用，做了超出预期的事。 再进一步，协程又平衡了两种方式，这是题外话。 |
 |
11
dychenyi Sep 17, 2018
都没错。
理解的问题。 你的线程是 cpu 密集型。 他的线程是 IO 密集型。 好比你写个 socket server 端，client 端可以连进来，设计成一个线程处理一个 client。 那么最起码能连几百个 client 端就需要几百个线程了。 |
 |
12
q397064399 Sep 17, 2018
当然可以.. 实际上拿线程池抗压 又不是没干过，因为后端大部分时候 都阻塞在网络 IO 数据库网络 IO 等等上面，
其实实际的计算负载很低的.. |
 |
13
catror Sep 17, 2018 via Android
看业务场景来决定
|
 |
14
Allianzcortex Sep 17, 2018
@xylophone21 @lhy360121 @ayonel 我理解的 [线程数量一般开到 CPU 核心数最好，最好不要超过 2 倍 CPU 核心数] 这句话的产生是因为 Intel 可以让一个实体 CPU 模拟出两倍逻辑 CPU...但具体使用场景里线程数量应该没有什么固定的 best pramater，参考 https://www.quora.com/How-can-I-tell-how-many-processes-are-too-many-on-a-Linux-machine 里的回答， [Linux scales very well with the number of processes on a system, Thus there isn't a definitive answer to how many processes are "too many." ] ，所以系统目标是 system load 要小，这个时候 number of processes 只是一个考量因素，memory 与 I/O bandwidth 也算，就需要不断调优数值，和 @chocotan 说的 CPU-bound 还是 I/O-bound 系统有很大关系。但线程最大值不会超过 $kernel.pid_max。如果有不对的话麻烦大家指出来改一下哈😄
|
 |
15
zsdroid Sep 17, 2018
 |
 |
17
sagaxu Sep 17, 2018 via Android
2 倍说的是 running 状态的线程，idle 的不算。运行队列深度不要超过 cpu 核心数的 2 倍，否则会有明显的性能下降。
idle 线程就算有几千个，也不会对性能有很大的影响。业务逻辑大都是同步阻塞模型，堆线程或者进程，十几年前，高校基于 telnet 协议的 bbs，每个在线用户对应一个进程，1 万在线就是 1 万个进程，当年配置很一般的服务器，也能搞定几千在线。 |
 |
18
linshuang Sep 17, 2018
1、前面那些拿网络 IO 跟服务器说事的，看看这句话吧——“做一个接口如果用多线程，数量都是 4000 个线程起”。都说是做接口了，明显跟这些玩意基本都不搭噶了，那些东西对他来说都是透明的。
2、万一说他写个接口真的是需要（协调）处理到网络 IO，只能说不愧大厂（啥都从头来），那样确实是需要开很多线程。 3、还有一种就是开线程花很少钱，但往往都是语言层面自带的，语言使用的是用户线程 |
 |
19
wysnylc Sep 17, 2018
IO 密集型开 10000 个我觉得也行
|
 |
20
xvhfeng Sep 18, 2018
这个问题？哪位同学用的是大型机吗？
线程和进程，基本的问题在于 OS 的支持，一般来说，不管你是 IO 密集型还是 CPU 密集型都不会开到 4000 个线程。就目前互联网企业尿性来说，机器不要说开到 4000 个线程，一般的接口开到 2000 线程都会有点累（注意，我说的是一般的接口）。从 OS 来说，4k 线程上下文的交换可能浪费掉了它原本 80%的性能，有点得不偿失。如果是 IO 密集型操作，完全可以不用走 CPU，应该也用不着 4k 线程来处理这些。如果 IO 密集型不走特殊硬件处理，那么应该也是多线程挂载多 event，然后通过生命周期将其操作拆开，这种方式才相对合理。否则别的请求不是都得饿死吗？ 所以，这哥们可能只是酒桌上的一个玩笑，或者...... 好吧，还是要回去多看看 OS 的书。 |
 |
21
ayonel OP 多谢各位大佬的回复，受益匪浅
|
Select Language