Referencias en Java II: referencias débiles
En un post anterior escribí sobre los distintos tipos de referencias a objetos que se pueden usar en Java. Hoy propongo echar mano a un poco de código y ver como se utilizan las referencias débiles, ó weak references.
El secreto de todo esto de las referencias se encuentra en el package java.lang.ref que consta de un par de clases:
+ Reference
+WeakReference
+PhantomReference
+SoftReference
+ ReferenceQueue
WeakReference es la clase que nos ocupa hoy y sirve para instrumentar a las famosas referencias débiles que mencione tiempo atras. Mirando todo mas pragmaticamente la diferencia entre estas weakreferences y las referencias fuertes radica en el momento de la creacion y el posterior acceso al objeto al que esta apunta. El siguiente codigo muestra el caso tipico entre dos objetos que se referencian mutuamente. La vista representa una pantalla de programa y Modelo algun objeto de dominio de negocio. Ambos objetos necesitan referencias al otro para implementar el patron observer que permita la comunicación correcta de estos dos componentes.
class Vista {
Modelo modelo;
public void imprimirModelo() {
System.out.println(modelo.value);
}
public void setModelo(Modelo m) {
modelo = m;
}
}
class Modelo {
int value;
WeakReference<Vista> vista; //referencia debil a la vista
public boolean existsVista() {
return this.vista.get()!=null;
}
public void actualizarVista() {
Vista miVista = this.vista.get(); //miVista es referencia fuerte a vista
//le avisa a la vista q cambio el modelo y debe actualizarse
//miVista.update();
}
public WeakReference<Vista> getVista() {
return vista;
}
public void setVista(Vista v) { //setter con weakreferences
vista = new WeakReference<Vista>(v);
}
}
La clase vista no tiene ningun comportamiento extraño, no podemos decir lo mismo de la clase Modelo. En ella vemos que la declaracion de una referencia debil se hace mediante la clase WeakReference indicando con generics la clase a la que va a apuntar esta referencia, en nuestro caso Vista.
Los accesors a este atributo son un tanto particulares, el setter recibe una referencia fuerte a Vista y que es envuelta con el constructor de WeakReference y finalmente asignada al atributo. El getter, sin embargo, devuelve un objeto de clase WeakReference. Con este objeto podemos obtener una referencia fuerte al objeto vista utilizando el metodo get().
El metodo existsVista() simplemente devuelve verdadero o falso indicandonos si existe el objeto al que apunta la referencia vista o si ya fue eliminado por el gc.
Un caso tipico de uso de estas clases, a saber:
public class Main {
public static void main(String[] args) {
Modelo m = new Modelo(); //creamos el modelo
Vista v = new Vista(); //creamos la vista
v.setModelo(m); //se aparean la vista y el modelo
m.setVista(v); //hay que recordar que setVista envuelve
//el parametro con una WeakReference
m.value = 77;
v.imprimirModelo();
//Imprime 77... como podria esperarse
v = null; //no queremos usar más la vista.
System.gc(); //pasa el basurero
System.out.println(m.existsVista());
}
}
Imprime false porque la referencia fuerte que apuntaba a la vista ya no lo hace. La unica referencia a ese objeto que queda es el atributo del modelo, que por ser una referencia debil el gc la ignora.
Recomiendo pasar estos pedazos de códigos por el amigo debugger e ir siguiendo el movimiento de las referencias y como desaparecen los objetos por arte de magia. En otro momento seguimos con las referencias fantasmas y blandas.
Puzzle!
¿Qué imprime este programa y por qué?
public class Puzzle {
public static void main(String args[]) {
int x = 0x3;
// AYUDITA: public class declara// una nueva clase. main es el metodo
// principal o entry point //del programa y String[] almacena un array
// de String que son // cadenas de caracteres que se guardan usando
// unicode que es un conjunto //de caracteres donde la letra a se escribe
// con \u0061 la letra b // con \u0062 y linefeed se representa con
// \u000A x++; // se usa para postincrementar una variable x//
// ++x;// se utiliza para preincrementar una variable x x+=2 incrementa
// en 2 a x; // los literales que empiezan con 0x se tratan como
// hexadecimales en java.
System.out.println(x+1-1);
}
}
La mejor respuesta se lleva un premio 
Bueno despues de mucho deliberar (?) decreto que el justo ganador del puzzle es Sherekan! quien se hace acreedora del siguiente premio:
2 (dos) libros “El Lenguaje de Programación Java SL-275″ compuesto por una Guía de Estudiante y Guía Práctica. Publicados por Sun Microsystems. Fuerte el aplauso!
Referencias en Java I
En Java existe más de una forma de “apuntar” a un objeto usando una referencia. Hay de hecho cuatro tipos distintos de referencias. Esto se debe a lo extraño que resulta a veces la forma en que trabaja el Garbage Collector. A pesar de contar con variedad de formas de referenciar a un objeto, normalmente se utiliza una sola.
Nota: Este tema es bastante largo y tedioso incluso. Está dividido en varias entregas con el fin de salvaguardar la integridad mental de los posibles lectores ante una indigestión por lectura violenta.
Motivación.
El Garbage Collector es un ser extraño. Repasemos por un segundo como funciona este particular habitante de la JVM. Cuando se inicia un programa en Java y se comienzan a crear objetos aparece un conjunto de referencias denominado root set donde se encuentran las referencias declaradas dentro del metodo main(), o run() si estamos trabajando con varios threads. Luego durante la ejecución del programa aparecerán otras referencias pero como atributos de algún objeto cuya referencia este en el root set. En la imagén, que tomé del excelente Hardcore Java de Robert Simmons Jr, se ve como en un metodo main() se crean tres referencias A, C y H a objetos a partir de las cuales se forma el grafo (fig.1).
Si cambiaramos en A la referencia que posee a B haciendola apuntar a null (fig.2) el Garbage Collector no eliminaria el objeto B puesto que aún existe un camino a traves de C->F->X->D->J->E->B. De esa forma funciona el Garbage Collector, elimina los objetos que no pueden ser accedidos a traves de un camino que se inicie en el root set. Esto es particularmente util para evitar las “islands of isolations” cuando hay un grupo de objetos con referencias entre si pero que no pueden ser accedidos por el thread principal.
Este comportamiento, en un principio benigno, es la principal causa de memory leaks en las aplicaciones cuando tenemos referencias circulares entre dos objetos o más objetos. Supongamos que el grafo representa una aplicación con interfaz gráfica donde A es la GUI y C el objeto a partir del cual se arma la lógica de negocios. El objeto A posee muchas referencias a otros objetos (panels, botones, textfields) y C a todas las clases del negocio. Ademas, como en todas las aplicaciones con GUI, se unen ambos mundos (Vista y Modelo) con algun mecanismo de Listeners que implemente el patrón observer. ¿Que pasa sí, como en el ejemplo anterior, el objeto B es una ventana a la que dejamos de referenciar desde A porque no queremos utilizarla más? Evidentemente aún queda un camino a traves del cual se puede acceder a este objeto, como vimos más arriba, por lo que la ventanita no es elegible para ser eliminada por el garbage collector. Tenemos una ventana en memoria (con todos sus componentes) que no queremos usar más pero sigue apuntada por un listener. Tenemos un Memory Leak.
Los cuatro tipos de referencias.
Java nos provee cuatro tipos de referencias distintos para ayudarnos a evitar problemas como el visto aguas arriba sin ensuciar el codigo con aventuradas técnicas de manejo de Listeners. Estos cuatro tipos de referencia son: Fuerte, Débil, Blanda y Fantasma.
- Referencia Fuerte Las referencias a objetos que se utilizan en java comunmente son referencias fuertes (ó strong references). Su comportamiento es por demas conocido por todos. Apuntan a un objeto y lo mantienen en memoria mientras esta referencia se mantenga. Cuandro creamos un String texto = “algo” estamos creando una referencia fuerte apuntando a un objeto de tipo String.
- Referencia Débil Una referencia debil (weak reference) es una referencia común y corriente pero con una salvedad: Si un objeto es apuntado solo por referencias debiles, sera elegible por el garbage colector para ser eliminado. Es decir, en el momento de elegir que objetos seran eliminados el GC ignora las referencias debiles haciendo como si no existieran.En el grafo original se reemplazan las referencias fuertes circulares, potencialmente peligrosas, por referencias debiles (indicadas en la figura con una flecha doble).
¿Qué sucede si ahora dejamos de apuntar a B desde A? ¡Sorpresa! B es elegible para ser eliminado.
- Referencia Blanda Las referencias blandas (soft reference) se comportan como las referencias debiles pero el garbage collector va a eliminar los objetos unicamente si tiene poco espacio en el Heap. Digamos que si un objeto esta siendo apuntado unicamente por referencias blandas el garbage collector puede elegirlo para eliminación si tiene poca memoria en el heap, sino no necesariamente va a eliminarlo. Este comportamiento sin embargo, como pasa con todo lo relacionado al garbage collector, es dependiente de la implementación y en la práctica las referencias blandas son tratadas como referencias debiles por la Java Virtual Machine.
- Referencia Fantasma El tipo más enigmático de todos y su uso es, por lo menos, tan bizarro como su nombre. La referencia fantasma (phantom reference) apunta a un objeto cuando este ya ha sido eliminado por el GC. Si, una vez que el objeto pasa por el GC la referencia fantasma apunta a él. Sin embargo no puede usarse para acceder a ningún miembro de este objeto, sino solo para saber que estuvo ahí en algun momento. ¿Extraño verdad? Su uso más común es contar cuantos objetos han sido eliminados y en técnicas de profilling.
Con estos cuatro tipos de referencias podemos lograr que nuestros programas hagan un uso más racional de la memoria pero como aplicarlos queda para mas adelante. Antes de terminar esta primera entrega es menester recordar que estos no son structurals patterns o algo parecido sino que java nos ofrece una API estandar para implementarlos programaticamente.
Errores y Excepciones
You are not required to catch Error objects or Error subtypes. You can also throw an Error yourself (although other than AssertionError you probably won’t ever want to), and you can catch one, but again, you probably won’t. What, for example, would you actually do if you got an outOfMemoryError? It’s not like you can tell the garbage collector to run; you can bet the JVM fought desperately to save itself (and reclaimed all the memory it could) by the time you got the error. In other words, don’t expect the JVM at that point to say, “Run the garbage collector? Oh, thanks so much for telling me. That just never occurred to me. Sure, I’ll get right on it.” Even better, what would you do if a VirtualMachineError arose? Your program is toast by the time you’d catch the Error, so there’s really no point in trying to catch one of these babies. Just remember, though, that you can!
Katty Sierra es lo más…
Identificadores Unicode en Java
Hablando de Unicode recorde algo que a veces pasa inadvertido pero puede ser beneficioso.
Como los colegas rusos saben ДОМ o Привет son identificadores válidos en cualquier compilador Java. Java admite cualquier letra unicode como identificador. Ojo que dije letra y no caracter, para ver que diablos es una letra y que no lo es dentro de la interminable tabla Unicode tenemos dos metodos más que utiles:
boolean Character.isJavaIdentifierStart(char c)
y
boolean Character.isJavaIdentifierPart(char c)
Ambos devuelven true si el caracter que se le paso como parametro puede utilizarse al comienzo de un identificador o como parte de este respectivamente.
Por lo tanto podriamos declarar tranquilamente una
public class Murciélago
Lo cual puede llegar a ser medio molesto para andar tipeando los acentos pero esta caracteristica, a veces olvidada, llega como un regalo del cielo cuando hay que hacer una
public class Ñandu
Ahora no hay más excusas para el horrendo
private int anio;
en lugar de año 
