How to Master Your Java Memory (and Save Your Programming)

June 06 2016
 

Find out how to fix slow or crashing applications in real-time by detecting symptoms of Java memory leaks with Java memory monitoring tools.


You spent countless hours working out the bugs in your Java application and getting its performance where you need it. During the testing, you noticed the application getting progressively slower over time, outright crashing or exhibiting poor performance. You go through your code and make sure you haven’t missed anything else that could cause these problems. Ultimately, you admit that you’re dealing with a memory leak. Java’s garbage collector does what it can to help with these leaks, but there’s only so much it can do when you’re running into major issues. You need a way to identify what’s causing your memory leaks, ways to address the issue and understanding of the role Java garbage collection plays in your overall application performance.

Primary Symptoms of Java Memory Leaks

You encounter several symptoms indicating the application has a memory leak problem. A slow decline in overall application performance, as opposed to a sudden failure, points strongly towards a memory leak. The problem may occur every time you run the application or only when you start working with more data or otherwise begin scaling it. Your application may display an out of memory error as the memory leak eats up all available resources. You can restart the application and hope for the best, but until you fix the leak, you’re going to encounter multiple crashes. Typically, you deal with memory leaks when object references accumulate rather than release. They take up your available memory and make it impossible for your application to access the resources it needs.

Configuration Errors that Look Like Memory Leaks

Before you look into Java memory issues and analysis, make sure you’re not dealing with an entirely different problem. Some out-of-memory errors come from various causes, such as configuration errors. Your application may lack the right heap size or conflict with other applications on the system. If you start addressing your out-of-memory problems but can’t pinpoint what’s causing the memory leak, take another look at your application. You may discover you need to make changes to your finalizer thread or increase your permanent generation space.

The Benefits of Memory Monitoring Tools

Memory monitoring tools give you greater visibility into how your Java application uses the available resources. You take this step to start narrowing down the root cause of the memory leak and other performance issues. This software comes in several categories, and you may need to use multiple applications to find out what went wrong, whether you’re dealing with a memory leak and how to begin addressing the problem.

Heap dump files give you the necessary output for your Java memory analysis. You may need to use two tools: one for generating the dump file and the other for meaningful analysis. This solution gives you a detailed view of what’s going on with your application. Once the tool highlights potential problem areas, work on narrowing down exactly where the issue occurs. Now, it’s time for the long and frustrating part: trial and error. Your memory analysis tool may indicate several problems with your code, but you don’t know for sure whether they’re causing the performance impact. If you change everything at once, you don’t know exactly what problem your application faced. Even worse, you may introduce brand new errors and have to start the process over again.

Make one change at a time and attempt to duplicate the error. You may need to let the application run for some time to duplicate the original error conditions. If your memory leak goes away with the first test, don’t forget to test it under load. Your application may work fine with small amounts of data but run back into the same issues with large sets. If you still run into the same error, start from the beginning and attack another potential cause.

Memory monitoring tools prove useful after you get your application working perfectly. You can remotely keep an eye on JVM performance and proactively address issues before you run into problems, gather historical performance data to help you improve your programming efforts in the future and observe how Java operates under a heavy load. Some solutions include alarms and other alerts so you know the instant something starts going wrong. You don’t want a mission critical application crashing and causing tens of thousands of dollars in losses due to downtime, so these tools increase your response time. Your memory-monitoring software also lets you start the diagnostic process instantly, rather than requiring you to go on-site when no one tells you the exact error codes or problems happening at the office.

If you frequently run into memory and performance problems with your Java applications, take a hard look at your testing process. Identify any weak areas in your process and change your testing strategies. Reach out to other Java programmers and compare QA best practices. Sometimes, you may overlook a small aspect of your code and cause a long-lasting impact for your entire application.

The Garbage Collection’s Role in Java Memory and Memory Leaks

Java’s garbage collection plays a key role in your application performance and memory usage. This program searches for objects no longer in use and removes them. These dead objects no longer take up memory, so your application continues to have resources available. Sometimes, your application doesn’t give GC sufficient time or resources to clear dead objects and they pile up. You may also run into a situation where you have active references to objects you assume are dead. The garbage collector can’t do anything about these because its automated memory management skips over active objects. Typically, the GC runs autonomously, but you may need to adjust its behavior to adapt to challenging memory problems. However, GC may lead to performance issues on its own.

GC Generations

The GC divides objects into different generations to optimize collection. The young generation represents objects that die off quickly. The GC frequently runs on this generation since it often has to clean up objects. Objects remaining alive past a certain threshold graduate into the old generation. These objects stay around for a longer time so GC doesn’t run as frequently. However, when GC does run on these objects, your application goes through a major operation where the collector looks through your live objects to remove the garbage. Your application has one final generation: the permanent generation. Typically, these objects include necessary JVM metadata. You don’t generate a lot of garbage with this generation, but your application may need the GC to remove classes after the program no longer needs them.

heap memory

Source: “Understanding Java Garbage Collection for Beginners”, Enterprise Integration for Beginners

The Connection Between GC and Response Time

Garbage collection, whether they’re minor or major, stop application threads until they complete the process. This is called a “Stop the World” event. A single young generation GC doesn’t noticeably impact performance, but you see problems if you have a high churn rate. You end up in a situation where minor GCs run constantly or your old generation grows at an unsustainable rate. You need to balance your young generation GC frequency with your performance, which may require increasing the size of the young generation.

Old generation and permanent generation GC create a significant impact on your application performance and memory usage. This major GC operation goes through the entire heap to pull out dead objects. This process lasts longer than minor GCs, so the performance impact lasts longer. When you have a high churn rate and a larger old generation, your entire application gets bogged down by Stop the World events.

GC optimization requires monitoring how often the program runs, the overall performance impact and how you can adjust your application to reduce this frequency. You may need to identify the same object being allocated more than once, stay away from allocations not necessary for your application or find choke points holding up your entire system. Getting the right balance requires paying close attention to everything from your CPU load to your GC cycles, particularly if your young and old generation frequencies get unbalanced.

Addressing memory leaks and optimizing your garbage collection helps you improve your Java application performance. You juggle many moving parts, but with the right troubleshooting approach and analysis tools designed to give you strong visibility, you can get to the bottom of the problem instead of suffering through frequent performance issues.

Proper memory allocation and monitoring play a critical role in your Java applications. You need to fully grasp the interaction between GC, object removal, memory leaks and performance to optimize your apps and avoid running into out-of-memory errors. Memory monitoring tools let you stay on top of potential issues and identify usage trends, so you take a proactive approach instead of a reactive approach to troubleshooting. Memory leaks often prove frustrating to troubleshoot, especially if you run into false positives attributed to misconfiguration, but handling memory issues as early as possible allows you to avoid larger issues down the road. Master your Java memory and GC to make your entire programming life much easier.

Aakrit Prasad
Aakrit is an industry professional presently responsible for leading product growth and innovation initiatives for Core & APM products at AppDynamics.

With 7+ years of professional industry experience, he has worked in multiple different engineering & product leadership roles, gaining necessary skills to head enterprise grade, disruptive technology products. He was previously a Product Owner and Senior Staff Software & Performance Engineer at Salesforce, managing the core product performance & scale growth and capacity strategy. Prior to Salesforce, he worked as a Sr Software & Process Automation Engineer for numerous years. He has a M.S. in Computer Science with a focus on high performance computing & back-end distributed systems from the University of Chicago and a B.S.E. in Materials Science & Engineering specializing in Electronic Materials & Polymers from the Ohio State University.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form