是Java'；堆栈分配的大小是物理的还是逻辑的？ 我想知道，我们认为java所具有的堆栈大小是否是逻辑大小（例如，实际上，我们使用的是超过512K，包括所有热点开销），或者是物理极限。（也就是说，将堆栈中所有Java分配的内容相加，就不会得到512k这样的值）

正如我在另一篇文章中看到的那样，通过测试很难解决这个问题：

如果可能的话，我想要一些资料来源

---

谢谢

我认为在这种情况下，物理和逻辑之间的区别有点模糊。由于HotSpot会随意将代码JIT为本机代码，并且结果可能取决于许多优化，因此可以说这两种视图在某种程度上都是正确的

或者，可以说堆栈是物理的，但堆栈上的内容是可变的，并且并不总是简单地从正在执行的Java代码派生。例如，函数调用可能是内联的，也可能不是内联的，因此从一个位置调用函数可能需要堆栈上的额外空间，从另一个位置或另一个位置调用相同的函数可能需要堆栈上的额外空间时间可能不需要它，也可能需要更少（或更多）。这称为中的深度内联。如果将引用推送到堆栈上，它们的大小也可能会有所不同（有些技巧使得有时甚至在64位JVM中也可以将引用压缩到32位）。由于JIT编译器异步工作，并根据代码执行中的分析数据做出某些决策，因此同一代码可能具有不同的性能，并且可能在不同运行期间使用堆栈

编辑：

---

垃圾收集器、JIT编译器等在单独的线程中运行，因此它们使用自己的调用堆栈，如果这是您所说的“热点开销”的意思的话。

堆栈大小在实际使用之前使用虚拟内存。这意味着每个线程的堆栈大小可能为1 MB，但驻留大小可能只有32 KB

这是因为当您实际使用页面时，操作系统会将页面（通常为4KB）分配给您的程序

e、 它在启动时分配最大堆大小，但在使用每个页面之前，程序不会使用那么多主内存

---

您可能很难找到JVM的这些信息，因为这是操作系统提供的功能，所有程序都是这样工作的。也就是说，JVM并没有什么特别的功能。

我会尽量让自己更清楚一点。我已经接触了JDK和HotSpot的代码，我得出的结论是，例如，当一个方法调用，有一个大的结构（JavaCallWrapper就是它的调用方式），它被创建时填充了所有这些不同的信息，比如参数、返回数据、线程信息等等。当然，这个结构存在的事实增加了我们假设存在的更明显的数据（像参数本身、返回数据、this参数等）您会“计算”JVM定义的堆栈大小的JavaCallWrapper吗？