Zachowanie GC przy przypisywaniu null do zmiennej referencyjnej

Zbadanie kodu bajtowego pomaga odkryć odpowiedź.

Kiedy przypisujesz null do zmiennej lokalnej, jak wspomniał Jon Skeet, jest to pewne przypisanie, a javac musi utworzyć zmienną lokalną w metodzie main., jak dowodzi bytecode:

// access flags 0x9
public static main([Ljava/lang/String;)V
  TRYCATCHBLOCK L0 L1 L2 java/lang/InterruptedException
 L3
  LINENUMBER 12 L3
  ACONST_NULL
  ASTORE 1

W tym przypadku zmienna lokalna zachowa ostatnią przypisaną wartość i będzie dostępna do zbierania śmieci tylko wtedy, gdy wyjdzie poza zakres. Ponieważ jest zdefiniowany w main, wychodzi poza zakres tylko wtedy, gdy program jest w momencie wydruku i nie jest pobierana.

Jeśli nie przypiszesz do niego wartości, ponieważ nigdy nie jest używana poza pętlą, javac optymalizuje ją do zmiennej lokalnej w zakresie pętli for, która może być oczywiście pobrana przed zakończeniem programu.

Zbadanie kodu bajtowego dla tego scenariusza pokazuje, że brakuje całego bloku LINENUMBER 12, co dowodzi słuszności tej teorii.

Uwaga:
Z tego co wiem, to zachowanie jest nie zdefiniowane przez standard Java i mogą się różnić w zależności od implementacji javac. Obserwowałem to w następującej wersji:

mureinik@computer ~/src/untracked $ javac -version
javac 1.8.0_31
mureinik@computer ~/src/untracked $ java -version
openjdk version "1.8.0_31"
OpenJDK Runtime Environment (build 1.8.0_31-b13)
OpenJDK 64-Bit Server VM (build 25.31-b07, mixed mode)

Nie znalazłem większych różnic w kodzie bajtowym w obu przypadkach (więc nie warto umieszczać kodu bajtowego tutaj). Tak więc moje założenie jest takie, że wynika to z optymalizacji JIT / JVM.

Wyjaśnienie:

Case -1:

public static void main(String[] args) {
  GCTest holdLastObject; //If I assign null here then no of eligible objects are 9 otherwise 10.
     for (int i = 0; i < 10; i++) {
         holdLastObject=new GCTest();
    }
    //System.out.println(holdLastObject); You can't do this here. holdLastObject might not have been initialized.
     System.gc(); //requesting GC
}

Tutaj, zauważ że nie zainicjalizowałeś holdLastObject na null. Tak więc poza pętlą nie można uzyskać do niej dostępu (pojawi się błąd czasu kompilacji). Oznacza to, że * JVM domyśla się, że pole nie jest używane w późniejszej części. Eclipse przekazuje Ci tę wiadomość. Tak więc JVM stworzy i usunie wszystko wewnątrz samej pętli . Więc 10 obiektów zniknęło.

Case -2:

 public static void main(String[] args) {
      GCTest holdLastObject=null; //If I assign null here then no of eligible objects are 9 otherwise 10.
         for (int i = 0; i < 10; i++) {
             holdLastObject=new GCTest();
        }
        //System.out.println(holdLastObject); You can't do this here. holdLastObject might not have been initialized.
         System.gc(); //requesting GC
    }

W tym przypadku, ponieważ pole jest zainicjalizowane do null, to jest tworzone poza pętlą, a zatem null reference jest wepchnięty do swojego gniazda w tabeli zmiennych lokalnych. W ten sposób JVM rozumie, że pole jest Dostępne z zewnątrz, więc nie nie niszczy ostatniej instancji zachowuje ją alive as it is still accessible / readable . Jeśli więc nie ustawisz wyraźnie wartości ostatniego odniesienia NA null, istnieje ono i jest osiągalne. Stąd 9 instancji będzie gotowe do GC.