First understand that we are talking about an abstract concept. It is a name just to facilitate our understanding. There is no hardware component called heap located in memory. Not even a specific area of memory where the heap gets. It is scattered throughout memory.

Heap

Simply heap is the memory area where your application objects are stored. But it is not any type of object that is stored there, only those created from classes, that is, objects with reference semantics.

In it are placed objects that are referenced somewhere, so they are called objects by reference. Java today encourages most allocations to occur in this way.

This is an area of memory managed by the garbage collector . It will occupy spaces as needed and the GC, at some point in the future, will release the spaces when the data contained in a given portion are no longer needed. The release is not done soon after the object is no longer needed.

This area does not need to be continuous, it is just a portion , a mount of memory allocated to your application. And we are talking about the virtual memory that can be RAM, disk or other form that the operating system makes available.

The way it is used is on demand, that is, it allocates specific spaces as needed. In the case of the JVM a good part of this allocation is already reserved in advance by the GC. He tries to manage memory as best he can. But you need to see this type of allocation as on demand, and it will be used as needed.

Stack

Short and short objects that are stored directly with their value are in stack . This is the case of objects of primitive types. Some people forget that primitive data is also an object (and neither is it because Java is object-oriented, in fact it is another object concept). maybe even because Java does not customarily use the term object for this data. But they are objects. In C which is nothing object-oriented you can reference as objects.

The operation of this area is similar to a stack , hence the name. It is a fixed-size, usually continuous area where data is being stacked as it needs to be allocated and unshackled when no longer needed. And the order of uncapping must be invariably inverse to stacking. This makes this area very fast. But its limitation is that it has a space that can not grow and can not destroy data at random. You can not, for example, leave a newly allocated data still in use and destroy unneeded ones that have been allocated before.

More in detail

To understand better about stack and heap see my generic answer about the subject . The explanation is not so simple but it is not as complex as the subject really is. I also clarify the difference between types by value and by reference in that other answer on C #. The biggest difference is that Java does not allow you to create types by value, at least until Java 9 (provided in Java 10), only the primitive types are by value.

Everyone knows that computers are machines that work with binary code. All that a computer handles are zeros and ones.

So when you have a die in your program, you have a set of zeros and ones. But this set can not simply get loose in space - it has to be well located in RAM. Otherwise, your program would not be able to distinguish the payroll you've implemented from photos of kittens loaded into an open tab of your browser.

In general, runtimes like C ++, and from the Java and .NET platforms, separate two spaces in RAM (literally something like "the X address byte to the address Y byte ") for each program they are running. These two spaces are usually called Stack and Heap , but these names are arbitrary and human conventions, not machine conventions.

All objects that you instantiate in your program are allocated and addressed in memory in one of these two spaces. Whether it goes to the Stack or to the Heap depends on how the object is created.

Objects that are said to be by value (in general, primitives such as int , bool , double etc.), as well as the references declared within a method, are allocated in the Stack. Objects by reference go to Heap.

And what's the difference? Stack stands for stack. The Stack is made of cells, or contexts ... Every time you call a method, a new cell or context is stacked on the stack with the information of that method. This cell or context exists as long as the method does not reach its end, and all the variables that the method needs are allocated in that cell. So if we have something like:

public void Foo() {
    int a = 0;
    boolean b = false;
    Bar();
}

public void Bar() {
    int b = 1;
    Ni();
}

public void Ni() {
    int c = 2;
}

We will have a stack as it grows this way:

Foo -> |a == 0, b == false|

Bar -> |b == 1|
Foo -> |a == 0, b == false|

Ni  -> |c == 2|
Bar -> |b == 1|
Foo -> |a == 0, b == false|

Note that there are two objects called b , with different types and values. No problem. The program "sees" only the current context or cell, which is at the top of every moment.

The Garbage Collector has no power here. He will never deallocate and devour the objects on the stack. However, when a method is terminated, its cell in Stack is unstacked and destroyed , taking all objects allocated within that cell to the hell of objects , which ends up discarding everything that is there.

Heap does not exist. Heap means mound, and there objects are allocated on the basis of "goes the way it fits." Objects survive between method calls, and are at the mercy of the Garbage Collector. They die when the GC thinks they should die (the doomsday algorithm GC mechanism, however, is topic for another question).

When you instantiate something from a class, type:

ArrayList l1 = new ArrayList();

You actually have two objects. l1 is a reference or pointer, and will live in Stack . Its only function is to tell the program where the Heap address is the list you created with the new List() command. This list will survive the end of the scope where it was declared.

It is therefore faster to allocate and deallocate objects in the stack, but they will only exist within the scope of a method. In the Heap there is memory management. It is slower to allocate and deallocate, but objects survive the method and die only when they are no longer needed.

Q.: One reason it's good to have objects in Heap is that you do not need to copy them in whole from one method call to another. If you have a list of a mega, things like:

Foo(l1); // aproveitando a que criamos mais acima

You are working with an object that occupies a mega in memory. If list was by value rather than by reference , a new copy of the list would be generated every time it was passed as a parameter, so only here would be double the memory consumed. At the end of the day, working with references saves memory in most cases.