Quali sono i punti deboli nell'utilizzo del modello di Immutability + Actor per la programmazione della concorrenza?

Question

Durante la creazione di una grande applicazione multi-thread per il settore dei servizi finanziari, ho utilizzato classi immutabili e un modello di attore per il flusso di lavoro ovunque potessi. Sono piuttosto soddisfatto del risultato. Usa una buona quantità di spazio heap (è in Java btw) ma il GC della JVM funziona piuttosto bene con classi immutabili di breve durata.

Mi chiedo solo se ci sono degli svantaggi nell'usare questo tipo di schema in futuro? Quando eseguo il debug di un codice di compagni di squadra, spesso mi ritrovo a raccomandare questo modello in un modo o nell'altro. Immagino che una volta che uno ha un martello, tutto sembra un chiodo. Quindi la domanda è: quando questo modello di progettazione (paradigma?) Funzionerà male?

La mia impressione è quando l'utilizzo della memoria è un grande problema o quando le restrizioni del progetto richiedono qualcosa lungo le linee di basso livello C, ecc

Answer 1

Molti scienza codici simulazioni sono davvero intensivo di memoria. Ad esempio, per i modelli di automi cellulari l'accesso veloce alla memoria è più importante della potenza della CPU. In tal caso, l'accesso e la modifica di un array mutabile è sempre più veloce (almeno in tutte le mie prove).

Answer 2

Tutto dipende dalla progettazione del progetto.

Se avete un po 'di risorse e molti attori lo usano, il modello comune è progettare un attore che acceda. Poi, quando qualche altro attore ha bisogno di chiedere informazioni su qualche risorsa, gli chiede informazioni sull'attore. Quindi la risposta viene copiata attraverso il canale dei messaggi.

Ora immagina - hai una risorsa davvero pesante (ad es.
L'idea migliore sarebbe quella di condividere la risorsa per tutti gli attori nella modalità a sola lettura e creare un attore per eseguire scritture.

Altro esempio sarebbe connettore di database che si collega al database con un numero di dati BLOB. Quando il connettore del database è thread-safe (come avviene normalmente) è meglio condividere il riferimento all'oggetto connettore a tutti gli attori, quindi progettare un attore che fornisce l'accesso.

Tutto ciò che serve per ricordare ogni comunicazione tra attori viene eseguita copiando messaggi.