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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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