如何增加Java堆栈大小? [英] How to increase the Java stack size?

问题描述

我问这个问题是为了了解如何增加 JVM 中的运行时调用堆栈大小.我已经得到了这个答案，而且我还得到了许多与 Java 如何处理需要大型运行时堆栈的情况相关的有用答案和评论.我已经用回复摘要扩展了我的问题.

I asked this question to get to know how to increase the runtime call stack size in the JVM. I've got an answer to this, and I've also got many useful answers and comments relevant to how Java handles the situation where a large runtime stack is needed. I've extended my question with the summary of the responses.

最初我想增加 JVM 堆栈大小，这样程序就可以在没有 StackOverflowError 的情况下运行.

Originally I wanted to increase the JVM stack size so programs like runs without a StackOverflowError.

public class TT {
  public static long fact(int n) {
    return n < 2 ? 1 : n * fact(n - 1);
  }
  public static void main(String[] args) {
    System.out.println(fact(1 << 15));
  }
}

相应的配置设置是java -Xss... 命令行标志，具有足够大的值.对于上面的程序 TT，它在 OpenJDK 的 JVM 中是这样工作的:

The corresponding configuration setting is the java -Xss... command-line flag with a large enough value. For the program TT above, it works like this with OpenJDK's JVM:

$ javac TT.java
$ java -Xss4m TT

其中一个答案还指出 -X... 标志是依赖于实现的.我正在使用

One of the answers has also pointed out that the -X... flags are implementation dependent. I was using

java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.1) (6b18-1.8.1-0ubuntu1~8.04.3)
OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode)

也可以只为一个线程指定一个大堆栈(参见答案之一).推荐使用 java -Xss... 以避免为不需要它的线程浪费内存.

It is also possible to specify a large stack only for one thread (see in one of the answers how). This is recommended over java -Xss... to avoid wasting memory for threads that don't need it.

我很好奇上面的程序到底需要多大的堆栈，所以我运行它n增加:

I was curious how large a stack the program above exactly needs, so I've run it n increased:

• -Xss4m 足以满足 fact(1 <<<15)
• -Xss5m 对于 fact(1 << 17)
• -Xss7m 足以满足 fact(1 <<18)
• -Xss9m 对于 fact(1 << 19)
• -Xss18m 足以满足 fact(1 <<20)
• -Xss35m 对于 fact(1 << 21)
• -Xss68m 足以满足 fact(1 << 22)
• -Xss129m 可以满足 fact(1 <<23)
• -Xss258m 足以满足 fact(1 <<24)
• -Xss515m 可以满足 fact(1 <<25)

从上面的数字看来，Java 为上面的函数使用了大约 16 个字节的每个堆栈帧，这是合理的.

From the numbers above it seems that Java is using about 16 bytes per stack frame for the function above, which is reasonable.

上面的枚举包含可以足够而不是足够，因为堆栈要求不是确定性的:使用相同的源文件和相同的-Xss... 有时会成功，有时会产生 StackOverflowError.例如.对于 1 <<20，-Xss18m 在 10 次运行中有 7 次就足够了，-Xss19m 也并不总是足够，但是 -Xss20m 已经足够了(总共 100 次，共 100 次).垃圾收集、JIT 启动或其他原因是否会导致这种不确定行为?

The enumeration above contains can be enough instead of is enough, because the stack requirement is not deterministic: running it multiple times with the same source file and the same -Xss... sometimes succeeds and sometimes yields a StackOverflowError. E.g. for 1 << 20, -Xss18m was enough in 7 runs out of 10, and -Xss19m wasn't always enough either, but -Xss20m was enough (in all 100 runs out of 100). Does garbage collection, the JIT kicking in, or something else cause this nondeterministic behavior?

在 StackOverflowError 处打印的堆栈跟踪(也可能在其他异常中)仅显示运行时堆栈的最新 1024 个元素.下面的答案演示了如何计算达到的确切深度(可能比 1024 大很多).

The stack trace printed at a StackOverflowError (and possibly at other exceptions as well) shows only the most recent 1024 elements of the runtime stack. An answer below demonstrates how to count the exact depth reached (which might be a lot larger than 1024).

许多做出回应的人指出，考虑相同算法的替代性、较少堆栈需求的实现是一种良好且安全的编码实践.通常，可以将一组递归函数转换为迭代函数(使用例如 Stack 对象，该对象填充在堆上而不是运行时堆栈上).对于这个特定的 fact 函数，转换它非常容易.我的迭代版本看起来像:

Many people who responded has pointed out that it is a good and safe coding practice to consider alternative, less stack-hungry implementations of the same algorithm. In general, it is possible to convert to a set of recursive functions to iterative functions (using a e.g. Stack object, which gets populated on the heap instead of on the runtime stack). For this particular fact function, it is quite easy to convert it. My iterative version would look like:

public class TTIterative {
  public static long fact(int n) {
    if (n < 2) return 1;
    if (n > 65) return 0;  // Enough powers of 2 in the product to make it (long)0.
    long f = 2;
    for (int i = 3; i <= n; ++i) {
      f *= i;
    }
    return f;
  }
  public static void main(String[] args) {
    System.out.println(fact(1 << 15));
  }
}

仅供参考，正如上面的迭代解决方案所示，fact 函数无法计算大于 65(实际上，甚至大于 20)的数字的精确阶乘，因为 Java 内置类型 long 会溢出.重构 fact 使其返回 BigInteger 而不是 long 也会为大输入产生准确的结果.

FYI, as the iterative solution above shows it, the fact function cannot compute the exact factorial of numbers above 65 (actually, even above 20), because the Java built-in type long would overflow. Refactoring fact so it would return a BigInteger instead of long would yield exact results for large inputs as well.

推荐答案

嗯...它对我有用，而且堆栈远远少于 999MB:

Hmm... it works for me and with far less than 999MB of stack:

> java -Xss4m Test
0

(Windows JDK 7，构建 17.0-b05 客户端 VM，以及 Linux JDK 6 - 与您发布的版本信息相同)

(Windows JDK 7, build 17.0-b05 client VM, and Linux JDK 6 - same version information as you posted)

这篇关于如何增加Java堆栈大小?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！