¿Cuáles son las debilidades en el uso del modelo Immutability + Actor para la programación de simultaneidad?

Question

Mientras construía una gran aplicación multihilo para la industria de servicios financieros, utilicé clases inmutables y un modelo Actor para el flujo de trabajo donde pude. Estoy bastante satisfecho con el resultado. Utiliza una buena cantidad de espacio de montón (está en Java por cierto) pero el GC de JVM funciona bastante bien con clases inmutables de corta duración.

Me pregunto si hay algún inconveniente en el uso de este tipo de patrón en el futuro? Al depurar un código de compañeros de equipo, a menudo me encuentro recomendando este patrón de una forma u otra. Supongo que una vez que alguien tiene un martillo, todo parece un clavo. Entonces la pregunta es: ¿Cuándo funcionaría mal este patrón de diseño (paradigma?).

Mi corazonada es cuando el uso de memoria es un gran problema o cuando las restricciones del proyecto requieren algo en la línea de bajo nivel C, etc.

Answer 1

Muchos códigos simulaciones científicas son realmente mucha memoria. Por ejemplo, para los modelos de autómatas celulares, el acceso rápido a la memoria es más importante que la potencia de la CPU. En ese caso, acceder y modificar una matriz mutable siempre es más rápido (al menos en todas mis pruebas).

Answer 2

Todo depende del diseño de su proyecto.

Si tiene algún recurso y muchos actores lo usan, entonces el patrón común es diseñar el actor de acceso. Entonces, cuando algún otro actor necesita preguntar acerca de algún recurso, pregunta sobre él, el acceso o el actor. Luego, la respuesta se copia a través del canal de mensajes.

Ahora imagina que tienes recursos muy pesados ​​(por ejemplo, map[String, BigObject]) y otros actores suelen preguntar acerca de algunos BigObject y luego pierdes el ancho de banda.
Mejor idea sería compartir el recurso con todos los actores en modo solo lectura, y hacer que un actor realice escribe.

Otro ejemplo sería el conector de la base de datos que se conecta a la base de datos con una gran cantidad de blob de datos. Cuando el conector de la base de datos es seguro para subprocesos (como normalmente lo es), es mejor compartir la referencia del objeto conector a todos los actores, y luego diseñar un actor que proporcione el acceso.

Todo lo que necesita para recordar que la comunicación entre los actores se realiza copiando mensajes.