This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes Performance and the fly likes trying to understand java memory leakage Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "trying to understand java memory leakage " Watch "trying to understand java memory leakage " New topic

trying to understand java memory leakage

eileen keeney
Ranch Hand

Joined: May 04, 2009
Posts: 51
Every article I read, giving examples of memory leaks, does not indicate if the object (the one that is the cause of the leak), becomes eligible for garbage collection, once the program exits the method.

I understand memory leakage within a method itself (if that can technically be called a memory leak).

I do not understand java memory leakage, outside of the method where the instance of the object is created.
Is this possible?
Is it possible to write code, where an instance of an object is created inside a method, and used (or created) in such a way that it does not become eligible for garbage collection once the method is no longer active?

I am trying to determine if my application has a memory leak. At this point I am convinced that Java is just not doing garbage collection as often as I thought it should (before I read more about this, and realized that it really doesn't bother until it realizes it needs memory.)
Calls to gc don't seem to help.

I have pretty much concluded that I just need more memory (or a smaller max heap, so that it does garbage collection sooner).
Paul Clapham

Joined: Oct 14, 2005
Posts: 19973

eileen keeney wrote:Is it possible to write code, where an instance of an object is created inside a method, and used (or created) in such a way that it does not become eligible for garbage collection once the method is no longer active?

Sure it is. Just assign a reference to the object to something else, something which can't be garbage-collected. The easiest way to do this is to add the object to a List of some kind. Small example:
Ernest Friedman-Hill
author and iconoclast

Joined: Jul 08, 2003
Posts: 24199

Hi Eileen,

An object can't be collected if any "live" variable anywhere is pointing to it. "Live" variables include static class members, local variables in any executing method of any thread, and instance variables of any object referred to by any other live variable.

So just as an example, imagine you've got a static member variable in the same class as main() called "arguments." You use it somehow to process the arguments to your program. Then your main() method starts a Swing GUI, and main() returns. The program keeps going because the Swing gui is running in its own thread, the Swing event thread. The static variable "arguments" will never be used again, but it's still there, and it's still taking up memory -- which means it's been leaked.

In Java, you cannot create the C language kind of leak, where a block of memory is unreachable but not freed; you can only create blocks which are reachable, but never going to be used again, and thus *could* be freed if you thought about it.

[Jess in Action][AskingGoodQuestions]
Bear Bibeault
Author and ninkuma

Joined: Jan 10, 2002
Posts: 63873

This is as I pointed out in your other topic; when you return from a method, any automatic variables are released, but if you have created alternate references to the instances, they cannot be collected.

Take the List example that Paul gave you: if you have a list in the session or in application scope and add an instance to it, that instance is locked into memory until you explicitly remove the reference or the list goes out of scope.

For a session, that may not be until the session expires. For application context, that won't be until the application is shut down.

That's why I had pointed out that the session is a likely culprit. If you have lots of users, each with their own session, and you are allowing unused instances to collect -- well, things can get out of hand quickly.

The session is a very useful and needed tool, but it must be used wisely. Same with application context and any static blocks in your application -- anywhere that long term, but unused, instances can be referenced.

[Asking smart questions] [About Bear] [Books by Bear]
Tanzy Akhtar
Ranch Hand

Joined: Jul 19, 2009
Posts: 110
Thank you Bear Bibeault for giving nice advice.

Roll with punchers, there is always tomorrow.
Techie Blog --
I agree. Here's the link:
subject: trying to understand java memory leakage
It's not a secret anymore!