Heap of Java memory

Asked

Viewed 6,315 times

17

I would like a simple explanation of what heap memory of JVM? I searched on Google but had no clear enough answer.

  • 1

    It’s not specific to Java, but it will help. The differences are not great: http://answall.com/questions/3797/o-que-s%C3%a3o-e-onde-est%C3%a3o-o-stack-e-heap e http://answall.com/q/14490/101

  • 1

    but in the case of java this would be the place where the objects are actually stored?

  • 1

    Objects created from classes, yes. Primitive objects no, these are in the stack. More links http://www.infoq.com/br/articles/intro-memoria-JVM and http://www.ibm.com/developerworks/br/library/j-codetoheap/

  • 3

    I already explained about Heap and Perm Heap in that reply.

  • 1

    @user16049 Take a look at [tour]. You can accept an answer if it solved your problem. You can vote for all the posts on the site as well. Did any help you more? You need something to be improved?

2 answers

12

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

Heap

In a simple way the heap is the memory area in which your application’s objects are stored. But it is not any kind of object that is stored there, only those created from classes, ie objects with reference semantics.

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

It is a memory area managed by Garbage collector. It will occupy spaces as needed and the GC, at some future time, will release the spaces when the data contained in a given portion is no longer needed. Release is not made right after the object is no longer needed.

This area doesn’t need to be continuous, it’s just one portion, one mound memory allocated for your application. And we are talking about the virtual memory that can be RAM, disk or other way that the operating system provides.

The way it is used is on demand, that is, it allocates specific spaces as needed. In the case of JVM much of this allocation is already reserved in advance by GC. It tries to manage the memory in the best way possible. But you need to see this type of allocation as on-demand, which is being used as needed.

Stack

Short and short-lived objects that are stored directly with their value are in the stack (some optimization can do this with type by reference). This is the case for objects of primitive types and will be when the language has other types that are neither primitive nor created with classes. Some people forget that primitive data is also objects (and it’s not because Java is object-oriented, it’s actually another concept of object). Perhaps because Java doesn’t usually use the term object for this data. But they are objects. In C that is nothing object oriented you call them objects.

The operation of this area is similar to a pile, hence the name. It is a fixed-size area of memory, usually continuous in which data is stacked as it needs to be allocated and popped when no longer needed. And the de-stacking order must be reversed to stacking. This makes this area very fast. But its limitation is that it has a space that cannot grow and that cannot destroy data randomly. You cannot, for example, leave a newly allocated data still in use and destroy other unnecessary data that was allocated earlier.

In more detail

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

9

Everyone knows that computers are machines that work with binary code. All 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’t just get loose in space - it has to be well located in RAM memory. Otherwise, your program wouldn’t be able to distinguish the payroll you implemented from photos of kittens loaded in an open tab of your browser.

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

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

Said objects by value (in general, the primitive as int, bool, double etc.), as well as the references declared within a method, are allocated to the Stack. Objects by reference go to Heap.

And what’s the difference? Stack means stack. The Stack is made of cells, or contexts... Every time you call a method, a new cell or context is stacked in 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’ll have a stack as soon as it grows like this:

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 the one at the top each time.

The Garbage Collector has no power here. It will never dislocate and devour the objects in the stack. However, when a method ends, your cell in the Stack is unstuck and destroyed, taking all the objects allocated inside that cell to the hell of the objects, what ends up dislocating everything that is there.

Already in the Heap there is no stack. Heap means mound, and there the objects are allocated at the base of the "go the way they fit". Objects survive between so-called methods, 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 topical for another question).

When you instantiate something from a class, like:

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 inform the program at which address on Heap you find the list you created with the command new List(). This list will survive the end of the scope where it was declared.

Therefore, it is faster to allocate and de-locate objects in the stack, but they will only exist within the scope of a method. No Heap there is memory management. It is slower to allocate and de-locate, but objects survive the method and die only when they are no longer needed.

P.S.: a reason why it is good to have objects in the Heap is that you don’t need to copy them 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 were by value instead of being by reference, a new copy of the list would be generated every time it was passed as a parameter, so only here would be twice as much memory consumed. After all, working with references saves memory in most cases.

  • 2

    @Maniero thanks! It’s been so long since I touched Java that I’d forgotten XD

  • 5

    I don’t know if this is obvious to everyone or not, but it’s not hard to stress: "Objects said by value (...), as well as references declared within a method, are allocated in the Stack..." ...when they are declared in a method. If a class has a field (attribute) this field is part of the data of its objects - and therefore occupies space in the heap (even if they are primitive types or references to other objects).

Browser other questions tagged

You are not signed in. Login or sign up in order to post.