why use Heap Memory in Java

Why do we use Heap Memory, Can we use Stack memory for the same?

EDITED

One more question came in my mind after reading answers 1) is there any other kind of memory which we can think of alternative to Heap and Stack?

Edited

I 开发者_JAVA技巧came across the string pool, is that memory associated with the heap or Stack?

Well, you have to use the heap if you want to use objects. Objects are inherently pointers on the stack (or inside other objects) to memory chunks in the heap.

Unlike C++ where you can put objects on the stack or heap, Java does things differently.

Even in C++, it's a good idea to use the heap for objects that must outlive the function they were created in. You probably can avoid it but you may find yourself with a performance problem with all the copy constructors.

As to your edit:

Is there any other kind of memory which we can think of alternative to Heap and Stack?

Sure there is: Static data members, the ones where there's only one per class rather than one per instantiated object must go somewhere. These can't be on the stack since they may disappear when you exit from a function. And they can't belong to an particular object.

These (at least in the Sun/Oracle JVM) go into the Method area.

In addition, you should not think of there being one stack. Every thread gets its own stack on creation.

There's also the runtime constant pool and stacks for native (non-Java) calls.

There's lots of information on the JVM internals here regarding that aspect but keep in mind there may be a distinction between the logical machine and the implementation.

Heap memory is central to Java. All objects are allocated on the heap, and local variables hold only references (essentially pointers) to them. C# allows you to have objects (value types) that live on the stack. Java chose not to borrow this from C++, partly in order to simplify the language.

Across languages, heap memory is the way to provide long-lived objects of arbitrary size.

Can we use Stack memory for the same?

Basically no.

In Java, stack memory is used solely for parameters and local variables of methods (and some hidden book-keeping info which is not relevant to this discussion). And for those variables, only primitive types use just stack memory. Any object or array is represented as a reference to something on the heap, and Java provides no way to allocate an object or array on the stack.

[Aside: it is theoretically possible to perform any calculation in Java using just primitive types and recursive static methods. However, it would be horribly messy. Even writing a simple message to the console will entail your application causing objects to be allocated on the heap. So we can dismiss this as being totally impractical.]

In the JVM, instead of a thread local stack for objects it uses a Thread Local Allocation Buffer or (TLAB) This gives much of the performance benifits of a Stack, without the developer needing to worry about wether an object is on the stack or not.

Heap memory is used to store objects in Java. No matter, where object is created in code. e.g. as member variable, local variable or class variable, they are always created inside heap space in Java. If there is no memory left in stack for storing function call or local variable, JVM will throw java.lang.StackOverFlowError, While if there is no more heap space for creating object, JVM will throw java.lang.OutOfMemoryError Java Heap Space.

Another important factor to consider is scoping. If all objects were to be allocated on stack then they go out of context as stack frame gets rolled out. In layman terms, think of stack as a dump that stores all the variable values and object references that are local to a subroutine/method which is currently in scope. As soon as it finishes executing (or the method goes out of scope), then all in it would be lost.

It makes it easier for compiler to manage large &/or dynamic sized variables too- they still take small constant storage on call stack- that of 4 bytes ( a heap pointer).