Повторное использование объектов Java

Должны ли объекты Java повторно использоваться так часто, как можно их повторно использовать? Или мы должны повторно использовать его только тогда, когда они "тяжеловесы", т.е. Связаны ли с ним ресурсы ОС?

Все старые статьи в Интернете говорят о возможности повторного использования объектов и пула объектов как можно больше, но я прочитал последние статьи, в которых new Object() теперь сильно оптимизирован (10 инструкций), а повторное использование объектов не так важно, как Раньше это было.

Какова нынешняя лучшая практика и как вы это делаете?

Ответ 1

Я разрешаю сборщику мусора сделать это для меня, единственный раз, когда я ударил ограничение кучи со свежераспределенными объектами, после запуска багги рекурсивного алгоритма на пару секунд, который сгенерировал 3 * 27 * 27.. новые объекты как можно быстрее.

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

Ответ 2

Если вы используете их очень интенсивно , а конструкция стоит дорого, вы должны попытаться повторно использовать их столько, сколько сможете.

Если ваши объекты очень маленькие и дешевые для создания (например, Object), вы должны создать новые.

Например, база данных соединений объединена, потому что затраты на создание нового выше, чем при создании.. mmhh new Integer, например.

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

Edit:

Кроме того, этот элемент из Эффективной Java: Способствовать неизменности стоит прочитать и может применяться к вашей ситуации.

Ответ 3

Пусть сборщик мусора выполняет свою работу, его можно считать лучше, чем ваш код.

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

Правило 1 оптимизации: не делайте этого.
Правило 2 (только для экспертов): не делайте этого еще.

Ответ 4

Создание объекта дешево, да, но иногда это не так дешево.

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

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

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

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

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

Однако, что бы вы ни делали: убедитесь, что вы сначала проверяете свои горячие точки профилировщиком. Преждевременная оптимизация - это корень самого злого.

Ответ 5

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

Если он просто создает новый String(), забудьте о повторном использовании, вы ничего не получите от него. Читаемость кода имеет более высокое предпочтение.

Ответ 6

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

Повторное использование объектов звучит как катастрофа, ожидающая случившегося кстати:

SomeClass someObject = new SomeClass();

someObject.doSomething();
someObject.changeState();
someObject.changeOtherState();
someObject.sendSignal();
// stuff

//re-use 
someObject.reset(); // urgh, had to put this in to support reuse
someObject.doSomethingElse(); // oh oh, this is wrong after calling changeOtherState, regardless of reset
someObject.changeState(); // crap, now this is wrong but it not obvious yet
someObject.doImportantStuff(); // what going on?

Ответ 7

Создание объекта, конечно, быстрее, чем раньше. Более новые поколения GC в JDKs 5 и выше также являются улучшениями.

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

Повторное использование повышает безопасность потоков. Вы должны тщательно подумать, чтобы обеспечить безопасное повторное использование объектов.

Если бы я решил, что повторное использование объекта важно, я бы сделал это с такими продуктами, как Terracotta, Tangersol, GridGain и т.д., и убедитесь, что у моего сервера есть доступ к памяти.

Ответ 8

Вторые приведенные выше комментарии.

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

Просто попробуйте написать чистый и простой код и поразите то, что может сделать Hotspot.

Почему бы не использовать VisualVM или профилировщик, чтобы взглянуть на ваш код?