Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Object lifecycle a-Z

 
Cedric Bosch
Ranch Hand
Posts: 92
3
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is my high level overview of this topic in the java 8 cert:

Explain an Object's Lifecycle (creation, "dereference by reassignment" and garbage collection)


I hope it can help others and myself if I understood something wrong and someone corrects me.

Stack vs heap:

**1. The stack**:


Imagine 2 buckets, one is called the stack, the other is called the heap.
When you enter a method the method is placed in the stack.



The stack is now :

- print();


----------


Let's call another method within that:





Now the stack is :

- println() -> when this finish it will be removed first

- print()


The method on the stack are Last-In-First-Out. Meaning that the last one to get added to the stack will be the first one to pop out upon its completion. Thus in this example println will be the first to get out of the stack.

Note: a stackoverflow error simply means that the stack bucket is full and is overflowing. An example of such an error could be:




**2. The heap & objects**





When an object is created in the a method its value is placed in the stack along side with the method. What is the value of the object ? The reference address of the object data which is in ... the heap !


So the stack and the heap at this point are:

- *the stack* : createObject(); (contains animal@144ab7)

- *the heap* : @144ab7 : animal with all its data


Difference with primitives

The thing to note here is that the value of a primitive is the data it contains, while the value of an object is a reference to the data object in the heap memory.


----------

Garbage collection


When a method leaves the stack, the objects associated with it are not referenced anymore by anything. IE:




When the method createObject finishes, it leaves the stack, taking away with it the reference to the animal object it was associated with. Mean while in the heap the data from the original animal isn't associated with any object. That means that it is available to be garbage collected.

That also implies that we can unreference objects:




Here the reference to the data of animal is lost before the end of the method. Therefor the garbage collector can potentially remove the data from the heap before the end of the method.


--------


What about String ?


Strings are a bit special because the JVM reserves memory for them in the heap as a pool of strings to be more efficient. What that means is that two strings will reference to the same data in the heap string pool.



s1 == s2 because they point to the same string in the string pool. However when creating a string with the new keyword, the string is NOT placed in the string pool. Ence why s2 != s3. If we want to place a string in the string pool we have to internalize it. s3 = s3.intern(). Then s2 == s3.


--------


With all that I have one question :

I'm 100% sure I've had experience where I initialized two strings with someString = "a" and anotherString ="a" but both weren't equal. So someString != anotherString. I can't reproduce it however. Where can this happen ?


I hope this can help.

 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cedric Bosch wrote:I hope it can help others and myself if I understood something wrong and someone corrects me.

Have a cow for creating this overview of the object lifecycle. It is not 100% accurate, so I will make some comments.

Cedric Bosch wrote:**1. The stack**:

I fully agree with this section

Cedric Bosch wrote:When an object is created in the a method its value is placed in the stack along side with the method. What is the value of the object ? The reference address of the object data which is in ... the heap !

This is incorrect! You have to make a distinction between the reference variable and the actual object. So in the createObject() method, you have the reference variable animal and its value is indeed a reference to the actual Animal instance. The reference variable animal will be on the stack, and the Animal instance will be on the heap. So the most important thing to remember is that there is a distinction between the reference variable and the object this reference variable is referring to.

Cedric Bosch wrote:The thing to note here is that the value of a primitive is the data it contains, while the value of an object is a reference to the data object in the heap memory.

And in this statement you made the same mistake: a primitive variable contains the value, whereas the reference varuable contains a reference to the actual instance (on the heap). So you can't state about "an object" and "a data object", because that's wrong and it is actual the same. Given a statement likeyou have one object/instance (created by invoking the name of the class with the new operator, new Animal() in this case) and the reference variable animal which refers to this object.

Cedric Bosch wrote:When a method leaves the stack, the objects associated with it are not referenced anymore by anything.

Although that's true for the example you have provided, that's not always true! Objects created within a method can still be referenced outside the method. An exampleAnd another example could be

Cedric Bosch wrote:Here the reference to the data of animal is lost before the end of the method. Therefor the garbage collector can potentially remove the data from the heap before the end of the method.

True! The most important thing to remember is that it is not a guarantee the unreferenced object will actually be garbage collected at all! GC can run before the end of the method or after the method has finished or even not at all.

Cedric Bosch wrote:Strings are a bit special because the JVM reserves memory for them in the heap as a pool of strings to be more efficient. What that means is that two strings will reference to the same data in the heap string pool.

Although that's true, it only applies to String literals! So only String literals will be placed in the String Literal pool and two String reference variables who refer to a String literal with the same content, will refer to the same String object. Because there will only be one String object with that content (and that's why String objects are immutable once you have created them ). So in your code example: there will be only one String object "lol" in the String Literal Pool and both reference variables s1 and s2 will refer to this String object.

Cedric Bosch wrote:However when creating a string with the new keyword, the string is NOT placed in the string pool. Ence why s2 != s3. If we want to place a string in the string pool we have to internalize it. s3 = s3.intern(). Then s2 == s3.

You are correct! But as far as I know, the intern() method is not on the OCAJP exam.

Cedric Bosch wrote:I'm 100% sure I've had experience where I initialized two strings with someString = "a" and anotherString ="a" but both weren't equal. So someString != anotherString. I can't reproduce it however. Where can this happen ?

As far as I know, this can only happen if you assigned a String object (which might seem to be a String literal but is not) to one of the String reference variables. For example

Hope it helps!
Kind regards,
Roel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic