IntelliJ IDEA на ноутбуке: настройка heap, быстрая индексация и Gradle без тормозов

Прямой ответ

IntelliJ IDEA — JVM-приложение с двумя отдельными «аппетитами»: heap самой IDE (индекс и интеллектуальные функции) и Gradle/Kotlin-демоны (сборка). На ноутбуке их нужно ограничивать раздельно, иначе два процесса по 2–3 ГБ незаметно выедают 16 ГБ. Рабочая формула для 16 ГБ: IDE -Xmx2048m, Gradle-демон -Xmx2048m, Kotlin-демон -Xmx1g, и обязательное исключение build-каталогов из индексации. На 32 ГБ цифры можно удвоить для больших монорепозиториев.

Heap IDE: где настраивать и сколько ставить

Help → Change Memory Settings — быстрый способ; полный контроль даёт файл idea64.exe.vmoptions (Help → Edit Custom VM Options):

-Xms512m
-Xmx2048m
-XX:ReservedCodeCacheSize=512m

Ориентиры по размеру проекта: до ~100 тыс. строк — 2 ГБ; крупные много-модульные проекты — 3–4 ГБ; монорепозитории 500 тыс.+ файлов — 4–6 ГБ и параллельно включённый Shared Indexes (скачиваемые индексы JDK/библиотек вместо локального построения). Ставить -Xmx «побольше про запас» вредно: раздутый heap означает длинные паузы сборщика мусора и общий рост потребления.

Диагностика нехватки heap: включите индикатор памяти (Settings → Appearance & Behavior → Appearance → Show memory indicator); частые клики «GC» или запись LowMemoryWatcher в idea.log — сигнал увеличить -Xmx или почистить проект от лишнего.

Индексация: главный потребитель времени и памяти

IDE индексирует всё, что не исключено, поэтому:

1. Исключайте сгенерированное: правый клик на build/, out/, generated/ → Mark Directory as → Excluded. В Gradle-проектах IDEA обычно исключает build сама — проверьте, что это случилось.
2. Не открывайте лишнего: открытый как модуль соседний мегапроект индексируется вместе с вашим. Один проект — одно окно.
3. Shared Indexes (Settings → Shared Indexes): индексы JDK и Maven-библиотек скачиваются готовыми — первая индексация большого проекта ускоряется кратно.
4. Инвалидация — не профилактика: Invalidate Caches помогает при поломке индекса, но его плановое использование «на всякий случай» лишь запускает полную переиндексацию заново.

Gradle на ноутбуке: демоны, кэши, параллельность

Gradle держит постоянно живущий демон-процесс — это ускорение повторных сборок ценой 1–2 ГБ памяти. Настройки в gradle.properties проекта:

org.gradle.jvmargs=-Xmx2048m -XX:MaxMetaspaceSize=512m
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=true

• parallel включает параллельную сборку модулей (эффективно при 6+ ядрах CPU ноутбука);
• caching переиспользует результаты задач — повторные сборки быстрее в разы;
• configuration-cache убирает фазу конфигурирования из повторных запусков;
• Kotlin-демон ограничивается отдельно: kotlin.daemon.jvmargs=-Xmx1g.

Кэш сборки живёт в ~/.gradle/caches и разрастается до десятков гигабайт: раз в квартал удаляйте старые версии (caches/<version> каталоги) — сборка сама скачает нужное. Останавливайте забытые демоны: ./gradlew --stop (процесс держит память, даже когда вы не собираете проект).

Подвисания: быстрый алгоритм локализации

1. Что замерло — IDE или сборка? Индикатор прогресса внизу показывает задачу; jps в терминале покажет активные Java-процессы.
2. IDE при наборе кода — обычно индексация/анализ: посмотрите CPU в Activity Monitor/Диспетчере, дождитесь окончания фонового индекса или исключите тяжёлый каталог.
3. Сборка деградировала — проверьте, не запускаются ли несколько Gradle-демонов (разные версии Gradle в проектах = несколько демонов); ./gradlew --stop во всех проектах и единая версия через Gradle Wrapper.
4. Память на пределе — суммарный счёт: IDE heap + демоны + запущенное приложение + Docker; общий подход к бюджету ОЗУ описан в статье про IDE и память 8/16/32 ГБ.
5. Монорепозиторий — дополнительно включите sparse-подход на стороне Git, чтобы IDE не видела чужие модули: механика в статье про Git-монорепозитории.

Полный бюджет памяти JVM-проекта на 16 ГБ ноутбуке

Сложим все процессы типичного дня Java/Kotlin-разработчика — так становится видно, почему «IDEA съела 16 ГБ» почти всегда история про сумму, а не про IDE:

Выводы практические: на 16 ГБ одновременная сборка + запущенное приложение + тяжёлый браузер — уже граница; урезайте демонов, а не heap IDE (IDE с урезанным heap деградирует заметнее всего). На 32 ГБ та же картина даёт 50% запаса. Если апгрейд не планируется — держите правило «одна тяжёлая операция за раз»: сначала сборка/тесты, потом запуск приложения.

Отдельный приём для медленных первых сборок: включите в IDEA делегирование сборки Gradle только для финальных прогонов, а повседневные итерации собирайте средствами IDE — разница на холодных сборках достигает 2–3 раз за счёт инкрементальной компиляции IDEA.

FAQ

Стоит ли переходить на Community Edition ради скорости? Нет: разница в потреблении минимальна, она определяется размером проекта, а не редакцией. Community просто не содержит веб-фреймворков и Spring-поддержки.

Почему после обновления IDEA первая сборка/индексация долгая? Меняются форматы индексов и кэшей — разовая полная перестройка нормальна. Дальше включается Shared Indexes и кэши Gradle.

Как ускорить запуск Spring-приложения из IDE? Собирайте через IDEA (а не Gradle-делегированием) для итераций: Settings → Build Tools → Gradle → Build and run using: IntelliJ IDEA. Для финальных сборок возвращайте Gradle.

Помогает ли «больше ОЗУ» без настроек? Частично: система перестанет своппить, но раздутые демоны и heap съедят и 32 ГБ. Сначала лимиты и исключения — потом апгрейд.

Что делать, если IDEA «индексирует вечно» после каждого перезапуска? Проверьте, не лежит ли кэш индексов на медленном/сетевом диске (Settings → System Settings → caches), не антивирус ли блокирует каталог кэшей, и не включён ли «безопасный режим» корпоративного ПО на папке. На Windows добавление каталога кэшей IDEA в исключения Defender часто сокращает индексацию в разы.

Отдельная статья экономии — плагины: каждый активный плагин добавляет классы в память и точки расширения в каждый проход анализа. Отключите неиспользуемые (Settings → Plugins → Installed): поддержка языков и фреймворков, которых нет в проекте, — мёртвый груз. В крупных командах полезно держать единый минимальный набор плагинов: и быстрее, и меньше расхождений в поведении IDE.

Источники: документация JetBrains (heap, performance troubleshooting), документация Gradle (build environment) — ссылки в шапке.