当 object 在堆转储分析中仅被“this$0”引用时，这意味着什么？

Question

I analyzed a heap dump to find out why some multiple instances of a certain class are still in memory even after their purpose is over. What I found out is that the only reference to each instance is the object itself.

ScheduleWindow#1 has 'this$0 in ScheduleWindow$1#1' as the only reference.

ScheduleWindow#2 has 'this$0 in ScheduleWindow$1#2' as the only reference.

ScheduleWindow#3 has 'this$0 in ScheduleWindow$1#3' as the only reference.

...

What does it mean to have references like this? ScheduleWindow is not an inner class either.

PS Please bear with me for not posting the actual code because I can't post the actual code due to legal reasons.

Answer 1

An inner class always has an implicit reference to the outer class which shows up as "this$0". Take this code for example:

public class Test {

  String test;

  // inner class has a this$0 reference to its outer / parent object
  public class Inner {
    String inner;

    void bar(Object anonymous) {
      // the debugger screenshot is taken here
      System.out.println();
    }
  }

  void foo() {
    // create an instance of Inner and pass an anonymous inner class to it
    new Inner().bar(new Runnable() {
      public void run() {}
    });
  }

  public static void main(String[] args) {
    new Test().foo();
  }
}

If you set a breakpoint in "bar", the call stack is: main -> foo -> bar. The debugger shows the following variables:

Bar is a method in the inner class (id 22), which points to the outer class (id 24) via this$0.

There is also an anonymous inner class in Test which is referred to as Test$1. It also has the same pointer.

If you define Inner as a static inner class, this pointer is not present.

Seeing the reference "ScheduleWindow$1" You probably have an anonymous class defined somewhere in there (like the Runnable in the example above) and this instance has the this$0 reference to ScheduleWindow.

Answer 2

Please see any static fields in that class. Also better to make the class stateless if you want it to easily release in the memory heap. I encounter this type of problem before. Having a bad design in a Singleton Util.