This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
what about a static method such as a factory method? does it occupy a certain part of the memory? do the object(s) created in that method elgibible for garbage collection or will be poped off the stack(no longer occupy memory space)?
When it comes to memory management, static methods work no differently than their non-static counterparts. Local variables and method parameters are stored on the stack, and objects may be created on the stack following escape analysis.
Joined: May 23, 2003
so if a object that represents some data structure is created within a static method as a local variable then after the method finishes the space that object occupies should be cleared(i.e. available again) and that object is destroyed?
Billy Tsai wrote:so if a object that represents some data structure is created within a static method as a local variable then after the method finishes the space that object occupies should be cleared(i.e. available again) and that object is destroyed?
Hello Billy, I think Stephan has said it all, in my honest opinion it doesn't really matter if the Object represents the white house
That said if the reference to that Object is returned from the method and assigned to another reference variable, located outside
the method, then it will NOT be garbage collected (or NOT be destroyed).
naveen yadav wrote:
what about the object created inside a method shouldn't it be stored on stack ?
@Naveen to the best of my knowledge objects live on the heap. You can imagine Objects living on the stack and the objects are referenced from outside the method where they where created "we know that once a method completes execution its properties disappear from the stack... together with the objects"?... Its a simple logic that requires a minute of brain flexing...
........... objects are referenced from outside the method where they where created "
suppose i have a code in which object do not referenced from outside.It is created inside the method and used inside the method.No reference to the outside
at a look
and yes i can access the nav directly but for the sake of explanation of my point using ob to i access nav .
should not it be ob stored on stack ?
Remember that 'local' variables live on the stack, while 'objects' live on the heap;
'ob' = lives on the stack
'new Jivvy()' = lives on the heap
as soon as the 'fun()' method completes, 'ob' no longer exists, hence 'new Jivvy()' becomes eligible for garbage collection.
setting 'ob' to null in this scenario is rather redundant.
No, that particular object will always be stored on the heap, because you pass it out of the method through a call to System.out.println(). The method does not know what the println() method could do with the object, so it's unsafe to store it on the stack.
If an object is created within a method, and never assigned to a field, or passed to a method, only then may it be stored on the stack. It depends on escape analysis though. If the compiler is smart enough to realize that the println() method does not need to store a reference to the object anywhere, then it may still create the object on the stack.
For all intents and purposes it's always safest to assume that an object is created on the heap.
Local variables and method parameters are always on the stack. Instance fields are stored together with their object. If an object is on the stack, so are its fields.