"java.lang.OutOfMemoryError: Java heap space" - If you've seen this error message, you know the sinking feeling that follows. One minute your application is running fine, the next it's completely dead, taking your system down with it. Whether you encounter this error once a year or once a week, it's always a problem that demands immediate attention.
This error hits harder than most because it doesn't give warnings before striking. There's no gradual slowdown or graceful degradation - just a sudden crash that leaves users disconnected and services offline. Your application stops working, period. That's why knowing what causes these errors and how to prevent them isn't just useful knowledge; it's essential for anyone running Java applications in production.
What Causes Java Heap Space Errors?
When Java tells you it's out of heap space, it means your application tried to use more memory than the JVM could provide. But why does this happen? Let's look at the real culprits behind these crashes.
Memory Leaks: The Sneaky Problem
The most common cause is code that holds onto objects it no longer needs. These leaks start small but grow over time, eventually eating up all available memory. Here's what typically goes wrong:
- Collections that keep growing because nothing removes old entries
- Caches that never expire their stored data
- Event listeners that hang around after their job is done
- Open database connections that never get closed
- Static variables holding onto large objects
Here's a classic example of trouble:
public class UserCache {
private static Map<String, User> userCache = new HashMap<>();
public void addUser(User user) {
userCache.put(user.getId(), user); // Old users never leave
}
}
Processing More Data Than Memory Can Handle
Sometimes your code works perfectly - it's just dealing with too much data for the available memory:
- Reading gigabyte-sized files into memory all at once
- Loading entire database tables when you need only a subset
- Keeping large API responses in memory
- Converting massive data files without streaming
Infinite Loops and Runaway Recursion
These problems create objects endlessly until memory runs out:
public void processData(List<Data> data) {
if (data.isEmpty()) return;
processData(data.subList(1, data.size())); // Creates new list each time
}
OutOfMemoryError Symptoms and Signs
Before your application crashes completely, it usually shows warning signs. Recognizing these symptoms can save you from emergency midnight debugging sessions:
Your Application Starts Acting Strange
- Response times get sluggish without obvious reasons
- CPU usage spikes as garbage collection works overtime
- The application freezes briefly during garbage collection pauses
- Overall throughput drops despite consistent load
Log Messages Tell the Story
When the crash happens, you'll see something like this:
at java.util.Arrays.copyOf (Arrays.java:3210)
at java.util.Arrays.copyOf (Arrays.java:3181)
at java.util.ArrayList.grow (ArrayList.java:261)
System Metrics Show the Danger
- Garbage collection logs reveal longer and longer pause times
- Heap usage stays consistently above 80%
- The old generation space grows but never shrinks
- Full garbage collections happen often but recover little memory
JVM Memory Structure Explained
To fix heap space problems, you need to understand how the JVM manages memory:
The Heap is Divided into Regions
Young Generation: Where new objects start their life
- Eden Space: Initial allocation area for new objects
- Survivor Spaces: Temporary storage for objects surviving garbage collection
Old Generation: Home for long-lived objects
Metaspace: Stores class metadata (replaced PermGen in Java 8+)
Controlling Memory with JVM Options
-Xms2g # Start with 2GB heap
-Xmx4g # Allow up to 4GB heap
-XX:NewSize=1g # Young generation starts at 1GB
-XX:MaxNewSize=1g # Young generation maximum 1GB
Diagnostic Flags You Need
-Xlog:gc*:gc.log:time ,uptime,level,tags
# Save heap dumps when memory runs out
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/path/to/dumps
How to Detect Memory Leaks in Java Applications
Finding memory leaks is like detective work - you need the right tools and a systematic approach. Beyond traditional debugging tools, setting up effective monitoring is crucial. Solutions like Odown can help you track memory metrics over time and alert you before minor issues become major outages.
Tools for Tracking Down Leaks
The Java ecosystem provides several powerful diagnostic tools:
jmap: Takes snapshots of your heap
jcmd: Monitors heap in real-time
jcmd <pid> VM.native_memory summary
- VisualVM: Visual heap analysis with live monitoring
- Eclipse Memory Analyzer (MAT): Deep analysis of heap dumps
Spotting Leak Patterns
Memory leaks often follow certain patterns. Here's a smarter approach to the earlier cache problem:
public class ImprovedUserCache {
private final Map<String, User> cache =
new LinkedHashMap<String, User>(1000, 0.75f, true) {
protected boolean removeEldestEntry (Map.Entry<String, User> eldest) {
return size() > 1000;
}
};
}
}
Signs You're Dealing with a Leak
- Object counts that keep growing without dropping
- Heap usage that climbs steadily despite garbage collection
- Particular object types taking up increasing memory
- Old generation space that never has much free room
Monitoring Java Heap Usage with Odown
You can't fix problems you don't know about. That's why proactive heap monitoring is essential. Odown's monitoring capabilities let you track memory usage patterns and catch problems early. You can set up custom health checks that watch your application's memory consumption and alert your team before things get critical.
While monitoring memory metrics, you should also track HTTP status codes that might indicate memory-related issues. Your application might return 503 Service Unavailable errors during memory pressure. Learn how to monitor and alert on HTTP status codes to catch these problems early.Retry
Exposing Memory Metrics
Create endpoints that Odown can monitor for memory health:
@RestController
public class HealthController {
@GetMapping("/health/memory")
public Map<String, Object> checkMemory() {
Runtime runtime = Runtime.getRuntime();
long maxMemory = runtime.maxMemory();
long totalMemory = runtime.totalMemory();
long freeMemory = runtime.freeMemory();
long usedMemory = totalMemory - freeMemory;
Map<String, Object> status = new HashMap<>();
status.put("usedMB", usedMemory / (1024 * 1024));
status.put("freeMB", freeMemory / (1024 * 1024));
status.put("totalMB", totalMemory / (1024 * 1024));
status.put("maxMB", maxMemory / (1024 * 1024));
status.put("usagePercent", ((double) usedMemory / maxMemory) * 100);
return status;
}
}
Setting Up Alerts for Memory Usage Spikes
The key to effective monitoring is knowing when to worry. Configure intelligent alerts that give you early warnings without creating alert fatigue:
Smart Alert Strategy
- Check heap usage every 5 minutes during business hours
- Send warnings when usage exceeds 80% for 3 consecutive checks
- Escalate to critical alerts at 90% usage
- Page the on-call team if usage stays high for more than 15 minutes
Monitor Configuration
"name": "Java Application Memory Check",
"url": "https://your-app.com/health/memory",
"interval": "5 minutes",
"validation": {
"jsonPath": "$.usagePercent",
"operator": "lessThan",
"value": 80
},
"alerts": {
"warning": {
"consecutiveFailures": 3,
"notify": ["team-slack", "dev-email"]
},
"critical": {
"threshold": {
"usagePercent": 90
},
"notify": ["sms", "pagerduty"]
}
}
}
When Alerts Fire
Having alerts means nothing without a response plan:
- Automatically capture heap dumps for analysis
- Trigger any emergency cleanup routines you've built
- Consider scaling out to distribute the memory load
- Get your development team involved for deeper investigation
Diagnostic Commands Reference
Keep these commands handy for troubleshooting heap issues:
Quick Memory Checks
jmap -heap <pid>
# Find which processes use the most memory
ps aux --sort=-%mem | head
# Watch garbage collection in action
jstat -gc <pid> 1000
# Check all JVM memory settings
java -XX:+PrintFlagsFinal -version | grep -i heap
Emergency Troubleshooting
jcmd <pid> GC.run
# Get thread information to check for deadlocks
jstack <pid> > threads.log
# Monitor memory usage in real-time
jconsole <pid>
Prevention Best Practices
Preventing heap problems is easier than fixing them. Here are coding patterns that save memory and headaches:
Handle Large Data Smartly
List<String> lines = Files.readAllLines(path);
// Better: Process line by line
try (Stream<String> lines = Files.lines(path)) {
lines.filter(line -> line.contains("error"))
.forEach(System.out::println);
}
Close Resources Properly
try (BufferedReader reader = Files .newBufferedReader(path)) {
return reader.lines()
.collect (Collectors.toList());
} catch (IOException e) {
logger.error("File reading failed", e);
return Collections.emptyList();
}
Cache with Care
Map<String, WeakReference<ExpensiveObject>> cache =
new ConcurrentHashMap<>();
public ExpensiveObject getFromCache(String key) {
WeakReference<ExpensiveObject> ref = cache.get(key);
ExpensiveObject object = null;
if (ref != null) {
object = ref.get();
}
if (object == null) {
object = createExpensiveObject(key);
cache.put(key, new WeakReference<>(object));
}
return object;
}
Performance Tuning Guidelines
Setting the Right Heap Size
Finding the sweet spot for heap size requires understanding your application:
- Start with maximum heap at 60-80% of available container memory
- Set young generation to 1/3 or 1/2 of total heap
- Always leave room for memory spikes during peak usage
Choosing Your Garbage Collector
Different applications need different GC approaches:
G1GC: Good balance for most applications (Java 9+ default)
ZGC: When you need the lowest possible latency
Shenandoah: Another low-latency option
JVM Parameter Cheat Sheet
Production Basics
-Xms4g -Xmx4g # Fixed heap size avoids resizing overhead
-XX:+UseG1GC # G1 garbage collector
-XX:MaxGCPauseMillis=200 # Target GC pause time
-XX:+UseStringDeduplication # Save memory on duplicate strings
Debugging and Monitoring
-Xlog:gc*=debug:file=gc. log:time,uptime:filecount=10, filesize=1m
# Save heap dumps when out of memory occurs
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath= /var/log/heapdumps
# Enable JMX for monitoring tools
-Dcom.sun.management.jmxremote
-Dcom.sun.management. jmxremote.port=9999
-Dcom.sun.management. jmxremote.authenticate=false
-Dcom.sun.management. jmxremote.ssl=false
Development Settings
-Xms512m -Xmx2g
# Extra checking for development
-XX:+CheckJNICalls
-XX:+EagerTest
-XX:+Verbose
When Things Go Wrong: Your Action Plan
First Response
- Capture that heap dump immediately
- Check recent deployments for new memory issues
- Scale horizontally if your architecture allows
Investigation
- Analyze heap dumps for suspicious objects
- Review GC logs for unusual patterns
- Look for recent code changes affecting memory
Prevention Going Forward
- Set up continuous heap monitoring
- Add memory tests to your test suite
- Schedule regular heap analysis sessions
Ongoing Vigilance
- Monitor memory trends, not just current usage
- Configure alerts that give early warnings
- Keep historical data for pattern recognition
Ready to Prevent the Next OutOfMemoryError?
Memory management doesn't have to be reactive. With the right monitoring setup and early detection, you can fix memory issues before they impact your users. Java heap space errors are serious, but they're also preventable.
Ready to monitor your Java application's memory and catch issues early? Use Odown and get alerts before heap space errors crash your applications.
