Objectpool против неизменных объектов

Допустим, вы работаете с простым классом, и создание объекта не является тяжелым:

class Simple {
  public final int data1;
  public final float data2;
  ...
}

Вы должны постоянно помещать простые объекты в очередь:

queue.add(new Simple(123,123f,...));

Быстрее ли работать с Object-Pool и изменять модифицируемый класс Simple-Class? Надеюсь нет.

Источник

2 ответа

Решение

Как правило, нет, это не быстрее. Если вы сконфигурируете JVM для использования "пропускной способности" GC, вы получите лучшую производительность, не пытаясь утилизировать объекты. Стоит рассмотреть пулы объектов, только если вы "ограничены в памяти" или если GC-паузы проблематичны. (Амортизированная стоимость сбора мусора объекта стремится к нулю, поскольку увеличивается доля мусора по сравнению с мусором, особенно если объекты "умирают молодыми", согласно гипотезе о поколениях.)

По факту:

  • если приложение является многопоточным, пул объектов вполне может быть узким местом параллелизма, и

  • Мутация "эффективно неизменяемых" объектов может потребовать дополнительных издержек и / или дополнительной синхронизации.

Если скорость создания объекта составляет "около 20 объектов в секунду", то использование пула объектов вряд ли существенно повлияет на производительность, даже если это приведет к улучшению (в чем я сомневаюсь).

Делай математику.

  • Если размер объекта для Simple равно N байтов, и вы выделяете M в секунду, вы можете оценить количество выделенных байтов в секунду.

  • Если ваш "молодой пробел" равен Y Мбайт, потребуется три секунды, чтобы активировать GC на основе этой скорости выделения.

  • Если для "молодого пространства" GC требуется в среднем G мс для пространства размера Y, вы можете оценить верхнюю границу времени, которое можно гипотетически сохранить... при условии, что у пула объектов были нулевые связанные накладные расходы.

  • Фактическая экономия будет меньше, поскольку предположение "нулевых накладных расходов" нереально.

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

Источник

Объектный пул имеет смысл, если вы действительно создаете какие-то тяжелые объекты или у вас есть другие требования, которые определяют необходимость использования пула объектов. В противном случае я бы просто занялся созданием новых и полагался на JVM, чтобы избавиться от всего, что не нужно (просто не забудьте сначала удалить / переназначить ссылку на ненужные объекты)

Источник
Другие вопросы по тегам