Recientemente hice una pequeña investigación sobre la mejor forma de identificar una instancia de un objeto de forma única, de forma que podamos utilizar dicho UID (Unique identifier). Este identificador puede ser muy útil a la hora de cachear instancias , por ejemplo en un HashMap.
Documentándome un poco por la red, he leído muchas "soluciones", algunas más acertadas y otras menos, y he aquí el verdadero motivo de que escriba esta entrada.
Cualquier desarrollador con un poco de experiencia en Java sabrá que esto se resuelve usualmente mediante el método hashCode, el cuál genera un código de hash para un objeto, que nos permite indexarlo fácilmente. Pero, ¿que pasa cuando se han sobrecargado dicho método generando un override del objeto que cambia su funcionalidad?. Este escenario es bastante habitual, ya que se suelen generar los métodos equals y hashCode, para poder comparar objetos y saber a igualdad de datos si se trata del mismo objeto.
Una cosa que ha llamado mi atención en particular es que en muchos sitios proponen usar el método toString, para obtener a un identificador único, siempre y cuando no se halla sobreescrito dicho método en las clases. Esta suposición no es errónea per se, pero resulta curiosa la forma de usar dicho método, y las limitaciones que conlleva (ya que no podremos modificar el método toString). Este método se basa en la implementación del método toString en la clase java.lang.Object, el cuál concatena el nombre de la clase con el hashcode y no con la dirección de memoria como cree mucha gente. El formato de la String devuelta puede verse en la documentación de Java):
public String toString() {
return getClass().getName() + '@' + Integer.toHexString(hashCode());
}Si esto es así, dicha solución tampoco funcionará en todos los casos, si hemos hecho un override del método hashCode basándonos en algunos datos, o cuando menos no podemos decir que la "resistencia a colisiones" sea alta.
En estas situaciones lo mejor sería utilizar el método hashCode original de la clase Object, el cual asegura que dos instancias distintas, aún cuando tengan los mismo datos, devolverán un hashCode diferente. Esto se debe a que el calculo de los datos se hace de forma nativa en base a la dirección de memoria donde se encuentra la instancia:
public int hashCode() {
return VMMemoryManager.getIdentityHashCode(this);
}
Para acceder al método de forma independiente de si lo hemos sobreescrito podemos usar la clase System, llamando al metodo identityHashCode.
System.identityHashCode(object);
Otra opción un poco más "delicada" es usar la clase sun.misc.Unsafe, para obtener la dirección real de memoria, podemos leer un poco más sobre ello aquí. esto es algo totalmente irrecomendable, que tiene cabida sólo como investigación para aquellos que gusten de saber como funcionan las cosas (Para que la llamaron Unsafe si no querían que trasteáramos con ella. XD).
