Resumen del problema El ejemplo utiliza una clase Employee con campos id int name String salary int y sobreescribe equals y hashCode para basarse en esos campos. En el main se crean tres instancias e1 e2 e3 con datos similares y se añaden a un HashSet. Tras cambiar el campo id de e3 una vez ya añadido al conjunto se observa que al imprimir el contenido del HashSet aparecen dos objetos aparentemente idénticos
Ejemplo de valores usados en el ejemplo e1 id 1 nombre Ajay salario 20000 e2 id 1 nombre Ajay salario 20000 e3 id 2 nombre Ajay salario 20000
Salida esperada Antes de la modificación muestra dos elementos Employee id 2 name Ajay salary 20000 y Employee id 1 name Ajay salary 20000 Después de la modificación al cambiar e3 id a 1 la impresión puede mostrar dos elementos con id 1 El orden puede variar porque HashSet no garantiza orden de iteración
Por qué ocurre esto Cuando un elemento se añade a un HashSet el conjunto calcula hashCode para ubicar en qué bucket guardar el elemento y si encuentra otros con el mismo hash invoca equals para comprobar igualdad Si equals devuelve true no añade el elemento Esta comprobación se realiza solo en el momento de la inserción Si más tarde se modifica un campo que participa en hashCode o equals el valor de hashCode del objeto cambia pero el objeto permanece en el bucket correspondiente a su antiguo hash El resultado es que el set puede contener objetos que parecen duplicados y operaciones como contains o remove pueden fallar o comportarse de forma inesperada
Consejos para evitar el problema La estrategia más segura es usar objetos inmutables como claves o elementos en colecciones basadas en hash Evitar mutar los campos que participan en equals y hashCode después de la inserción Si no es posible la inmovilidad siga este procedimiento al modificar un objeto eliminar el objeto del conjunto actualizarlo y volver a añadirlo Alternativas técnicas incluyen usar colecciones que no dependan de hashCode como listas o TreeSet con un comparador estable
Ejemplo de solución práctica Hacer que los campos sean privados y finales eliminar setters o cualquier método que permita modificar id name o salary después de construir la instancia De este modo equals y hashCode permanecen estables durante toda la vida del objeto y HashSet funciona correctamente
Consideraciones adicionales Modificar objetos en colecciones hash puede llevar a fugas lógicas datos inaccesibles e imposibilidad para eliminar instancias Por eso es buena práctica diseñar modelos inmutables cuando se usan como claves o elementos únicos en colecciones hash
Sobre Q2BSTUDIO En Q2BSTUDIO somos una empresa de desarrollo de software dedicada a crear aplicaciones a medida y soluciones de software a medida para empresas de todos los tamaños Nos especializamos en inteligencia artificial ciberseguridad servicios cloud aws y azure servicios inteligencia de negocio y consultoría en ia para empresas Ofrecemos agentes IA integrados soluciones de Power BI y pipelines de datos para convertir información en decisiones estratégicas Nuestro equipo desarrolla aplicaciones a medida de alto rendimiento seguridad y escalabilidad con enfoque en soluciones personalizadas y transformación digital
Servicios destacados aplicaciones a medida software a medida inteligencia artificial ciberseguridad servicios cloud aws y azure servicios inteligencia de negocio ia para empresas agentes IA power bi
Si quieres evitar errores sutiles como la ilusión de duplicados en HashSet o necesitas ayuda para diseñar sistemas robustos y seguros contacta con Q2BSTUDIO Ofrecemos auditoría de código diseño de arquitecturas inmutables migración a servicios cloud y desarrollo de soluciones de inteligencia artificial a medida
Resumen final Entender que HashSet usa hashCode y equals en la inserción y que no reubica elementos cuando sus campos cambian es clave para evitar comportamientos inesperados La solución habitual es diseñar objetos inmutables o seguir el patrón eliminar modificar reinsertar para mantener la integridad de la colección