Использование PhantomReferences в Java

Платформа Java предоставляет несколько типов ссылок для связи между объектами:

1. Жесткие ссылки (Strong References) - стандартные, известные нам ссылки. Если на объект есть хоть одна жесткая ссылка, то данный объект не будет утилизирован при сборке мусора.


2. Мягкие ссылки (Soft References) - создаются с помощью вызова new SoftReference<T>(T obj, ReferenceQueue<T> queue) или new SoftReference(T obj). Если на объект есть только мягкая ссылка, то будет выполнена попытка утилизации данного объекта при сборке мусора в случае, если приложению не хватает памяти.


3. Слабые ссылки (WeakReferences) - создаются с помощью вызова new WeakReference<T>(T obj, ReferenceQueue<T> queue) или new WeakReference<T>(T obj). Если на объект есть только слабая ссылка, то будет выполнена попытка утилизации данного объекта при сборке мусора.


4. Фантомные ссылки (PhantomReferences) - создаются с помощью вызова new PhantomReference<T>(T obj, ReferenceQueue<T> queue). Если на объект есть только фантомная ссылка, то будет выполнена попытка утилизации данного объекта при сборке мусора. Сам объект при этом не будет удален из памяти до тех пор, пока на него существует фантомная ссылка или данная фантомная ссылка не очищена с помощью вызова метода clear(). Так же стоит заметить, что метод get() фантомной ссылки всегда возвращает null.

Возникает вполне закономерный вопрос: зачем нужны ссылки, которые фактически держат объект в памяти, но по которым к нему нельзя получить доступ?

Проблемы использования метода finalize()

Утилизация объекта сборщиком мусора производится в два этапа:

1. Выполнение метода finalize() объекта.


2. Непосредственно освобождение памяти, выделенной под объект.

Оба эти действия выполняются из потока сборщика мусора. При этом поведение сборщика мусора существенно отличается в случаях если у объекта переопределен метод finalize() и если не переопределен. Если у объекта переопределен метод finalize(), то при первом проходе сборщика мусора данный объект помечается как требующий удаления. Затем у него выполняется метод finalize(). Сам объект при этом удаляется только при последующих проходах сборщика мусора.

Поведение объекта, у класса которого не переопределен метод finalize():



Поведение объекта, у класса которого переопределен метод finalize():



Однако при вызове метода finalize() на объект может быть создана жесткая ссылка. Например, реализовали при финализации сериализацию объекта в файл. Передаем объект сериализатору, тот выполнил свою работу, но продолжает держать ссылку на объект. Тогда при последующих за выполнением метода finalize() проходах сборщика мусора объект не сможет быть удален.

Данное поведение может быть критичным в системах, орабатывающих большие объекты в условиях ограниченного объема памяти. Например, в системах обработки больших изображений. Загружать новое изображение мы можем только после того, как из памяти выгрузилось старое. В методе finalize() мы уведомляем систему о выгрузке старого изображения, но на самом деле из-за проблемы, описанной выше, объект изображения не утилизируется. Система этого не знает и пытается загрузить другое - новое - изображение. В итоге существует риск получить OutOfMemoryError.

Поведение PhantomReference

При наличие на объект только фантомной ссылки, сборщик мусора предпринимает следующие действия по утилизации объекта:

1. Выполняет метод finalize().


2. Если после выполнения предыдущего шага на объект не было создано жестких ссылок и объект может быть удален из памяти, то фантомная ссылка помещается в очередь ReferenceQueue.
   

Стоит заметить, что если метод finalize() у объекта переопределен, то эти действия выполняются в разных проходах сборщика мусора.

Как было отмечено во вступлении к статье, непосредственное удаление объекта из памяти не производится до очистки фантомной ссылки. После выполнения данной очистки объект может быть удален при следующем проходе сборщика мусора. Таким образом, если у объекта не переопределен метод finalize(), то для его удаления потребуется в лучшем случае два прохода сборщика мусора, если же переопределен - три прохода.

Использование PhantomReference

Разберемся теперь с тем, как использовать фантомные ссылки. Удобный способ получить уведомление о помещении ссылки в очередь - создать отдельный поток, который будет периодически опрашивать данную очередь, вызывая метод ReferenceQueue#poll(). Данный метод возвращает ссылку в случае ее наличия в очереди или null - в случае отсутствия. Поместить код данного потока и механизмы его запуска удобнее всего в класс-наследник PhantomReference. Так же в данном наследнике можно создать метод, осуществляющий действия по очистке системы после удаления объекта - те действия, которые раньше размещались в методе finalize(). К таким действиям относятся: закрытие соединений, сбрасывание состояния объекта на диск, освобождение сессий и т.д. Стоит отметить, что для выполнения некоторых действий могут понадобиться знания о внутреннем состоянии объекта. Ни в коем случае нельзя сохранять объект как поле в классе-наследнике PhantomReference, т.к. в таком случае будет создана жесткая ссылка на данный объект, т.е. при сборке мусора с ним не будет выполняться никаких действий. Необходимо сохранять в классе-наследнике PhantomReference значения только тех полей объекта, которые будут нужны для проведения процедуры очистки.

