Пулинг объектов

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

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

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

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

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

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

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

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

Не делать.

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

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

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

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

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

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

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

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

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