Yes, to increase the threads number you need to increase the virtual memory or decrease the stack size. In Raspberry Pi I didn’t find a way to increase the virtual memory, if a decrease the stack size from default 8MB to 1MB It is possibly get more than 1000 threads per process but decrease the stack size with the “ulimit -s” command make this for all threads. So, my solution was use “pthread_t” instance “thread class” because the pthread_t let me set the stack size per each thread. Finally, I am available to archive more than 1000 threads per process in Raspberry Pi each one with 1MB of stack.

我认为我们错过了另一个限制，它也会阻止新线程的创建，这是内核。pid_max极限。

root@myhost:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.7 LTS
Release:    16.04
Codename:   xenial
root@myhost:~# uname -a
Linux myhost 4.4.0-190-generic #220-Ubuntu SMP Fri Aug 28 23:02:15 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

我发现至少在我的系统中，这个阈值核。Pid_max是32768。当我启动任何简单的JVM进程时，它会报告如下错误:

java/jstack/jstat ...
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Cannot create GC thread. Out of system resources.
# An error report file with more information is saved as:
# /root/hs_err_pid1390.log

检查内存是否充足。

root@lascorehadoop-15a32:~# free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G         11G         41G        1.2G         72G        111G
Swap:            0B          0B          0B

检查系统线程:

~# ps -eLf|wc -l
31506

但是我用ulimit检查系统限制:

root@myhost:~# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 515471
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 98000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 515471
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

从ulimit输出中，我们可以看到当前线程数远远小于最大用户进程限制。

实际上，所达到的极限是kernel.pid_max

非常容易检查和调整: https://www.cyberciti.biz/tips/howto-linux-increase-pid-limits.html

线程数限制:

$ cat /proc/sys/kernel/threads-max 

计算方法:

max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);

和: x86_64页大小(PAGE_SIZE)为4K; 像所有其他体系结构一样，x86_64为每个活动线程都有一个内核堆栈。这些线程栈是THREAD_SIZE (2*PAGE_SIZE)大;

备忘录:

cat /proc/zoneinfo | grep spanned | awk '{totalpages=totalpages+$2} END {print totalpages}';

因此，实际上这个数字与线程内存堆栈大小的限制(ulimit -s)无关。

注:线程内存堆栈限制是10M在我的rhel虚拟机，1.5G内存，这个虚拟机只能提供150个线程?

在实际应用中，限制通常由堆栈空间决定。如果每个线程获得1MB的堆栈(我不记得这是否是Linux上的默认值)，那么32位系统将在3000个线程后耗尽地址空间(假设最后gb留给内核)。

但是，如果使用几十个以上的线程，您很可能会遇到糟糕的性能。迟早，您会得到太多的上下文切换开销、调度程序开销等等。(创建大量线程只会消耗大量内存。但是很多有实际工作要做的线程会减慢你的速度，因为它们在争夺可用的CPU时间)

你在做什么，这个极限甚至是相关的?

也许这并不重要。将算法设计为使用固定数量的线程(例如，如果有4或8个处理器，则使用4或8个线程)，将获得更好的性能。您可以使用工作队列、异步IO或类似libevent的东西来实现这一点。

对于现在看到这个的人来说，在systemd系统上(在我的情况下，特别是Ubuntu 16.04)，还有另一个由cgroup pid强制执行的限制。max参数。

默认设置为12288，可以在/etc/systemd/logind.conf中覆盖

其他建议仍然适用，包括pids_max、threads-max、max_maps_count、ulimits等。