Итак, стратегия использования PhantomReference может быть следующей:

1. Создаем класс-наследник PhantomReference. В данном классе реализуем метод, осуществляющий очистку окружения после удаления объекта.


2. Создаем класс-поток, в конструктор которого передается очередь ReferenceQueue, связанная с экземпляром созданного ранее класса PhantomReference. В методе run() данного потока реализуем опрос этой очереди. Как только из ReferenceQueue будет считано непустое значение - вызываем метод класса-наследника PhantomReference, осуществляющий очистку окружения.


3. В конструкторе класса-наследника PhantomReference сохраняем значения нужных в дальнейшем полей переданного объекта после чего запускаем поток, созданный на втором шаге алгоритма.

Описанная стратегия иллюстрируется следующим кодом:

1. import java.lang.ref.PhantomReference;


2. import java.lang.ref.Reference;


3. import java.lang.ref.ReferenceQueue;


4.  


5.  


6. public class RessurectDemo {


7.    


8.     private A a;


9.    


10.     public static class A {


11.         private RessurectDemo demo;


12.         private String data;


13.        


14.         public String getData() {


15.             return data;


16.         }


17.        


18.         public A(RessurectDemo demo) {


19.             this.demo = demo;


20.             StringBuffer buff = new StringBuffer();


21.             for (long i = 0; i < 50000000; i++) {


22.                 buff.append('a');


23.             }


24.             this.data = buff.toString();


25.         }


26.  


27.         @Override


28.         protected void finalize() throws Throwable {           


29.             System.out.println("A.finalize()");        


30.         }              


31.     }


32.        


33.     private static class MyPhantomReference<T> extends PhantomReference<T> {       


34.        


35.         public MyPhantomReference(T obj, ReferenceQueue<? super T> queue) {


36.             super(obj, queue);


37.             Thread thread = new MyPollingThread<T>(queue);


38.             thread.start();


39.         }      


40.        


41.         public void cleanup() {


42.             System.out.println("cleanup()");


43.            


44.             // Clear Reference!!!


45.             clear();           


46.         }


47.        


48.         public static class MyPollingThread<T> extends Thread {


49.  


50.             private ReferenceQueue<? super T> referenceQueue;


51.            


52.             public MyPollingThread(ReferenceQueue<? super T> referenceQueue) {


53.                 this.referenceQueue = referenceQueue;


54.             }


55.            


56.             @Override


57.             public void run() {


58.                 System.out.println("MyPollingThread started");


59.                 Reference<?> ref = null;


60.                 while ((ref = referenceQueue.poll()) == null) {


61.                     try {


62.                         Thread.sleep(50);


63.                     }


64.                     catch (InterruptedException e) {


65.                         throw new RuntimeException("Thread " + getName() + " has been interrupted");


66.                     }


67.                 }


68.                


69.                 if (ref instanceof MyPhantomReference<?>) {


70.                     ((MyPhantomReference<?>) ref).cleanup();


71.                 }


72.             }


73.         }


74.     }


75.    


76.     public static void main(String[] args) throws InterruptedException {


77.         RessurectDemo demo = new RessurectDemo();


78.        


79.         Thread.sleep(20000);


80.        


81.         Reference<A> ref = new MyPhantomReference<RessurectDemo.A>(new A(demo), new ReferenceQueue<RessurectDemo.A>());


82.                


83.         System.out.println("ref = " + ref);


84.         System.out.println("A = " + ref.get());    


85.                


86.         Thread.sleep(10000);       


87.        


88.         System.out.println("System.gc()");


89.         System.gc();


90.        


91.         Thread.sleep(400);


92.        


93.         System.out.println("ref = " + ref);


94.         System.out.println("A = " + ref.get());    


95.  


96.         Thread.sleep(10000);


97.        


98.         System.out.println("System.gc()");


99.         System.gc();       


100.         Thread.sleep(400);


101.  


102.         Thread.sleep(10000);


103.        


104.         System.out.println("System.gc()");


105.         System.gc();   


106.        


107.         Thread.sleep(10000);


108.     }


109. }


110.  

Предлагаю в комментариях делиться замечаниями по теме. Возможно у читателей есть свое понимание особенностей использования фантомных ссылок - поделитесь им. Особенно был бы благодарен за приведение реальных примеров использования.

UPD 08.09.2011: Статья немного обновлена по результатам обсуждения в комментариях.

UPD 11.09.2011: Подумалось, что применять PhantomReferences для реализации пулов соединений действительно не получится, а вот для знаменитой задачи про двухуровневый кэш - почему бы нет.

Понравилось сообщение - подпишитесь на блог