aspose file tools*
The moose likes Beginning Java and the fly likes Stack? Heap? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Stack? Heap?" Watch "Stack? Heap?" New topic
Author

Stack? Heap?

ed suttner
Greenhorn

Joined: Mar 04, 2003
Posts: 13
What does it mean when I read in the book that an object was placed on the stack or an object was placed on the heap? What is the stack and the heap?Thanks.
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy,
The heap is the area where the JVM puts all the objects (and possibly other things). In fact, you can also call it the "gargabe-collectible heap" to help give you an idea of what it really means. In Java, ALL objects that are created, regardless of where they are created, live in the heap. When nobody has a reference to an object, the object is said to be 'abandoned on the heap', and that means the next time the garbage collector runs, it can decide to reclaim the space that object has been using, since nobody can ever get to that object again.
For example, if you say:
Dog d1 = new Dog();
Dog d2 = new Dog();
d1 = d2;
You have left the poor first Dog that was created with NO references. The 'd1' reference is now referring to the second Dog created, leaving no references for the first Dog. Both Dog objects are on the heap, but the first Dog is now 'eligible for garbage collection.'
Now, the stack...
The stack is really "the CALL stack". In a normal Java program, it all starts with main(), that sits on the bottom of the stack. If in main, you call a method doStuff(), then doStuff() is put on to the top of the stack. If doStuff() calls another method go(), then go() is put on the top of the stack, and as long as the go() method is doing things, you have a stack with three methods in it , like this:
go()
doStuff()
main()
AFTER go() completes, it is popped off the stack and now doStuff() is on top. The stack looks like this;
doStuff()
main()
AFTER doStuff() completes, it is popped off the stack and now only main() is left. When main() completes, there's nothing left to be on the stack, and the JVM completes.
The stack will become important when you learn about threads, and exceptions. But the only thing you might want to remember now is that the stack is where LOCAL variables live. In other words, a variable that is declared INSIDE a method (as opposed to an *instance* variable that is declared within a class but NOT inside a method). With LOCAL variables, then, you can see that they live only as long as the method is on the stack. Once the method is popped off the stack, that variable is GONE. But... ALL objects are on the heap, remember, so even objects created and assigned to local variables still live on the heap.
For example:
void go() {
Dog d = new Dog();
// other stuff
}
Now, while go() is running, 'd' variable is on the stack, but the Dog object is on the heap. When go() completes, and the method pops off the stack, then the 'd' reference no longer exists. Once again, that leaves a poor abandoned Dog object, that is now eligible for garbage collection.
With instance variables, they live on the heap as long as the object holding the reference is on the heap, so they're alive regardless of the state of the stack.
Hope that helps...
Again, there's not much you need to know about it until you learn more about exceptions and threads, and even then -- it's not really more complicated than what's in this message.
cheers,
Kathy
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy,
The heap is the area where the JVM puts all the objects (and possibly other things). In fact, you can also call it the "gargabe-collectible heap" to help give you an idea of what it really means. In Java, ALL objects that are created, regardless of where they are created, live in the heap. When nobody has a reference to an object, the object is said to be 'abandoned on the heap', and that means the next time the garbage collector runs, it can decide to reclaim the space that object has been using, since nobody can ever get to that object again.
For example, if you say:
Dog d1 = new Dog();
Dog d2 = new Dog();
d1 = d2;
You have left the poor first Dog that was created with NO references. The 'd1' reference is now referring to the second Dog created, leaving no references for the first Dog. Both Dog objects are on the heap, but the first Dog is now 'eligible for garbage collection.'
Now, the stack...
The stack is really "the CALL stack". In a normal Java program, it all starts with main(), that sits on the bottom of the stack. If in main, you call a method doStuff(), then doStuff() is put on to the top of the stack. If doStuff() calls another method go(), then go() is put on the top of the stack, and as long as the go() method is doing things, you have a stack with three methods in it , like this:
go()
doStuff()
main()
AFTER go() completes, it is popped off the stack and now doStuff() is on top. The stack looks like this;
doStuff()
main()
AFTER doStuff() completes, it is popped off the stack and now only main() is left. When main() completes, there's nothing left to be on the stack, and the JVM completes.
The stack will become important when you learn about threads, and exceptions. But the only thing you might want to remember now is that the stack is where LOCAL variables live. In other words, a variable that is declared INSIDE a method (as opposed to an *instance* variable that is declared within a class but NOT inside a method). With LOCAL variables, then, you can see that they live only as long as the method is on the stack. Once the method is popped off the stack, that variable is GONE. But... ALL objects are on the heap, remember, so even objects created and assigned to local variables still live on the heap.
For example:
void go() {
Dog d = new Dog();
// other stuff
}
Now, while go() is running, 'd' variable is on the stack, but the Dog object is on the heap. When go() completes, and the method pops off the stack, then the 'd' reference no longer exists. Once again, that leaves a poor abandoned Dog object, that is now eligible for garbage collection.
With instance variables, they live on the heap as long as the object holding the reference is on the heap, so they're alive regardless of the state of the stack.
Hope that helps...
Again, there's not much you need to know about it until you learn more about exceptions and threads, and even then -- it's not really more complicated than what's in this message.
cheers,
Kathy
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Stack? Heap?