Короткая версия: Да, вы можете.
Длинная версия:
Как Java / JVM управляет памятью
Для большинства приложений JVM по умолчанию в порядке.Похоже, что JVM ожидает, что приложения будут работать только в течение ограниченного периода времени.Следовательно, он не освобождает память самостоятельно.
Чтобы помочь JVM решить, как и когда выполнять сборку мусора, необходимо указать следующие параметры:
-Xms Указывает минимальный размер кучи –Xmx Указывает максимальный размер кучи
Для серверных приложений добавьте: -server
Этого мне недостаточно,Я хочу больше контроля!
Если вышеупомянутых параметров недостаточно, вы можете повлиять на поведение JVM в отношении сборки мусора.
Сначала вы можете использовать System.gc(), чтобы сообщить виртуальной машинекогда вы считаете, что сбор мусора имеет смысл.Во-вторых, вы можете указать, какой из сборщиков мусора должна использовать JVM:
Различные виды сборщиков мусора:
Serial GC
Параметр командной строки: -XX:+UseSerialGC
Останавливает ваше приложение и выполняет GC.
Параллельный GC
КомандаСтроковый параметр: -XX:+UseParallelGC -XX:ParallelGCThreads=value
Запускает вспомогательные коллекции параллельно с вашим приложением.Сокращает время, необходимое для основных коллекций , но использует другой поток.
Параллельное сжатие GC
Параметр командной строки: -XX:+UseParallelOldGC
Запускает основных коллекций параллельно с вашим приложением.Использует больше ресурсов ЦП, уменьшает использование памяти.
CMS GC
Параметр командной строки: -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=value -XX:+UseCMSInitiatingOccupancyOnly
Выполняет меньшеколлекции, и чаще, чем Serial GC , что ограничивает перерывы / остановки приложения.
G1
Параметр командной строки: -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
Экспериментальный (по крайней мере, в Java 1.6): Пытается убедиться, что приложение никогда не останавливается в течение более 1 с.
Пример
Использование памяти веб-приложением Play Framework без каких-либо оптимизаций: 
Как видите, оно использует довольно много места в куче, и используемое пространство регулярно освобождается.
В этом случае оптимизации только с параметрами были неэффективными.Было несколько запланированных заданий, которые занимали довольно много памяти.В этом случае наилучшая производительность была достигнута при использовании CMS GC в сочетании с System.gc() после операций с интенсивным использованием памяти.В результате использование памяти WebApp было уменьшено с 1,8 ГБ до 400-500 МБ.
Здесь вы можете увидеть еще один скриншот из VisualVM, который показывает, как память освобождается JVM и фактически возвращается кОС:
Примечание. Я использовал кнопку «Perform GC» VisualVM для выполнения GC, а не System.gc() в моем коде, как запланированные задачи, которые потребляютпамять запускается только в определенное время, и ее несколько сложнее захватить с помощью VisualVM.
Дальнейшее чтение