分配的变量引用在哪里，在堆栈中还是在堆中？
例如，我有一个问题，
当我在方法内声明变量时会发生什么。
void myMethod() {
Ship myShip = new Ship();
}
分配的 myShip 引用在哪里，在堆栈中还是在堆中？
我认为在堆栈中，但我很困惑，因为我正在阅读《J2ME 游戏编程》一书 “Java 类被实例化到 Java 堆上”
所有 java 类？
提前致谢
I have a question
What happend when I declare a variable inside a method, for example.
void myMethod() {
Ship myShip = new Ship();
}
Where is allocated myShip reference, in stack or in the heap ?
I think in stack but I'm confused because I was reading in J2ME Game Programming book
"Java classes are instantiated onto the Java heap"
All java clases ?
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
myShip是对Ship对象的引用，myShip位于方法调用堆栈上，称为“堆栈”。 当一个方法被调用时，一块内存被压入栈顶，该内存块有空间容纳该方法的所有基元（int、float、boolean 等）和对象引用，其中包括方法参数。 堆是为实际对象分配内存的地方。因此，
myShip位于堆栈上，Ship对象位于堆上。请注意，每个线程都有自己的堆栈，但共享堆。
myShipis a reference to aShipobject,myShipis on the method call stack, which is referred to as "the stack". When a method is called a block of memory is pushed onto the top the stack, that memory block has space for all primitives (int, float, boolean etc) and object references of the method, which includes the method parameters. The heap is where the memory for the actual objects is allocated.So
myShipis on the stack and theShipobject is on the heap.Note each thread has its own stack but share the heap.
Java 的做法确实有点不同。 引用基本上位于堆栈上。 对象的内存是在堆中分配的。 然而，可分配内存的实现方式与 C/C++ 模型中堆的实现方式不太一样。
当您创建这样的新对象时，它会有效地将名称放入该范围的引用表中。 这很像 C++ 中指向对象的指针。 当它超出范围时，该引用就会丢失； 分配的内存不再被引用，并且可以被垃圾收集。
Java really does things a bit differently. The reference is basically on the stack. The memory for the object is allocated in what passes for the heap. However, the implementation of allocable memory isn't quite like the way the heap is implemented in the C/C++ model.
When you create a new object like that, it effectively puts the name into the table of references for that scope. That's much like a pointer to an object in C++. When it goes out of scope, that reference is lost; the allocated memory is no longer referenced, and can be garbage-collected.
目前，所有 Java 对象都在堆上分配。 有传言称 Java 7 可能会进行转义分析并能够在堆栈上分配，但我不知道该提案是否已最终确定。 这是 RFE。
编辑：显然，它是已经在 JDK 7 的早期版本中。 （文章说它也会出现在 JDK 6u14 中，但我找不到确认信息。）
Currently, all Java objects are allocated on the heap. There is talk that Java 7 might do escape analysis and be able to allocate on the stack, but I don't know if the proposal is finalized yet. Here's the RFE.
Edit: Apparently, it's already in early builds of JDK 7. (The article says it will also be in JDK 6u14, but I can't find confirmation.)
理论上，对象位于“堆”中。 然后，因为它是方法本地引用，所以实际引用将位于堆栈上。 “the”堆栈，我们指的是本机线程堆栈（即，至少在 Sun 的 VM 中分配 C 中的局部变量的堆栈），但我认为这实际上并不是一个要求（JVM只需有一些“堆栈帧”的抽象概念，它在每个方法调用上分配，无论是否来自本机堆栈）。
但是......在现代虚拟机上（诚然，简单的嵌入式/mpbile 虚拟机可能是个例外），实际上不存在“堆”这样的东西。 在实践中，存在各种堆区域。
其中最简单的通常几乎就像一个“迷你堆栈”，旨在快速分配不会长时间挂起并且可能几乎可以立即取消分配的对象。
正如另一位发帖者所提到的，高度优化的 JVM 原则上可以在堆栈上分配对象数据，并且对此有明确的建议。 尽管，正如其中一篇参考文献中也提到的，对此的批评是快速的“伊甸园”堆无论如何都几乎像一个堆栈（只是不是“该”堆栈）。
Notionally, the object goes on "the heap". Then, because it's a method-local reference, the actual reference will be on the stack. By "the" stack, we mean the native thread stack (i.e. the same stack that a local variable in C would be allocated on) in the case of Sun's VM at least, but I don't think that's actually a requirement (the JVM just has to have some abstract notion of "stack frames" that it allocates on each method call, be it from the native stack or not).
But... on modern VMs (with admittedly the possible exception of simpler embedded/mpbile VMs), there's really no such thing as "the" heap. In practice, there are various heap areas.
The simplest of these is typically almost like a "mini stack", designed to be quick to allocate for objects that won't hang around for long and can probably be de-allocated almost at once.
As mentioned by another poster, a highly optimised JVM could in principle allocate object data on the stack and there are definite proposals for this. Although, as also mentioned in one of the references, a criticism of this is that the fast "eden" heap is almost like a stack anyway (just not "the" stack).