大并发服务器设计下的一些常见的linux问题

1.Linux能同时启动多少个线程？

对于 32-bit Linux，一个进程的地址空间是 4G，其中用户态能访问 3G 左右，一个线程的默认栈 (stack) 大小是 8M，所以一个进程大约最多能同时启动 350 个线程左右。有的地方说一个线程的默认栈大小是10M，反正如果口算的话，把8M看成10M，把1G=1024M近似看成是1000M,所以是3*1000除以10=300，所以约为300多个。

2.多线程能提高并发度吗？

如果指的是“并发连接数”，不能。假如单纯采用 thread per connection 的模型，那么并发连接数大约350，这远远低于基于事件的单线程程序所能轻松达到的并发连接数（几千上万，甚至几万）。所谓“基于事件”，指的是用 IO multiplexing event loop 的编程模型，又称 Reactor 模式。

3.多线程能提高吞吐量吗？所谓的吞吐量就是一次性能测试中处理网络上传输的数据量的总和。反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值

对于计算密集型服务，不能。

如果要在一个8核的机器上压缩100个1G的文本文件，每个core的处理能力为200MB/s，那么“每次创建8个进程，一个进程压缩一个文件（这种事进程里面没有线程）”与“只启动一个进程（进程里有8个线程并发压缩一个文件）”，这两种方式总耗时相当，但是第二种方式能较快的拿到第一个压缩完的文件。8个进程分别压缩8个文件，而只启动一个进程是8个线程并行处理，比较快。

4.多线程能提高响应时间吗？

可以。问题3说明了多线程可以较快拿到第一个压缩完的文件，就说明了这一点。

5.多线程如何让IO和计算重叠，降低latency(延迟)

比如说日志（logging），多个线程写日志，由于文件操作比较慢，服务线程会等在IO上，而cpu处于空闲，增加了响应时间，

解决办法：单独用一个logging线程专门负责磁盘IO，比如说写磁盘文件，而其他线程只管往这个日志线程中发送日志信息（比如说通过一个有锁对列（Blockqueue提供接口））别的线程要写日志的时候网队列一塞就行吗，然后由日志线程从队列中取出并负责将要写日志的线程写了，这样服务线程的计算和日志线程的IO就重叠了。

当然如果有成熟的protator模式，可以采用。

6、线程池大小的选择

如果池中执行任务时，密集计算所占时间比重为P（0<P<=1)，而系统一共有C个CPU，为了让C个CPU跑满而不过载，线程池大小的经验公式T=C/P，即T*P=C（让CPU刚好跑满 ）

假设C=8，P=1.0，线程池的任务完全密集计算，只要8个活动线程就能让CPU饱和

假设C=8，P=0.5，线程池的任务有一半是计算，一半是IO，那么T=16，也就是16个“50%繁忙的线程”能让8个CPU忙个不停。

7、线程分类

I/O线程（这里特指网络I/O）（进行IO操作的线程）
计算线程(比较耗费CPU)
第三方库所用线程，如logging,又比如database