Прежде всего, прежде чем делать это, вы должны выполнить обширное профилирование, чтобы определить, действительно ли у вас действительно есть проблема с производительностью, вызванная нагрузкой при сборе. Сборщик мусора хорошо настроен и работает довольно хорошо большую часть времени; ситуации, когда вам нужно объединить объекты для повышения производительности, редки.
Я на самом деле , я в этом сценарии; В ходе всестороннего тестирования мы определили, что есть определенные объекты, которые мы используем постоянно на временной основе (по сути, «строители» других объектов), и что стоимость давления сбора, вызванного перераспределением их, часто измерима и высока.
Что мы делаем, так это то, что у нас есть класс пула, который поддерживает массив «пустых» объектов. Когда вам нужен новый объект, пул проверяет массив и возвращает объект, который находится в массиве, если он у нас есть, обнуляя запись массива. Если у нас его нет, он создает новый объект. Когда временный пользователь завершает работу с объектом, он передает его обратно в пул, который «очищает» его и вставляет обратно в массив. (Увеличение массива при необходимости.)
Если пользователь забывает поместить объект обратно в пул или не может этого сделать, потому что перед вызовом «назад в пул» было сгенерировано исключение, кого это волнует? Все, что мы сделали в этом случае, возможно, немного де-оптимизировали распределение в будущем. Плата за то, что вам нужно помнить, чтобы положить объект обратно в пул, когда вы закончите с ним.
Нет никакого способа "зацепить" сборщик мусора, чтобы автоматически помещать вещи в пул, о которых я знаю.