CODEWITHSUNDEEP
javamemorymemory-leakssingleton
Sean
Sean

Reputation: 21

would an anonymous class instance who has an implicit reference to the singleton enclosing instance cause memory leak?

public class Singleton {

  public void processRequest(final List<a> aList) {

      List<b> bList = new AbstractList<b>() {
              b get(int i) {
                   return (b)aList.get(i); 
              }

              int size() {
                   return aList.size();
              }

             ......
      }

  }

here an anonymous instance is created with an implicit reference to the enclosing instance. Since the enclosing instance is a singleton that would always exist in JVM, would this prevent the anonymous instance being claimed by GC and cause memory leak?

any help appreciated!

Upvotes: 2

Views: 340

Answers (3)

NameSpace
NameSpace

Reputation: 10177

This answer is coming 2 years after the fact, but it came up under my similar question pane when I asked: Reference to final object in anonymous class constructor a leak?

I give a different answer than both @Russel and @Sebestian because they rely on a narrow definition of memory leak. What leak often means in GC languages, however, is "keeping a reference thus preventing the GC from collecting it." http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html and that to me seems how OP was using the term. I think he's asking am I unintendedly keeping this object alive? Am I preventing the GC from claiming it?

If those are your actual questions, then the answer is yes. aList is an implict field of bList. Holding a reference to bList will prevent aList from being collected, so long as bList is kept alive.

Upvotes: 0

Sebastien Lorber
Sebastien Lorber

Reputation: 92140

As Russell said, there is no memory leak here.

An object is eligible to garbage collection when it is not reachable by any thread.

If an object is not referenced by any other object, it is never reachable. But if A and B are refering to each others, it doesn't mean they are reachable, because both of them can be unreachable from any thread. This is what we call Island of isolation

Notice that in some cases, an object reachable from a thread can be collected, when you are not using the normal references (default) but when you use soft or weak references.

Reachability

Going from strongest to weakest, the different levels of reachability reflect the life cycle of an object. They are operationally defined as follows: An object is strongly reachable if it can be reached by some thread without traversing any reference objects. A newly-created object is strongly reachable by the thread that created it. An object is softly reachable if it is not strongly reachable but can be reached by traversing a soft reference. An object is weakly reachable if it is neither strongly nor softly reachable but can be reached by traversing a weak reference. When the weak references to a weakly-reachable object are cleared, the object becomes eligible for finalization. An object is phantom reachable if it is neither strongly, softly, nor weakly reachable, it has been finalized, and some phantom reference refers to it. Finally, an object is unreachable, and therefore eligible for reclamation, when it is not reachable in any of the above ways.

Reference package of Java API

Upvotes: 0

Russell Zahniser
Russell Zahniser

Reputation: 16364

No, there is no memory leak here. Objects that refer to non-garbage objects can be collected; it is only objects referred to by non-garbage objects that cannot become garbage.

Upvotes: 3

Related Questions