Объединение объектов

Ответ 1

Если объект не дорог для создания, я бы не стал беспокоиться.

Преимущества:

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

Downsides:

• Более сложный код
• Общий ресурс = блокировка; потенциальное узкое место
• Нарушает ожидания GC для жизни объектов (большинство объектов будут неработающими)

У вас есть реальная проблема, которую вы пытаетесь решить, или это умозрительное? Я бы не подумал о том, чтобы делать что-то подобное, если у вас нет тестов/прогонов, показывающих, что есть проблема.

Ответ 2

Первый закон оптимизации: не делайте этого. Второй закон: не делайте этого, если вы на самом деле не измерили и не знаете, что вам нужно оптимизировать и где.

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

Два преимущества, о которых вы говорите, на самом деле не так: распределение памяти в Java бесплатное (стоимость была близка к 10 командам процессора, что ничего не значит). Таким образом, сокращение создания объектов экономит ваше время, затрачиваемое на конструктор. Это может быть усиление с действительно тяжелыми объектами, которые могут быть повторно использованы (соединения с базой данных, потоки) без изменения: вы повторно используете одно и то же соединение, тот же поток.

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

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

Ответ 3

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

Неизменность не всегда желательна, но чаще всего вы обнаружите, что вещи могут быть неизменными. Сделать их не неизменными, чтобы вы могли повторно использовать их в пуле, возможно, это не отличная идея.

Итак, если вы точно не знаете, что это проблема, не беспокойтесь. Сделайте код понятным и понятным, и вероятность того, что он будет достаточно быстрым. Если это не так, то тот факт, что код понятен и легко следовать, облегчит его ускорение (в общем).

Ответ 4

Не.

Это размышление в 2001 году. Единственный объект "пул", который все еще стоит ничего в днях, - это синглтон. Я использую singleletons только для уменьшения создания объекта для профилирования (поэтому я могу более четко видеть, что влияет на код).

Что-то еще вы просто фрагментируете память без каких-либо хороших целей.

Идем дальше и запускаем профиль при создании 1 000 000 объектов. Это незначительно.

Старая статья здесь.

Ответ 5

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

Пример реальной жизни: мне нужно было повторно извлекать n наивысших ранжированных элементов (целых чисел) из процесса, генерирующего большое количество пар целых/ранговых. Я использовал "парный" объект (целое число и значение ранжирования с плавающей точкой) в очереди с ограниченным приоритетом. Повторное использование пар против опорожнения очереди, выброса пар и их воссоздания дало 20% -ное улучшение производительности... главным образом в сборе GC, потому что пары никогда не нуждались в перераспределении на протяжении всей жизни JVM.

Ответ 6

Пулы объектов обычно являются лишь хорошей идеей для дорогостоящих объектов, таких как соединения с базой данных. До Java 1.4.2 пулы объектов могли бы повысить производительность, но с пулов объектов Java 5.0, где более вероятно, чтобы снизить производительность, чем помощь, и часто пулы объектов были удалены для улучшения производительности (и простоты).

Ответ 7

Я согласен с точками Jon Skeet, если у вас нет конкретной причины создавать пул объектов, я бы не стал беспокоиться.

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