Долговечные Java WeakReferences

Ответ 1

Наконец-то я обзавелся проверкой исходного кода JVM Hotspot и нашел следующий код.

В referenceProcessor.cpp:

void ReferenceProcessor::process_discovered_references(
  BoolObjectClosure*           is_alive,
  OopClosure*                  keep_alive,
  VoidClosure*                 complete_gc,
  AbstractRefProcTaskExecutor* task_executor) {
  NOT_PRODUCT(verify_ok_to_handle_reflists());

  assert(!enqueuing_is_done(), "If here enqueuing should not be complete");
  // Stop treating discovered references specially.
  disable_discovery();

  bool trace_time = PrintGCDetails && PrintReferenceGC;
  // Soft references
  {
    TraceTime tt("SoftReference", trace_time, false, gclog_or_tty);
    process_discovered_reflist(_discoveredSoftRefs, _current_soft_ref_policy, true,
                               is_alive, keep_alive, complete_gc, task_executor);
  }

  update_soft_ref_master_clock();

  // Weak references
  {
    TraceTime tt("WeakReference", trace_time, false, gclog_or_tty);
    process_discovered_reflist(_discoveredWeakRefs, NULL, true,
                               is_alive, keep_alive, complete_gc, task_executor);
  }

Функция process_discovered_reflist имеет следующую подпись:

void
ReferenceProcessor::process_discovered_reflist(
  DiscoveredList               refs_lists[],
  ReferencePolicy*             policy,
  bool                         clear_referent,
  BoolObjectClosure*           is_alive,
  OopClosure*                  keep_alive,
  VoidClosure*                 complete_gc,
  AbstractRefProcTaskExecutor* task_executor)

Это показывает, что WeakRefs безоговорочно очищаются с помощью ReferenceProcessor:: process_discovered_references.

Поиск кода Hotspot для process_discovered_reference показывает, что сборщик CMS (который я использую) вызывает этот метод из следующего стека вызовов.

CMSCollector::refProcessingWork
CMSCollector::checkpointRootsFinalWork
CMSCollector::checkpointRootsFinal

Этот стек вызовов выглядит так, как будто он вызывается каждый раз при запуске коллекции CMS.

Предполагая, что это правда, единственным объяснением для долговечного слабоопределенного объекта будет либо тонкая ошибка JVM, либо если GC не был запущен.

Ответ 2

Возможно, вы захотите проверить, есть ли у вас проблема с загрузкой класса. Подробнее об этой теме вы можете найти в этом сообщении в блоге

Ответ 3

Вам нужно уточнить, какова связь между Foo и WeakReference. Случай

class Wrapper<T> extends WeakReference<T> {
  private final T referent;
  public Wrapper(T referent) {
    super(t);
    this.referent = referent;
  }
}

сильно отличается от просто

class Wrapper<T> extends WeakReferece<T> {
  public Wrapper(T referent) {
    super(t);
  }
}

или его встроенная версия WeakReference<Foo> wr = new WeakReference<Foo>(foo).

Итак, я предполагаю, что ваш случай не так, как я описал в своем первом фрагменте кода.

Как вы уже сказали, вы работаете с JNI, вы можете проверить, есть ли у вас какие-либо небезопасные финализаторы. Каждый финализатор должен иметь finally блокировать вызов super.finalize() и легко проскальзывать.

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

Ответ 4

@iirekm No: WeakReferences "слабее", чем SoftReferences, что означает, что WeakReference всегда будет мусором, собранным до SoftReference.

Дополнительная информация в этом сообщении: Понимание классов ссылок Java: SoftReference, WeakReference и PhantomReference

Изменить: (после чтения комментариев) Да, конечно, Слабые ссылки "Слабее", чем SoftReferences, опечатка.: S

Вот некоторые примеры использования, чтобы пролить свет на объект:

• SoftReference: кеш в памяти (объект остается в живых до тех пор, пока VM не увидит, что там не хватает кучи памяти)
• WeakReference: Авто-очистка прослушивателей (объект должен быть очищен в следующем цикле GC после того, как он считается слабым)
• PhantomReference. Избегайте ошибок из памяти при работе с необычно большими объектами. (Когда запланировано в ссылочной очереди, мы знаем, что объект хоста должен быть очищен, чтобы выделить другой большой объект). Подумайте об этом как о finalize() альтернативе, не имея возможности вернуть мертвые объекты к жизни (как вы могли бы с финализацией)

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

Это лучший ресурс, который я смог найти по этому вопросу: http://www.pawlan.com/monica/articles/refobjs/

Изменить 2: Добавлен "быть" перед очисткой в ​​PhantomRef

Ответ 5

Я не знаком с Java, но вы можете использовать коллективный сборщик мусора, который будет содержать только ваши объекты Foo и FooWeakRef (не собрано), пока

• они прошли в старшем поколении
• достаточно памяти для размещения новых объектов в младших поколениях

Знает ли журнал, указывающий на то, что сбор мусора различает основные и второстепенные коллекции?

Ответ 6

Для неверующих, которые утверждают, что слабые ссылки очищаются до мягких ссылок:

import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;
import java.lang.ref.SoftReference;
import java.lang.ref.WeakReference;
import java.util.HashMap;
import java.util.Map;


public class Test {

/**
 * @param args
 */
public static void main(String[] args) {
    ReferenceQueue<Object> q = new ReferenceQueue<Object>();
    Map<Reference<?>, String> referenceToId = new HashMap<Reference<?>, String>();
    for(int i=0; i<100; ++i) {
        Object obj = new byte [10*1024*1024];    // 10M
        SoftReference<Object> sr = new SoftReference<Object>(obj, q);
        referenceToId.put(sr, "soft:"+i);
        WeakReference<Object> wr = new WeakReference<Object>(obj, q);
        referenceToId.put(wr, "weak:"+i);

        for(;;){
            Reference<?> ref = q.poll();
            if(ref == null) {
                break;
            }
            System.out.println("cleared reference " + referenceToId.get(ref) + ", value=" + ref.get());
        }
    }
}
}

Если вы запустите его с помощью -client или -server, вы увидите, что мягкие ссылки всегда очищаются до слабых ссылок, что также согласуется с Javadoc: http://download.oracle.com/javase/1.4.2/docs/api/java/lang/ref/package-summary.html#reachability

Типично мягкие/слабые ссылки используются в связи с Картами, чтобы создавать типы кешей. Если ключи в вашей карте сравниваются с оператором == (или unoverriden.equals from Object), то лучше всего использовать Map, которая работает с ключами SoftReference (например, из Apache Commons) - когда объект "исчезает", ни один другой объект никогда не будет быть равным в "==" смысле старой. Если ключи вашей Карты сравниваются с расширенным оператором .equals(), например String или Date, многие другие объекты могут соответствовать "исчезающему", поэтому лучше использовать стандартный WeakHashMap.

Ответ 7

Попробуйте SoftReference. Javadoc говорит: "Все мягкие ссылки на объекты с мягким достижением гарантированно будут очищены до того, как виртуальная машина выбросит OutOfMemoryError.

WeakReference не имеет таких гарантий, что делает их более подходящими для кешей, но иногда SoftReferences лучше.