Каковы недостатки в использовании модели Immutability + Actor для программирования concurrency?

При создании большого многопоточного приложения для индустрии финансовых услуг я использовал неизменные классы и модель Actor для рабочего процесса во всем мире. Я очень доволен результатом. Он использует достаточное количество кучи пространства (его в Java, но Btw), но JVM GC работает очень хорошо с недолговечными неизменяемыми классами.

Мне просто интересно, есть ли какие-либо недостатки для использования такого рода шаблонов в будущем? Когда вы отлаживаете код товарищей по команде, я часто нахожу, что так или иначе рекомендую этот шаблон. Думаю, когда у кого-то есть молоток, все выглядит как гвоздь. Поэтому возникает вопрос: когда эта схема проектирования (парадигма?) Работает плохо?

Моя догадка заключается в том, что использование памяти является большой проблемой или когда ограничения проекта требуют чего-то в строках низкого уровня C и т.д.

Ответ 1

Многие коды моделирования науки действительно интенсивно занимают память. Например, для моделей сотовых автоматов быстрый доступ к памяти более важен, чем мощность процессора. В этом случае доступ и изменение на месте изменяемого массива всегда быстрее (по крайней мере, во всех моих испытаниях).

Ответ 2

Все зависит от вашего проекта.

Если у вас есть какой-то ресурс, и многие участники используют его, тогда общая картина заключается в создании аксессуаров-актеров. Затем, когда какой-либо другой актер должен спросить о каком-то ресурсе, он спрашивает об этом актер-актер. Затем ответ копируется через канал сообщений.

Теперь представьте себе - у вас действительно тяжелый ресурс (например, map[String, BigObject]), а другие актеры часто спрашивают о некоторых BigObject, тогда вы теряете свою пропускную способность.
Лучшей идеей было бы разделить ресурс со всеми участниками в режиме readonly и заставить одного актера выполнять записи.

Другим примером может быть соединитель базы данных, который подключается к базе данных с большим количеством данных blob. Когда соединитель базы данных является потокобезопасным (как обычно), лучше использовать ссылку на объект соединителя для всех участников, а затем сконструировать некоторого актера, который обеспечивает доступ.

Все, что вам нужно запомнить, это то, что общение между участниками осуществляется путем копирования сообщений.