原文链接：http://jzhihui.iteye.com/blog/1271122
windows 操作系统中允许的最大线程数。
===========================================================================
默认情况下，一个线程的栈要预留1M的内存空间
而一个进程中可用的内存空间只有2G，所以理论上一个进程中最多可以开2048个线程
但是内存当然不可能完全拿来作线程的栈，所以实际数目要比这个值要小。
你也可以通过连接时修改默认栈大小，将其改的比较小，这样就可以多开一些线程。
如将默认栈的大小改成512K，这样理论上最多就可以开4096个线程。
即使物理内存再大，一个进程中可以起的线程总要受到2GB这个内存空间的限制。
比方说你的机器装了64GB物理内存，但每个进程的内存空间还是4GB，其中用户态可用的还是2GB。
如果是同一台机器内的话，能起多少线程也是受内存限制的。每个线程对象都要站用非页面内存，而
非页面内存也是有限的，当非页面内存被耗尽时，也就无法创建线程了。
如果物理内存非常大，同一台机器内可以跑的线程数目的限制值会越来越大。
在Windows下写个程序，一个进程Fork出2000个左右线程就会异常退出了，为什么？
这个问题的产生是因为windows32位系统，一个进程所能使用的最大虚拟内存为2G，而一个线程的
默认线程栈StackSize为1024K（1M），这样当线程数量逼近2000时，2000*1024K=2G（大约），
内存资源就相当于耗尽。
MSDN原文：
“The number of threads a process can create is limited by the available virtual memory.
By default， every thread has one megabyte of stack space. Therefore， you can create
at most 2，028 threads. If you reduce the default stack size， you can create more threads. However， your application will have better performance if you create one thread per
processor and build queues of requests for which the application maintains the context
information. A thread would process all requests in a queue before processing requests
in the next queue.”
如何突破2000个限制？
可以通过修改CreateThread参数来缩小线程栈StackSize
服务器端程序设计
如果你的服务器端程序设计成：来一个client连接请求则创建一个线程，那么就会存在2000个限制（在
硬件内存和CPU个数一定的情况下）。建议如下：
The “one thread per client” model is well-known not to scale beyond a dozen clients
or so. If you‘re going to be handling more than that many clients simultaneously，
you should move to a model where instead of dedicating a thread to a client， you
instead allocate an object. （Someday I’ll muse on the duality between threads and
objects.） Windows provides I/O completion ports and a thread pool to help you
convert from a thread-based model to a work-item-based model.
1. Serve many clients with each thread， and use nonblocking I/O and level-triggered
readiness notification
2. Serve many clients with each thread， and use nonblocking I/O and readiness
change notification
3. Serve many clients with each server thread， and use asynchronous I/O
--------------------
附：Win32将低区的2GB留给进程使用， 高区的2GB则留给系统使用。
Linux将高位1GB留给内核，低位3GB留给进程
linux系统中允许的最大线程数
==========================================================================================
JVM中可生成的最大Thread数量
JVM中可以生成的最大数量由JVM的堆内存大小、Thread的Stack内存大小、系统最大
可创建的线程数量（Java线程的实现是基于底层系统的线程机制来实现的，Windows下_beginthreadex，Linux下pthread_create）三个方面影响。
| -Xms | intial java heap size |
| -Xmx | maximum java heap size |
| -Xss | the stack size for each thread |
| 系统限制 | 系统最大可开线程数 |
- import java.util.concurrent.atomic.AtomicInteger;
- public class TestThread extends Thread {
- private static final AtomicInteger count = new AtomicInteger();
- public static void main(String[] args) {
- while (true)
- (new TestThread()).start();
- }
- @Override
- public void run() {
- System.out.println(count.incrementAndGet());
- while (true)
- try {
- Thread.sleep(Integer.MAX_VALUE);
- } catch (InterruptedException e) {
- break;
- }
- }
- }
测试环境：
系统：Ubuntu 10.04 Linux Kernel 2.6 （32位）
内存：2G
JDK：1.7
测试结果：
◆ 不考虑系统限制
| -Xms | -Xmx | -Xss | 结果 |
| 1024m | 1024m | 1024k | 1737 |
| 1024m | 1024m | 64k | 26077 |
| 512m | 512m | 64k | 31842 |
| 256m | 256m | 64k | 31842 |
在创建的线程数量达到31842个时，系统中无法创建任何线程。
由上面的测试结果可以看出增大堆内存（-Xms，-Xmx）会减少可创建的线程数量，增大线程栈内存
（-Xss，32位系统中此参数值最小为60K）也会减少可创建的线程数量。
◆ 结合系统限制
线程数量31842的限制是是由系统可以生成的最大线程数量决定的：/proc/sys/kernel/threads-max，
可其默认值是32080。修改其值为10000：echo 10000 > /proc/sys/kernel/threads-max，
修改后的测试结果如下：
| -Xms | -Xmx | -Xss | 结果 |
| 256m | 256m | 64k | 9761 |
这样的话，是不是意味着可以配置尽量多的线程？再做修改：echo 1000000 > /proc/sys/kernel/threads-max，
修改后的测试结果如下：
| -Xms | -Xmx | -Xss | 结果 |
| 256m | 256m | 64k | 32279 |
| 128m | 128m | 64k | 32279 |
发现线程数量在达到32279以后，不再增长。查了一下，32位Linux系统可创建的最大pid数是32678，
这个数值可以通过/proc/sys/kernel/pid_max来做修改（修改方法同threads-max），但是在32系
统下这个值只能改小，无法更大。在threads-max一定的情况下，修改pid_max对应的测试结果如下：
| pid_max | -Xms | -Xmx | -Xss | 结果 |
| 1000 | 128m | 128m | 64k | 582 |
| 10000 | 128m | 128m | 64k | 9507 |
在Windows上的情况应该类似，不过相比Linux，Windows上可创建的线程数量可能更少。基于线
总结：
JVM中可以生成的最大数量由JVM的堆内存大小、Thread的Stack内存大小、系统最大可创建的线程数量
（Java线程的实现是基于底层系统的线程机制来实现的，Windows下_beginthreadex，Linux下
pthread_create）三个方面影响。具体数量可以根据Java进程可以访问的最大内存（32位系统上一般2G）、
堆内存、Thread的Stack内存来估算。
序：
在64位Linux系统（CentOS 6， 3G内存）下测试，发现还有一个参数是会限制线程数量：
max user process（可通过ulimit –a查看，默认值1024，通过ulimit –u可以修改此值），
这个值在上面的32位Ubuntu测试环境下并无限制。
将threads-max，pid_max，max user process，这三个参数值都修改成100000，-Xms，
-Xmx尽量小（128m，64m），-Xss尽量小（64位下最小104k，可取值128k）。事先预测在
这样的测试环境下，线程数量就只会受限于测试环境的内存大小（3G），可是实际的测试结果是
线程数量在达到32K（32768，创建的数量最多的时候大概是33000左右）左右时JVM是抛出警告：
Attempt to allocate stack guard pages failed，然后出现OutOfMemoryError无法创建本
地线程。查看内存后发现还有很多空闲，所以应该不是内存容量的原因。Google此警告无果，
暂时不知什么原因，有待进一步研究。
序2：
今天无意中发现文章[7]，马上试了下，果然这个因素会影响线程创建数量，按文中描述把/proc/sys/vm/max_map_count的数量翻倍，从65536变为131072，创建的线程总数
量达到65000+，电脑基本要卡死（3G内存）… 简单查了下这个参数的作用，在[8]中的描述如下：
“This file contains the maximum number of memory map areas a process may have.
Memory map areas are used as a side-effect of calling malloc, directly by mmap and
mprotect, and also when loading shared libraries.
While most applications need less than a thousand maps, certain programs,
particularly malloc debuggers, may consume lots of them, e.g., up to one or two
maps per allocation.
The default value is 65536.”
OK，这个问题总算完满解决，最后总结下影响Java线程数量的因素：
Java虚拟机本身：-Xms，-Xmx，-Xss；
系统限制：
/proc/sys/kernel/pid_max，
/proc/sys/kernel/thread-max，
max_user_process（ulimit -u），
/proc/sys/vm/max_map_count。
参考资料：
1. http://blog.krecan.net/2010/04/07/how-many-threads-a-jvm-can-handle/
2. http://www.cyberciti.biz/tips/maximum-number-of-processes-linux-26-kernel-can-handle.html
3. http://geekomatic.ch/2010/11/24/1290630420000.html
4. http://stackoverflow.com/questions/763579/how-many-threads-can-a-java-vm-support
5. http://www.iteye.com/topic/1035818
6. http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html
7. https://listman.redhat.com/archives/phil-list/2003-August/msg00025.html
8. http://www.linuxinsight.com/proc_sys_vm_max_map_count.html
7483
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
