При создании большого многопоточного приложения для индустрии финансовых услуг я использовал неизменные классы и модель Actor для рабочего процесса во всем мире. Я очень доволен результатом. Он использует достаточное количество кучи пространства (его в Java, но Btw), но JVM GC работает очень хорошо с недолговечными неизменяемыми классами.
Мне просто интересно, есть ли какие-либо недостатки для использования такого рода шаблонов в будущем? Когда вы отлаживаете код товарищей по команде, я часто нахожу, что так или иначе рекомендую этот шаблон. Думаю, когда у кого-то есть молоток, все выглядит как гвоздь. Поэтому возникает вопрос: когда эта схема проектирования (парадигма?) Работает плохо?
Моя догадка заключается в том, что использование памяти является большой проблемой или когда ограничения проекта требуют чего-то в строках низкого уровня C и т.д.
Многие коды моделирования науки действительно интенсивно занимают память. Например, для моделей сотовых автоматов быстрый доступ к памяти более важен, чем мощность процессора. В этом случае доступ и изменение на месте изменяемого массива всегда быстрее (по крайней мере, во всех моих испытаниях).
Все зависит от вашего проекта.
Если у вас есть какой-то ресурс, и многие участники используют его, тогда общая картина заключается в создании аксессуаров-актеров. Затем, когда какой-либо другой актер должен спросить о каком-то ресурсе, он спрашивает об этом актер-актер. Затем ответ копируется через канал сообщений.
Теперь представьте себе - у вас действительно тяжелый ресурс (например, map[String, BigObject]), а другие актеры часто спрашивают о некоторых BigObject, тогда вы теряете свою пропускную способность.
Лучшей идеей было бы разделить ресурс со всеми участниками в режиме readonly и заставить одного актера выполнять записи.
Другим примером может быть соединитель базы данных, который подключается к базе данных с большим количеством данных blob. Когда соединитель базы данных является потокобезопасным (как обычно), лучше использовать ссылку на объект соединителя для всех участников, а затем сконструировать некоторого актера, который обеспечивает доступ.
Все, что вам нужно запомнить, это то, что общение между участниками осуществляется путем копирования сообщений.