70 votos

Pros y Contras de los Oyentes como WeakReferences

¿Cuáles son los pros y los contras de mantener a los oyentes como WeakReferences.

El gran "Pro", por supuesto, es que:

La adición de un agente de escucha como un WeakReference significa que el oyente no tiene que molestarse en "eliminar".

Actualización

Para aquellos preocupados por la escucha de tener la única referencia al objeto, ¿por qué no puedo hay 2 métodos, el método addListener() y addWeakRefListener()?

aquellos que no cuidan sobre la eliminación puede utilizar este último.

69voto

BegemoT Puntos 2020

Primero de todos, el uso de WeakReference en los oyentes listas le dará a su objeto de diferentes semántica, a continuación, utilizando duro referencias. En caso de referencia de addListener(...) significa "notificar objeto proporcionado acerca de evento específico(s) hasta que me deje explícitamente con removeListener(..)", en la debilidad de referencia caso significa "notificar objeto proporcionado acerca de evento específico(s) hasta que este objeto no será utilizada por nadie (o explícitamente parada con removeListener)". Aviso, es perfectamente legal en muchas situaciones a tener objeto, la escucha de algunos eventos, y al no tener otras referencias el mantenimiento de la GC. Registrador puede ser un ejemplo.

Como se puede ver, el uso de WeakReference no acaba de resolver un problema ("que debe tener en mente para que no se olvide de quitar añadido escucha en algún lugar"), pero también lugar a otro, "debo de tener en mente lo que mi oyente ca dejar de escuchar en cualquier momento en donde hay más referencia a él". Usted no resuelve el problema, sólo el comercio de un problema por otro. Mira, de alguna manera has obligado a definir claramente, diseño y seguimiento periodo de vida de usted escucha -- de una manera o de otra.

Así que, personalmente, estoy de acuerdo con mencionar lo uso WeakReference en los oyentes listas es más como un hack whan una solución. Es el patrón de la pena saber acerca de, a veces, puede ayudar a usted, para hacer que el legado del código de trabajo, por ejemplo. Pero no es el patrón de elección :)

P. S. También cabe señalar lo WeakReference introducir adicionales en el nivel de direccionamiento indirecto, que, en algunos casos con muy altas tasas de eventos, puede reducir el rendimiento.

31voto

Kirk Woll Puntos 34601

Esto no es una respuesta completa, pero la fuerza que mencionas puede ser también su principal debilidad. Considere lo que sucedería si la acción de los oyentes fueron implementadas débilmente:

button.addActionListener(new ActionListener() {
    // blah
});

Que la acción de escucha se va a obtener de la basura recolectada en cualquier momento! No es raro que la única referencia a una clase anónima es el evento al que desea agregar.

10voto

JVerstry Puntos 12414

He visto toneladas de código, donde los oyentes no eran no registrados correctamente. Esto significa que todavía se llamaban innecesariamente para realizar tareas innecesarias.

Si sólo uno de la clase, se basa en un detector, entonces es fácil de limpiar, pero ¿qué sucede cuando el 25 de clases confiar en ella? Se vuelve mucho más difícil de eliminar del registro a ellos correctamente. El hecho es que su código puede comenzar con un objeto hace referencia a su oyente y al final hasta en un futuro con la versión 25 de objetos de referencia que el mismo oyente.

No usar WeakReference es equivalente a tomar un gran riesgo de consumo innecesario de memoria y cpu. Es más complicado, más complicado y requiere más trabajo duro, las referencias en el código complejo.

WeakReferences están llenas de ventajas, ya que se limpian automáticamente. La única contra es que usted no se olvide de mantener un duro referencia en el resto del código. Normalmente, en los objetos de depender de este tipo de oyente.

Yo odio el código de la creación anónima instancias de la clase de oyentes (como se ha mencionado por Kirk Woll), porque una vez registrado, usted no puede anular el registro de estos oyente más. Usted no tiene una referencia a ellos. Es realmente mala codificación en mi humilde opinión.

También puede null una referencia a un detector cuando no la necesito. Usted no necesita preocuparse de nada más.

5voto

James Scriven Puntos 2027

En realidad no hay profesionales. Un weakrefrence se utiliza generalmente para "opcional" de datos, tales como una memoria caché en la que usted no desea evitar que la recolección de basura. Usted no quiere que su oyente de basura recogidos, que usted desea que se siga escuchando.

Actualización:

Ok, creo que yo podría haber imaginado lo que usted está consiguiendo. Si usted está agregando de corta duración a los oyentes a la larga duración de los objetos no puede ser de beneficio en el uso de un weakReference. Así, por ejemplo, si se agregan PropertyChangeListeners a su dominio de objetos para actualizar el estado de la interfaz gráfica de usuario que es constantemente recreado, los objetos de dominio se va a celebrar en el Gui, lo que podría generar. Pensar en un gran cuadro de diálogo emergente que está siendo constantemente recreado, con un detector de referencia de nuevo a un Empleado objeto a través de un PropertyChangeListener. Me corrija si estoy equivocado, pero no creo que toda la PropertyChangeListener patrón es muy popular ya.

Por otro lado, si usted está hablando acerca de los oyentes entre los elementos de la GUI o tener objetos de dominio escuchar a los elementos de la GUI, no comprar nada, ya que cuando la GUI se va, también lo será la de los oyentes.

Aquí hay un par de interesantes lecturas:

http://www.javalobby.org/java/forums/t19468.html

Cómo resolver swing detector de fugas de memoria?

4voto

Nicolas Bousquet Puntos 2245

Para ser honesto, realmente no comprar esa idea y exactamente lo que usted espera hacer con un addWeakListener. Tal vez sea sólo yo, pero parece ser un mal buena idea. En primer lugar, es seducir, pero el problema que se puede implica no son despreciables.

Con weakReference usted no está seguro de que el oyente ya no se llamará cuando el oyente ya no se hace referencia. El recolector de basura puede liberar menmory un par de ms más tarde o nunca. Esto significa que puede seguir consumiendo CPU y hacer extraño que este como lanzando una excepción porque el oyente no debe ser llamado.

Un ejemplo con swing sería la de tratar de hacer las cosas sólo se puede hacer si su componente de interfaz de usuario está realmente asociado a una ventana activa. Esto podría lanzar una excepción, y afectar el notificador de hacer que se bloquee y la prevención de la validez de los oyentes a ser notofied.

Segundo problema como ya se ha dicho es anónima, el que escucha, el que podría ser liberado muy pronto nunca notificó a todos o sólo un par de veces.

Lo que estamos tratando de lograr es peligroso, ya que no puede controlar más cuando usted deja de recibir notificaciones. Pueden durar para siempre o detener demasiado pronto.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by: