Я настоятельно рекомендую против этого: Java, пытающаяся GC вместо того, чтобы немедленно генерировать исключение OutOfMemoryException, имеет гораздо больший смысл - не заставляйте ваше приложение отказываться, пока не исчерпаны все альтернативы.
Если вашему приложению не хватает памяти, вы должны увеличить максимальный размер кучи или посмотреть на его производительность с точки зрения выделения памяти и посмотреть, можно ли его оптимизировать.
Вот некоторые вещи, на которые стоит обратить внимание:
- Используйте слабые ссылки в тех местах, где ваши объекты не понадобятся, если на них нет ссылок нигде.
- Не выделяйте объекты большего размера, чем вам нужно (т. Е. Храните огромный массив из 100 объектов, когда вам нужен только доступ к трем из них в течение жизненного цикла массива), и не используйте длинный тип данных, когда вам нужно только сохранить восемь значений.
- Не держите ссылки на объекты дольше, чем нужно!
Редактировать: Я думаю, вы неправильно поняли мою точку зрения. Если вы случайно оставите живую ссылку на объект, который больше не нужно использовать, он, очевидно, все равно не будет собирать мусор. Это не имеет ничего общего с обнулением, просто incase - типичным примером этого является использование большого объекта для определенной цели, но когда он выходит из области видимости, это не GC, потому что живая ссылка случайно была оставлена в другом месте, где-то, что вы не знаю о причинении утечки. Типичным примером этого может служить поиск в хеш-таблице, который может быть решен с помощью слабых ссылок, так как он будет иметь право на сборщик мусора, когда он только слабо доступен.
Несмотря на это, это просто общие идеи о том, как улучшить производительность с выделением памяти. Суть, которую я пытаюсь сделать, заключается в том, что вопрос о том, как быстрее вызвать ошибку OutOfMemory, а не о том, чтобы Java GC попытался найти лучший способ освободить место в куче, не является хорошей идеей для IMO. Вместо этого оптимизируйте свое приложение.