/proc/sys/kernel/pid_max，表示系统全局的 PID 号数值的限制，每一个进程或线程都有 ID，ID 的值超过这个数，进程或线程就会创建失败，默认值是 32768；
/proc/sys/vm/max_map_count，表示限制一个进程可以拥有的VMA(虚拟内存区域)的数量，具体什么意思我也没搞清楚，反正如果它的值很小，也会导致创建线程失败，默认值是 65530。
那接下针对我的测试服务器的配置，看下一个进程最多能创建多少个线程呢？
我在这台服务器跑了前面的程序，其结果如下：
可以看到，创建了 14374 个线程后，就无法在创建了，而且报错是因为资源的限制。
前面我提到的 threads-max 内核参数，它是限制系统里最大线程数，默认值是 14553。
我们可以运行那个测试线程数的程序后，看下当前系统的线程数是多少，可以通过 top -H 查看。
左上角的 Threads 的数量显示是 14553，与 threads-max 内核参数的值相同，所以我们可以认为是因为这个参数导致无法继续创建线程。
那么，我们可以把 threads-max 参数设置成 99999:
echo 99999 > /proc/sys/kernel/threads-max设置完 threads-max 参数后，我们重新跑测试线程数的程序，运行后结果如下图：
可以看到，当进程创建了 32326 个线程后，就无法继续创建里，且报错是无法继续申请内存。
此时的上限个数很接近 pid_max 内核参数的默认值（32768），那么我们可以尝试将这个参数设置为 99999：
echo 99999 > /proc/sys/kernel/pid_max设置完 pid_max 参数后，继续跑测试线程数的程序，运行后结果创建线程的个数还是一样卡在了 32768 了。
当时我也挺疑惑的，明明 pid_max 已经调整大后，为什么线程个数还是上不去呢？
后面经过查阅资料发现，max_map_count 这个内核参数也是需要调大的，但是它的数值与最大线程数之间有什么关系，我也不太明白，只是知道它的值是会限制创建线程个数的上限。
然后，我把 max_map_count 内核参数也设置成后 99999：
echo 99999 > /proc/sys/kernel/max_map_count继续跑测试线程数的程序，结果如下图：
当创建差不多 5 万个线程后，我的服务器就卡住不动了，CPU 都已经被占满了，毕竟这个是单核 CPU，所以现在是 CPU 的瓶颈了。
我只有这台服务器，如果你们有性能更强的服务器来测试的话，有兴趣的小伙伴可以去测试下。
接下来，我们换个思路测试下，把创建线程时分配的栈空间调大，比如调大为 100M，在大就会创建线程失败。
ulimit -s 1024000设置完后，跑测试线程的程序，其结果如下：
总共创建了 26390 个线程，然后就无法继续创建了，而且该进程的虚拟内存空间已经高达 25T，要知道这台服务器的物理内存才 2G。
为什么物理内存只有 2G，进程的虚拟内存却可以使用 25T 呢？
因为虚拟内存并不是全部都映射到物理内存的，程序是有局部性的特性，也就是某一个时间只会执行部分代码，所以只需要映射这部分程序就好。
你可以从上面那个 top 的截图看到，虽然进程虚拟空间很大，但是物理内存（RES）只有使用了 400 多M。
好了，简单总结下：
32 位系统，用户态的虚拟空间只有 3G，如果创建线程时分配的栈空间是 10M，那么一个进程最多只能创建 300 个左右的线程。
64 位系统，用户态的虚拟空间大到有 128T，理论上不会受虚拟内存大小的限制，而会受系统的参数或性能限制。
絮叨絮叨