Предотвращает ли этот метод сбор мусора в Java?

Question

Кольт МакАнлис сделал удивительно интересное видео о предотвращении замедления работы приложений сборщиком мусора JavaScript

Суть его такова:

1. Когдаприложение загружает, создает пул неиспользуемых объектов / классов, которые могут понадобиться вашему приложению в какой-то момент в будущем.
2. Когда вы хотите создать новый объектвместо этого найдите в пуле объект соответствующего типа, который не используется, возьмите его и установите его свойства.
3. Вместо этого используйте этот объект.
4. Когда вы закончите с ним,пометьте его как «неиспользуемый», чтобы его могли использовать будущие методы.

Мой вопрос заключается в том, будет ли эта методология работать также с Java-сборщиком мусора, или ее будет сложнее обойти, и она просто закончит сканированиевся ваша куча или что-то в этом роде.

Это в основном теоретическая вещь / любопытство.У меня нет приложений в разработке, которые зависят от обхода сборки мусора.

Answer 1

Это будет "работать" в некотором смысле.Но это не рекомендуется, потому что есть некоторые существенные проблемы.

1. Если вы реализуете это неправильно, это утечка памяти.Проблема в том, что «пул» должен хранить ссылку на все свои объекты.Это предотвращает сбор мусора.Но если приложению не удается всегда помечать объекты как «неиспользуемые», когда это делается с ними (например, ошибка), эти объекты остаются «используемыми» навсегда.

   (Если вы попытаетесь смягчить это с помощью чего-либоподобно Reference объектам, вы в конечном итоге используете больше места и увеличиваете нагрузку на ГХ.)

2. Когда ГХ работает, он должен пройти все объекты вбассейн, а также все их зависимые объекты.Это больше работы, чем если бы объектам было позволено умереть.(Молодые недоступные объекты вообще не нужно сканировать.)

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

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

Существуют и другие причины использования пулов объектов:

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

Примеры включают в себя пулы потоков, пулы соединений с базой данных и пулы соединений HTTP (под капотом в типичных клиентских библиотеках HTTP).Это определенно полезно в соответствующих обстоятельствах.