Código extraño en java.util.concurrent.LinkedBlockingQueue

Question

Todo!

me pareció extraño código en LinkedBlockingQueue:

private E dequeue() { 
     // assert takeLock.isHeldByCurrentThread(); 
     Node<E> h = head; 
     Node<E> first = h.next; 
     h.next = h; // help GC 
     head = first; 
     E x = first.item; 
     first.item = null; 
     return x; 
} 

que puede explicar por qué necesitamos variable local h? ¿Cómo puede ayudar a GC?

Answer 1

Para comprender mejor qué sucede, veamos cómo se ve la lista después de ejecutar el código. Consideremos en primer lugar una lista inicial:

1 -> 2 -> 3 

Entonces h puntos a head y first a h.next:

1 -> 2 -> 3 
| | 
h first 

Entonces h.next puntos a h y head puntos a first:

1 -> 2 -> 3 
| /\ 
h head first 

Ahora, practicamente sabemos que th Sólo hay referencia activa apuntando al primer elemento, que es por sí mismo (h.next = h), y también sabemos que el GC recopila objetos que no tienen más referencias activas, por lo que cuando el método finaliza, el (antiguo) encabezado de la lista ca debe ser recolectado de manera segura por el GC ya que h existe solo dentro del alcance del método.

Una vez dicho esto, se señaló, y estoy de acuerdo con esto, que incluso con el método clásico de quitar de la cola (es decir, sólo hacer first punto a head.next y head punto a first) no hay más referencias que apuntan hacia la cabeza de edad . Sin embargo, en este escenario, la cabeza anterior se deja colgando en la memoria y todavía tiene su campo next apuntando hacia first, mientras que en el código que publicó, lo único que queda es un objeto aislado que apunta a sí mismo. Esto puede provocar que el GC actúe más rápido.

Answer 2

Aquí hay un ejemplo de código que ilustra la pregunta: http://pastebin.com/zTsLpUpq. Realizar un GC después de runWith() y tomar un volcado de almacenamiento dinámico para ambas versiones indica que solo hay una instancia de artículo.

Answer 3

Tal vez un poco tarde, pero la explicación actual es completamente insatisfactoria para mí y creo que tengo una explicación más sensata.

En primer lugar, cada java GC realiza algún tipo de rastreo desde un conjunto raíz de una manera u otra. Esto significa que si se recolecta el encabezado anterior no leeremos la variable next de ninguna manera; no hay ninguna razón para hacerlo. Por lo tanto, IF cabeza se recoge en la siguiente iteración, no importa.

El IF en la oración anterior es la parte importante aquí. La diferencia entre la configuración al lado de algo diferente no es importante para recolectar la cabeza, pero puede hacer una diferencia para otros objetos.

Supongamos un GC generacional simple: si la cabeza está en el conjunto joven, de todos modos se recogerá en el siguiente GC. Pero si está en el conjunto anterior, solo se recopilará cuando hagamos un GC completo, lo que ocurre con poca frecuencia.

Entonces, ¿qué sucede si la cabeza está en el conjunto anterior y hacemos un GC joven?En este caso, la JVM supone que todos los objetos en el antiguo montón todavía están vivos y agrega todas las referencias de los objetos antiguos a los jóvenes al conjunto raíz del GC joven. Y eso es exactamente lo que la tarea evita aquí: escribir en el antiguo montón generalmente está protegido con una barrera de escritura o algo así para que la JVM pueda atrapar tales asignaciones y manejarlas correctamente; en nuestro caso, elimina el objeto next apuntado desde el conjunto raíz que tiene consecuencias

ejemplo corto:

Asumamos que tenemos 1 (old) -> 2 (young) -> 3 (xx). Si eliminamos 1 y 2 ahora de nuestra lista, podemos esperar que ambos elementos sean recopilados por el próximo CG. Pero si solo se produce un GC joven y NO hemos eliminado el puntero next en antiguo, no se recopilarán los elementos 1 y 2. Contrariamente a esto si hemos eliminado el puntero en 1, 2 serán recogidos por los jóvenes GC ..

Answer 4

Si nos fijamos en el src jsr166 continuación, se encuentra el infractor commit

http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/LinkedBlockingQueue.java?view=log (ver v 1.51)

esto demuestra que la respuesta es en este informe de error

http://bugs.sun.com/view_bug.do?bug_id=6805775

la discusión completa es en este hilo

http://thread.gmane.org/gmane.comp.java.jsr.166-concurrency/5758

El bit "ayuda GC" trata de evitar que las hemorragias se conserven.

Saludos

Matt