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).
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:
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.
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.