64位Linux上的Java线程堆栈大小
我的目标是提出可以并行运行的最大线程数。 Google 向我指出了许多链接，他们通过除以 RAM/StackSize 给出了简单的数学计算。在 64 位 Linux 中，我们将线程堆栈大小定义为 10 MB（ulimit -s = 10240kb），RAM 为 4GB，为操作系统留下 1 GB，按照这个数学计算，我可以拥有大约 300 个线程左右，但我可以使用小型测试应用程序write 达到 ~32297，然后给出内存不足错误。
我使用 -Xss 尝试了不同的值，但这些值几乎对线程数没有任何影响，它仍然与 ~32297 相同）。
这给我的印象是堆栈大小是可变的，由操作系统决定，并且在需要时达到我们定义的最大值，但无论我读到什么，它们的大小堆栈大小都是静态的
我在这里到底缺少什么？
My goal is to come up with figure of max threads which can run in parallel. I was pointed to many links by Google, where they give simple math by dividing the RAM/StackSize. In 64 bit Linux, we have thread stack size defined as 10 MB(ulimit -s = 10240kb) and RAM was 4GB, leaving 1 GB for OS and going with this math I can have ~300 threads or so but small test application which I wrote goes upto ~32297 and then gives out of memory error.
I tried different values with -Xss but these values hardly have any effect on thread count, it remains same as ~32297).
This gave me an impression that stack size is variable and decided by OS and goes upto max defined by us whenever needed, but wherever I read, they size stack size is static
What exactly I'm missing here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
尝试使用检查/更改Linux最大堆栈大小
同时检查Linux线程限制
Try checking/changing linux maximum stack size using
Also check for linux threads limit
我还发现 Java 中线程的限制约为 32K。如果您有这么多线程，通常最好使用不同的方法。在我的机器上，32K 线程执行
while(true) Thread.sleep(1000)仅上下文切换就会消耗 3 个核心。Java：限制是什么您可以创建的线程数？
I have also found a limit of about 32K for thread in Java. If you have this many threads, its usually a better idea to use a different approach. On my machine 32K thread doing
while(true) Thread.sleep(1000)will consume 3 cores just context switching.Java: What is the limit to the number of threads you can create?
因此，可以通过增加总虚拟内存或减少堆栈大小来增加每个进程的线程数。但是，当最大虚拟内存等于交换内存时，过多减小堆栈大小可能会因堆栈溢出而导致代码失败。
检查您的机器：
总虚拟内存：
ulimit -v（默认为无限制，因此您需要增加交换内存来增加此值）总堆栈大小：
ulimit - s（默认为 8Mb）增加这些值的命令：
*将新值替换为您想要作为限制的值。
参考文献：
http ://dustycodes.wordpress.com/2012/02/09/increasing-number-of-threads-per-process/
Thus, the number of threads per process can be increased by increasing total virtual memory or by decreasing stack size. But, decreasing stack size too much can lead to code failure due to stack overflow while max virtual memory is equals to the swap memory.
Check you machine:
Total Virtual Memory:
ulimit -v(default is unlimited, thus you need to increase swap memory to increase this)Total Stack Size:
ulimit -s(default is 8Mb)Command to increase these values:
*Replace new value with the value you want to put as limit.
References:
http://dustycodes.wordpress.com/2012/02/09/increasing-number-of-threads-per-process/
您所读到的内容仅在 32 位体系结构中有效，且限制为地址空间 (2^32)。你实际上有这样的东西： Xmx + MaxPermSize + (Xss * 线程数) <操作系统允许用户进程的最大地址空间。根据操作系统和物理硬件，您可以使用像您所说的 3Go 之类的东西。但这与RAM无关。
对于 64 位体系结构，地址空间不会成为限制 (2^64)。您应该像上面有人所说的那样查看操作系统限制。
What you've read is only valid in 32 bit architecture when the limit is the address space (2^32). You have effectively something like that: Xmx + MaxPermSize + (Xss * number of threads) < Max address space OS allow for user process. Depending on the OS and physical hardware you've something like 3Go like you said. But this has nothing to do with RAM.
For 64 bit architecture, you address space won't be the limitation (2^64). You should look at OS limitation like someone has told above.
这是因为 pid_max 内核变量默认为 32768，但对于 64 位系统可能会增加到 400 万。
解释很简单 1 个线程 = 1 个进程，将有 1 个 PID（进程 ID），因此不再有 pid，也不再有线程。
It is because of the pid_max kernel variable that is by default 32768, but for 64 bit systems may be increased up to 4 milions.
Explanation is simple 1 thread = 1 process that will have 1 PID (process ID) so no more pids, no more threads.