¿GC garantizar que borra las Referencias están en la cola de espera para ReferenceQueue en orden topológico?

Question

Dicen que hay dos objetos, A y B, y no es un puntero A.x --> B, y nos crea, por ejemplo, WeakReferences a ambos A y B, con un asociado de la ReferenceQueue.

Se supone que ambas A y B convertido en inalcanzable.Intuitivamente B no pueden ser considerados inalcanzables antes de A es.En tal caso, ¿tenemos que conseguir de alguna manera una garantía de que las respectivas referencias serán encolados en la intuitiva (topológicas cuando no hay ciclos) orden en el ReferenceQueue?I. e.ref(A) antes de la ref(B).No sé - ¿y si la GC marcado un montón de objetos como inalcanzable y, a continuación, en la cola de espera sin ningún orden en particular?

Yo estaba revisando Finalizer.java de la guayaba, ver este fragmento de código:

private void cleanUp(Reference<?> reference) throws ShutDown {
  ...
  if (reference == frqReference) {
    /*
     * The client no longer has a reference to the
     * FinalizableReferenceQueue. We can stop.
     */
    throw new ShutDown();
  }

frqReference es un PhantomReference a las que se usan ReferenceQueue, así que si este es el GC ed, no Finalizable{Débil, Suave, Fantasma}Referencias puede ser vivo, ya que hacen referencia a la cola.Así que tienen que ser GC ed antes de que la cola de sí mismo puede ser GC ed - pero aún así, podemos obtener la garantía de que estas referencias serán encolados a la ReferenceQueue en el fin de llegar "recolector de basura" (como si ellos consiguen GC ed uno por uno)?El código implica que exista algún tipo de garantía, de lo contrario no procesados referencias, en teoría, podría permanecer en la cola.

Gracias

Answer 1

No hay ninguna garantía de pedidos. En el caso de Finalizer.java, el hilo se puede apagar antes de que se procesan todas las referencias. Consulte la documentación de FinalizableReferenceQueue:

• Mantener una fuerte referencia a este objeto hasta que todo el asociado

• referentes han sido finalizados. Si este objeto se recoge la basura antes,
• el hilo de soporte no invoke {@code finalizeReferent ()} en la
• referencias restante.

Este es un comportamiento intencional. Por ejemplo, utilizamos FRQ para limpiar entradas de mapa cuando se borran las referencias a las teclas y / o valores. Si el usuario ya no tiene una referencia al mapa, ya su vez ya no tiene una referencia a la FRQ, no tiene sentido en el procesamiento de esas referencias.

Answer 2

estoy bastante seguro de que la respuesta es no.

La especificación JVM dice esto acerca de los métodos Finalizer:

  

La máquina virtual de Java no impone pedidos en llamadas a métodos de finalización. Los finalizadores se pueden llamar en cualquier orden o incluso simultáneamente. ( JVM espec 2.17.7 )

A partir de este deduzco que no hay garantías de que las referencias están en cola en orden topológico.

Answer 3

Creo que no existe tal garantía. La GC en sí no tiene una visión completa e inmediata de la RAM (no se puede, ya que las carreras de GC en la CPU que sólo puede mirar a unos pocos bytes a la vez). En su ejemplo, asumiendo una "marca y barrido" básica GC, lo más probable es que A y B se declararán inalcanzable en la misma fase de la marca, y barridos juntos en ningún orden en particular. Mantener el orden topológico, probablemente sería costoso.

En cuanto a Finalizer, parece que está destinado a ser utilizado a través de una instancia única FinalizableReferenceQueue, lo que lo hace un poco de magia cargador de clases relacionadas. El Finalizer utiliza sus propias instalaciones para detectar cuando el FinalizableReferenceQueue de la que depende funcionalmente se convierte en sí mismo inalcanzable; este es el punto en el hilo que corre Finalizer sabe que debe salir. Por lo que entiendo, si la aplicación permite que el GC recuperar el FRQ, a continuación, el subproceso finalizador saldrá, y cualquier referencia en cola "después" no se procesará la referencia FRQ. Esto depende del orden topológico o falta de ella, pero no puede decidir si esto es un problema o no. Creo que no se supone que la aplicación a abandonar su FRQ, siempre y cuando el procesamiento de objetos referenciados recuperados es importante.