Revisando los objetos inmutables: implementación, ventajas y desventajas
Piense en un objeto de orden asignado al mundo real.
Si el estado de este contenedor es mutable, se llama objeto mutable; de lo contrario, se llama objeto inmutable. Artículos anteriores han enfatizado repetidamente los beneficios de los objetos inmutables.
Aquí tienes un breve resumen.
La implementación específica de objetos inmutables también es muy simple.
Si estás utilizando una versión antigua como Java 8, puedes marcar cada campo como final o eliminar todos los métodos públicos equivalentes a operaciones de configuración.
Si está utilizando una nueva versión como Java17, simplemente use la clase de registro directamente.
1. Ventajas
Los objetos inmutables se pueden pasar de manera más informal
En el caso de un solo hilo, no hay necesidad de preocuparse por el paso del objeto. un determinado método, algunos atributos fueron modificados inexplicablemente. Si es un objeto mutable, para evitar cambios de atributos, debe hacer una copia del objeto y luego pasar la copia.
En el caso de subprocesos múltiples, una vez que se construye el objeto, no hay necesidad de preocuparse por la carrera de datos cuando el objeto es procesado por varios subprocesos al mismo tiempo.
Piensa en sincronizado o ReentrantLock. Si se trata de programación de pizarra durante una entrevista, es posible que la mayoría de las personas ni siquiera puedan deletrear las palabras correctamente, y mucho menos el ensayo de ocho partes sobre ellas.
Los objetos variables no deben usarse como clave de HashMap/HashSet
Según el principio de HashMap, al calcular el valor hash, se basará en el estado del objeto. (es decir, algunos o todos los campos) para calcular.
Por lo tanto, si se utiliza un objeto mutable como clave, una vez que se cambia el estado del objeto, el valor hash creído definitivamente cambiará en consecuencia y no se podrá encontrar el registro original en función de una determinada clave. Los objetos inmutables no tienen este problema.
2. Desventajas
Se crearán muchos objetos
Por ejemplo:
Cadena de saludo = "Hola"
saludo += ", Mundo!"
Debido a que el tipo String es inmutable en Java, se creará más de un objeto debajo.
Este fenómeno es particularmente obvio en Spark. Cada operación en RDD, ya sea filtro, mapa, grupo, unión, etc., generará un nuevo RDD.
Una cosa más: puede utilizar el patrón de diseño Flyweight en el patrón de diseño para resolver parcialmente este problema.
Puede haber un cuello de botella en el rendimiento.
Debido a que los objetos deben copiarse con frecuencia, el rendimiento será peor que actualizar directamente un atributo.
Una cosa más: si se trata de un desarrollo de tipo no middleware, este consumo adicional es completamente insignificante en comparación con una llamada RPC.