Сообщение актера Akka нуждается в пуле памяти

Использование ArrayBlockingQueue для хранения пула ваших объектов должно помочь,

Вот пример кода.

Чтобы создать пул и вставить в него экземпляр объекта пула.

BlockingQueue<YOURCLASS> queue = new ArrayBlockingQueue<YOURCLASS>(256);//Adjust 256 to your desired count. ArrayBlockingQueues size cannot be adjusted once it is initialized.


queue.put(YOUROBJ); //This should be in your code that instanciates the pool

и позже там, где вам это нужно (в вашем актере, который получает сообщение)

YOURCLASS instanceName = queue.take();

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

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

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

Да, когда GC срабатывает, приложение будет немного лагать при больших нагрузках. Но в 95% сценариев, особенно в такой производительной среде, как Akka, GC не будет вашим узким местом: IO будет.

Я не говорю, что вы не должны этого делать. Я говорю, что прежде чем браться за задачу, учитывая ее нетривиальность, вы должны измерить влияние GC на ваше приложение во время выполнения с помощью таких вещей, как Kamon или другие специализированные решения для мониторинга Akka, и только после того, как вы убедитесь, что это того стоит, вы можете пойти на это.

Можно создать пул объектов, чтобы свести к минимуму длинный хвост задержки (пожертвовав медианой в многопоточной среде). рассмотрите возможность использования соответствующих очередей, например. от JCTools, Distruptor или Agrona. Не забывайте о правилах взаимодействия для обмена состоянием через изменяемое состояние с использованием нескольких чтений в хранимых объектах - https://youtu.be/nhYIEqt-jvY (лучший контент, который мне удалось найти).

Опять же, не ожидайте улучшения во всем, используя такие слегка опасные техники. Вы потеряете эффективность кеша L1-L3 и оградите PCI барьерами.

Немного касательной (чтобы понять технологию с низкой задержкой): можно рассмотреть некоторую реализацию GC с более низкой задержкой, если вы хотите придерживаться Akka, или использовать пользовательскую реактивную модель, в которой пул объектов используется одним потоком, или память копируется, например. Подход Disrupptor. Другой альтернативой является использование областей памяти (как работает Erlang VM). Он создает мусор, но по форме легко обрабатывается сборщиком мусора!

Если вы переходите на ввод-вывод с очень малой задержкой и являетесь самым большим врагом задержки - забудьте о устаревшем TCP (по сравнению с RDMA через Infininiband), о коммутаторах (по сравнению с swichless), о доступе ОС к диску через вызовы ОС и файловой системе (используйте RDMA), забудьте о прерываниях, разделяемых одно и то же ядро, не закрепленные ядра (и без вращения для ввода) к реальному ядру ЦП (по сравнению с виртуальными/гиперпотоками) или обмен данными между NUMA или сообщения один за другим вместо аппаратной многоадресной рассылки (или лучше оптического коммутатора) для нескольких потребителей, и не забывайте превращая Epsilon GC для JVM;)