2015-08-19 2 views
1

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

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

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

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

Is быстрее работать с пулом объектов и изменять класс, модифицируемый классом Simple-Class? Надеюсь нет.

+0

Есть ли у вас какое-то приблизительное представление о том, сколько из этих объектов потребуется во время выполнения? – Lucas

+0

Как часто/сколько объектов вы создаете? Как правило, создание объектов на Java не дорого. – Alex

+0

Около 20 объектов в секунду. – doev

ответ

5

Вообще-то нет, t быстрее. Если вы настроите JVM на использование GC «пропускной способности», вы получите лучшую производительность, не пытаясь перерабатывать объекты. Стоит только рассматривать пулы объектов, если вы либо ограничены памятью, либо если GC-паузы являются проблематичными. (Амортизированная стоимость мусора сбор объекта стремится к нулю, как доля мусора в не-мусоре увеличивается, особенно если объекты «умирают молодыми», согласно гипотезе поколений.)

В самом деле:

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

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


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

Сделайте математику.

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

  • Если ваше «молодое пространство» составляет Y Мбайт, для запуска GC на основе этой скорости распределения потребуется T секунд.

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

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

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

1

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

+0

Это моя мысль. Создание этих простых объектов, которые хранят данные только и не инициализируют что-то в конструкторе, не могут быть тяжелой задачей. – doev

+0

, вы должны инициализировать конечных членов в конструкторе, хотя – Lucas

Смежные вопросы