java – 计算方法调用栈大小来检查StackOverflowException

>堆内存(通过JVM选项-Xms和-Xmx控制的分配)

>构造的对象和数组实例
>静态类和数组数据(包括对象/数组实例)
>线程实例(对象实例,运行时数据和元数据,包括线程对象监视器锁定引用)

>非堆存储器

>堆栈堆栈内存

>每线程堆栈内存(通过JVM选项-Xss控制的每个线程分配)：方法调用帧,参数,返回值,本地声明的基元&对象的引用

>静态常量(基元)
> String实例池
java代码：加载类和元数据
> JVM内部使用内存(JVM代码和数据结构)

见http://docs.oracle.com/javase/7/docs/api/java/lang/management/MemoryMXBean.html和http://www.yourkit.com/docs/kb/sizes.jsp

Is there any method by which we can compute the method call stacks size dynamically in our program

> Java SE / Java EE中没有包含标准方法来获取每个线程堆栈的实际内存使用量.
>有标准的方法来获取聚合非堆内存：MemoryMxBean.getNonHeapMemoryUsage().参考这个不允许你做出动态代码决定,以避免StackOverflow异常
>有没有标准的方法可以获得没有内存使用的调用堆栈：Thread.getStackTrace() ThreadMxBean.getThreadInfo()& ThreadInfo.getStackTrace()

我建议你不要在你的建议的问题,因为：

>如果没有一些复杂的特定于JVM的API,那么您不能在动态线程堆栈内存使用中使用仪器/内部信息 – 在哪里可以找到这样一个API？
>每个线程堆栈通常相对于整个JVM消耗的内存很少,因此通常很容易分配足够的数据,以适应您的算法(例如Windows 64位JVM的默认值为128KB堆栈大小,而2GB的内存可能已经被预算了对于整个JVM)
>这将是非常有限的权力：如果你的逻辑实际上需要调用一个方法,但你不能由于内存不足,那么你的程序将在那一刻被打破. StackOverflow异常实际上是最好的响应.
>你想做什么可能是一个反设计的反模式.
“正确”的方法是指定程序要求,指定所需的运行时环境(包括最小/所需的内存！),并相应地设计程序以获得最佳性能和内存使用.

反模式是在设计和开发过程中不要对这些事情进行适当的思考,只是想象一些运行时反省的魔法可以弥补这一点.可能存在一些(罕见的)高性能要求的应用程序,这些应用程序需要在运行时大大地重新排列算法以与发现的资源完全匹配 – 但这是复杂的,丑陋的昂贵.

即使如此,它可能会更好地从“-Xss”参数在宏级别驱动动态算法更改,而不是在代码中位置的确切堆栈内存消耗的微观级别.