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 like
you 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 example
And 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