Diagnosing High CPU During Project Indexing in IntelliJ IDEA

IntelliJ IDEA indexes every file it considers part of the project so that search, navigation, and refactoring stay fast. When that indexing runs long and pins a CPU core, the cause is almost always one of five things: too many files in scope, missing directory exclusions, antivirus interference, a misbehaving plugin, or a JVM heap that is too small. The fix depends on which one you have, so diagnose before changing settings.

Recognizing the condition

Normal indexing happens after opening a project, switching branches, or a large build. It shows a progress bar in the status bar and finishes in seconds to a few minutes, after which CPU drops to idle. The problem state looks different: the "Indexing" or "Scanning files" indicator runs for tens of minutes, repeats after every minor change, or the fans spin up every time you touch the project. On large projects some indexing cost is expected; the signal is indexing that never settles or re-triggers constantly.

Likely causes and how to tell them apart

Ordered checks

1. Watch what is being indexed. Click the indexing progress indicator in the status bar. It shows the file currently being scanned. If you see paths under target/, build/, node_modules/, or .git/, exclusions are the problem.
2. Check the log. Open Help → Show Log in Explorer/Finder and inspect idea.log. Repeated "Scanning files" or "Indexing" entries that loop over the same directories confirm scope problems; OutOfMemoryError or long GC messages point to heap.
3. Correlate with antivirus. Open your OS process monitor while indexing runs. If a security product's process consumes CPU in lockstep with the IDE, that is your contention.
4. Isolate plugins. If the issue began recently, disable plugins installed or updated around that time (Settings → Plugins), restart, and re-test.
5. Check memory pressure. Enable the memory indicator (Settings → Appearance & Behavior → Appearance → "Show memory indicator"). If the used value sits near the cap during indexing, the heap is too small.

Fixes matched to findings

Exclude generated and dependency directories

Right-click the directory in the Project tool window → Mark Directory as → Excluded. For Maven/Gradle projects, build output directories are usually excluded automatically when the project is imported as a Maven/Gradle project rather than opened as a plain folder — if target/ is indexed, re-import the project via the build tool. Typical candidates for exclusion: target/, build/, out/, dist/, node_modules/, .git/ (normally excluded by default).

Risk: excluded directories disappear from search, navigation, and refactoring. Only exclude paths that contain build artifacts or vendored dependencies, never hand-written source. After excluding, run Ctrl+Click navigation on a few symbols and a global search to confirm nothing legitimate went missing.

Add antivirus exclusions

Ask your security team (or configure, if you manage it) to exclude the IDE's system directory and your project/build directories from real-time scanning. The IDE system directory location is shown under Help → Edit Custom Properties context — by default it lives under the JetBrains folder in your user profile (e.g., ~/.cache/JetBrains/ on Linux, %LOCALAPPDATA%\\JetBrains\\ on Windows). This is a machine-level change, so confirm it complies with your organization's policy.

Remove or update the offending plugin

Update all plugins first (Settings → Plugins → check for updates), since many indexing issues are fixed upstream. If a specific plugin is implicated and no update exists, disable it and report the issue to the plugin vendor with your IDE build number (Help → About).

Raise the JVM heap

Use Help → Change Memory Settings (this edits the IDE's VM options and requires a restart). For large projects, raising the max heap from the default to 2048–4096 MB is common. Do not exceed roughly half your physical RAM, and never more than the machine can spare — oversizing causes OS swapping, which is worse than GC pauses. After restarting, watch the memory indicator during indexing: usage should peak and fall back rather than pinning at the cap.

Verifying the fix

• Restart the IDE and trigger a fresh index (File → Invalidate Caches → Invalidate and Restart if needed). Indexing should complete in its usual time and CPU should return to idle afterward.
• Check idea.log: indexing completion messages should appear once, without repeating "Scanning files" loops.
• Confirm functionality: global search (Ctrl+Shift+F), go-to-declaration, and a rename refactoring should still work across your real source tree.

When to escalate

If indexing stays pathological after exclusions, antivirus tuning, plugin isolation, and a heap increase, capture a CPU snapshot (Help → Diagnostic Tools → Start CPU Usage Profiling, reproduce the problem, stop and save), bundle it with idea.log and your build number, and file an issue in JetBrains YouTrack. Also escalate internally if the antivirus exclusion requires security-team approval or if the project structure itself (e.g., a monorepo with millions of files) may need splitting into smaller IDE modules.