{"id":12826,"date":"2017-08-14T10:37:48","date_gmt":"2017-08-14T10:37:48","guid":{"rendered":"https:\/\/stackify.com\/?p=12826"},"modified":"2024-03-04T07:07:03","modified_gmt":"2024-03-04T07:07:03","slug":"memory-leaks-java","status":"publish","type":"post","link":"https:\/\/stackify.com\/memory-leaks-java\/","title":{"rendered":"How Memory Leaks Happen in a Java Application"},"content":{"rendered":"

Introduction to Memory Leaks In Java Apps<\/strong><\/h2>\n

One of the core benefits of Java is the JVM, which is an out-of-the-box memory management<\/a>. Essentially, we can\u00a0create objects and the Java Garbage Collector<\/a> will take care of allocating and freeing up memory for us.<\/p>\n

Nevertheless, memory leaks can still occur in Java applications.<\/strong><\/p>\n

In this article, we’re going to describe the most common memory leaks, understand their causes, and look at a few techniques to detect\/avoid them. We’re also going to use the Java YourKit profiler throughout the article, to analyze the state of our memory at runtime.<\/p>\n

1. What is a Memory Leak in Java?<\/strong><\/h3>\n

The standard definition of a memory leak is a scenario that occurs when objects are no longer being used by the application, but the Garbage Collector is unable to remove them from working memory<\/strong>\u00a0– because they’re still being referenced. As a result, the application consumes more and more resources – which eventually leads to a fatal OutOfMemoryError<\/em>.<\/p>\n

For a better understanding of the concept, here’s a simple visual representation:<\/p>\n

\"How<\/p>\n

As we can see, we have two types of objects – referenced and unreferenced; the Garbage Collector can remove objects that are unreferenced. Referenced objects won’t be collected, even if they’re actually not longer used by the application.<\/p>\n

Detecting memory leaks can be difficult. A number of tools perform static analysis to determine potential leaks, but these techniques aren’t perfect because the most important aspect is the actual runtime behavior of the running system.<\/p>\n

So, let’s have a focused look at some of the standard practices of preventing memory leaks<\/a>, by analyzing some common scenarios<\/strong>.<\/p>\n

2. Java Heap Leaks<\/strong><\/h3>\n

In this initial section, we’re going to focus on the classic memory leak scenario – where Java objects are continuously created without being released.<\/p>\n

An advantageous technique to understand these situations is to make reproducing a memory leak easier by setting a lower size for the Heap<\/strong>. That’s why, when starting our application, we can adjust the JVM to suit our memory needs:<\/p>\n

-Xms<size><\/pre>\n
-Xmx<size><\/pre>\n
These parameters specify the initial Java Heap size as well as the maximum Heap size.<\/p>\n
2.1. Static Field Holding On to the Object Reference<\/strong><\/h4>\n
The first scenario that might cause a Java memory leak is referencing a heavy object with a static field.<\/p>\n
Let’s have a look at a quick example:<\/p>\n
private Random random = new Random();\npublic static final ArrayList<Double> list = new ArrayList<Double>(1000000);\n\n@Test\npublic void givenStaticField_whenLotsOfOperations_thenMemoryLeak() throws InterruptedException {\n    for (int i = 0; i < 1000000; i++) {\n        list.add(random.nextDouble());\n    }\n    \n    System.gc();\n    Thread.sleep(10000); \/\/ to allow GC do its job\n}<\/pre>\n
We created our ArrayList<\/em>\u00a0as a static field – which will never be collected by the JVM Garbage Collector during the lifetime of the JVM process, even after the calculations it was used for are done. We also invoked\u00a0Thread.sleep(10000)<\/em> to allow the GC to perform a full collection and try to reclaim everything that can be reclaimed.<\/p>\n
Let’s run the test and analyze the JVM with our profiler:<\/p>\n
\"Java<\/p>\n
Notice how, at the very beginning, all memory is, of course, free.<\/p>\n
Then, in just 2 seconds, the iteration process runs and finishes – loading everything into the list (naturally this will depend on the machine you’re running the test on).<\/p>\n
After that, a full garbage collection cycle is triggered, and the test continues to execute, to allow this cycle time to run and finish. As you can see, the list is not reclaimed and the memory consumption doesn’t go down.<\/p>\n
Let’s now see the exact same example, only this time, the ArrayList<\/em> isn’t referenced by a static variable. Instead, it’s a local variable that gets created, used and then discarded:<\/p>\n
@Test\npublic void givenNormalField_whenLotsOfOperations_thenGCWorksFine() throws InterruptedException {\n    addElementsToTheList();\n    System.gc();\n    Thread.sleep(10000); \/\/ to allow GC do its job\n}\n    \nprivate void addElementsToTheList(){\n    ArrayList<Double> list = new ArrayList<Double>(1000000);\n    for (int i = 0; i < 1000000; i++) {\n        list.add(random.nextDouble());\n    }\n}<\/pre>\n
Once the method finishes its job, we’ll observe the major GC collection, around 50th second on the image below:<\/p>\n
\"Java<\/p>\n
Notice how the GC is now able to reclaim some of the memory utilized by the JVM.<\/p>\n
How to prevent it?<\/strong><\/h4>\n
Now that you understand the scenario, there are of course ways to prevent it from occurring.<\/p>\n
First, we need to pay close attention to our usage of static<\/em><\/strong>; declaring any collection or heavy object as static <\/em>ties its lifecycle to the lifecycle of the JVM itself, and makes the entire object graph impossible to collect.<\/p>\n
We also need to be aware of collections in general – that’s a common way to unintentionally hold on to references for longer than we need to.<\/p>\n
2.2. Calling String.intern()<\/em> on Long String<\/em><\/strong><\/h4>\n
The second group of scenarios that frequently causes memory leaks involves\u00a0String<\/em> operations – specifically the\u00a0String.intern()<\/em> API.\u00a0<\/em><\/p>\n
Let’s have a look at a quick example:<\/p>\n
@Test\npublic void givenLengthString_whenIntern_thenOutOfMemory()\n  throws IOException, InterruptedException {\n    Thread.sleep(15000);\n    \n    String str \n      = new Scanner(new File(\"src\/test\/resources\/large.txt\"), \"UTF-8\")\n      .useDelimiter(\"\\\\A\").next();\n    str.intern();\n    \n   \u00a0System.gc(); \n    Thread.sleep(15000);\n}<\/pre>\n
Here, we simply try to load a large text file into running memory and then return a canonical form, using .intern()<\/em>.<\/p>\n
The intern<\/em> API\u00a0will place the str<\/em>\u00a0String in the JVM memory pool – where it can’t be collected – and again, this will cause the GC to be unable to free up enough memory:<\/p>\n
\"Java<\/p>\n
We can clearly see that in the first 15th seconds JVM is stable, then we load the file and JVM perform\u00a0garbage collection (20th second).<\/p>\n
Finally, the str.intern()<\/em> is invoked, which leads to the memory leak – the stable line indicating high heap memory usage, which will never be released.<\/p>\n
How to prevent it?<\/strong><\/h4>\n
Please remember that interned String\u00a0<\/em>objects are stored in PermGen<\/em> space – if our application is intended to perform a lot of operations on large strings<\/a>, we might need to increase the size of the permanent generation:<\/p>\n
-XX:MaxPermSize=<size><\/pre>\n
The second solution is to use Java 8 – where the PermGen<\/em> space is replaced by the\u00a0Metaspace <\/em>– which won’t lead to any\u00a0OutOfMemoryError\u00a0<\/em>when using\u00a0intern<\/em> on Strings:<\/p>\n
\"\"<\/p>\n
Finally, there are also several options of avoiding the .intern()<\/em> API on Strings as well.<\/p>\n
2.3. Unclosed Streams<\/strong><\/h4>\n
Forgetting to close a stream is a very common scenario, and certainly, one that most developers can relate to. The problem was partially removed in Java 7 when the ability to automatically close all types of streams was introduced into the try-with-resource<\/em> clause<\/a>.<\/p>\n
Why partially? Because the\u00a0try-with-resources<\/em>\u00a0syntax is optional<\/strong>:<\/p>\n
@Test(expected = OutOfMemoryError.class)\npublic void givenURL_whenUnclosedStream_thenOutOfMemory()\n  throws IOException, URISyntaxException {\n    String str = \"\";\n    URLConnection conn \n      = new URL(\"http:\/\/norvig.com\/big.txt\").openConnection();\n    BufferedReader br = new BufferedReader(\n      new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8));\n    \n    while (br.readLine() != null) {\n        str += br.readLine();\n    } \n    \n    \/\/\n}<\/pre>\n
Let’s see how the memory of the application looks when loading a large file from an URL:<\/p>\n
\"Java<\/p>\n
As we can see, the heap usage is gradually increasing over time – which is the direct impact of the memory leak caused by not closing the stream.<\/p>\n
Let’s dig a bit deeper into this scenario because it’s not as clear-cut as the rest. Technically, an unclosed stream will result in two types of leaks – a low-level resource leak and memory leak.<\/p>\n
The low-level resource leak is simply the leak of an OS-level resource – such as file descriptors, open connections, etc. These resources can also leak, just like memory does.<\/p>\n
Of course, the JVM uses memory to keep track of these underlying resources as well, which is why this also results in a memory leak<\/strong>.<\/p>\n
How to prevent it?<\/strong><\/h4>\n
We always need to remember to close streams manually, or to make a use of the auto-close feature introduced in Java 8:<\/p>\n
try (BufferedReader br = new BufferedReader(\n  new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8))) {\n    \/\/ further implementation\n} catch (IOException e) {\n    e.printStackTrace();\n}<\/pre>\n
In this case, the BufferedReader<\/em> will be automatically closed at the end of the try<\/em> statement, without the need to close it in an explicit finally<\/em> block.<\/p>\n
2.4. Unclosed Connections<\/strong><\/h4>\n
This scenario is quite similar to the previous one, with the primary difference of dealing with unclosed connections (e.g. to a database, to an FTP server, etc.). Again, improper implementation can do a lot of harm, leading to memory problems.<\/p>\n
Let’s see a quick example:<\/p>\n
@Test(expected = OutOfMemoryError.class)\npublic void givenConnection_whenUnclosed_thenOutOfMemory()\n  throws IOException, URISyntaxException {\n    \n    URL url = new URL(\"ftp:\/\/speedtest.tele2.net\");\n    URLConnection urlc = url.openConnection();\n    InputStream is = urlc.getInputStream();\n    String str = \"\";\n    \n    \/\/\n}<\/pre>\n
The URLConnection<\/em> remains open, and the result is, predictably, a memory leak:<\/p>\n
\"Java<\/p>\n
Notice how the Garbage Collector cannot do anything to release unused, but referenced memory. The situation is immediately clear after the 1st minute – the number of GC operations rapidly decreases, causing increased Heap memory use, which leads to the OutOfMemoryError.<\/em><\/p>\n
How to prevent it?<\/strong><\/h4>\n
The answer here is simple – we need to always close connections in a disciplined manner.<\/p>\n
2.5. Adding Objects with no hashCode()<\/em> and equals()<\/em> into a HashSet<\/em><\/strong><\/h4>\n
A simple but very common example that can lead to a memory leak is to use a HashSet<\/em>\u00a0with objects that are missing their\u00a0hashCode()<\/em> or equals()<\/em>\u00a0implementations.<\/p>\n
Specifically, when we start adding duplicate\u00a0objects into a Set<\/em>\u00a0– this will only ever grow, instead of ignoring duplicates as it should. We also won’t be able to remove these objects, once added.<\/p>\n
Let’s create a simple class without either equals<\/em> or hashCode<\/em>:<\/p>\n
public class Key {\n    public String key;\n    \n    public Key(String key) {\n        Key.key = key;\n    }\n}<\/pre>\n
Now, let’s see the scenario:<\/p>\n
@Test(expected = OutOfMemoryError.class)\npublic void givenMap_whenNoEqualsNoHashCodeMethods_thenOutOfMemory()\n  throws IOException, URISyntaxException {\n    Map<Object, Object> map = System.getProperties();\n    while (true) {\n        map.put(new Key(\"key\"), \"value\");\n    }\n}<\/pre>\n
This simple implementation will lead to the following scenario at runtime:<\/p>\n
\"Java<\/p>\n
Notice how the garbage collector stopped being able to reclaim memory around 1:40, and notice the memory leak; the number of GC collections dropped almost four times immediately after.<\/p>\n
How to prevent it?<\/strong><\/h4>\n
In these situations, the solution is simple – it’s crucial to provide the hashCode()<\/em> and equals()<\/em> implementations.<\/p>\n
One tool worth mentioning here is Project Lombok<\/a>\u00a0– this provides a lot of default implementation by annotations, e.g.\u00a0@EqualsAndHashCode<\/em><\/a>.<\/p>\n
3. How to Find Leaking Sources in Your Application<\/strong><\/h3>\n
Diagnosing memory leaks is a lengthy process that requires a lot of practical experience, debugging skills and detailed knowledge of the application.<\/p>\n
Let’s see which techniques can help you in addition to standard profiling.<\/p>\n
3.1. Verbose Garbage Collection<\/strong><\/h4>\n
One of the quickest ways to identify a memory leak is to enable verbose garbage collection.<\/p>\n
By adding the\u00a0-verbose:gc<\/em> parameter to the JVM configuration of our application, we’re enabling a very detailed trace of GC. Summary reports are shown in default error output file, which should help you understand how your memory is being managed.<\/p>\n
3.2. Do Profiling<\/strong><\/h4>\n
The second technique is the one we’ve been using throughout this article – and that’s profiling. The most popular profiler is\u00a0Visual VM<\/a>\u00a0– which is a good place to start moving past command-line JDK tools and into lightweight profiling.<\/p>\n
In this article, we used another profiler – YourKit – which has some additional, more advanced features compared to Visual VM.<\/p>\n
3.3. Review Your Code<\/strong><\/h4>\n
Finally, this is more of a general good practice than a specific technique to deal with memory leaks.<\/p>\n
Simply put – review your code thoroughly, practice regular code reviews and make good use of static analysis tools to help you understand your code and your system.<\/p>\n
Conclusion<\/strong><\/h3>\n
In this tutorial, we had a practical look at how memory leaks happen on the JVM. Understanding how these scenarios happen is the first step in the process of dealing with them.<\/p>\n
Then, having the techniques and tools to really see what’s happening at runtime, as the leak occurs, is critical as well. Static analysis and careful code-focused reviews can only do so much, and – at the end of the day – it’s the runtime that will show you the more complex leaks that aren’t immediately identifiable in the code.<\/p>\n
Finally, leaks can be notoriously hard to find and reproduce\u00a0because many of them only happen under intense load, which generally happens in production.\u00a0<\/strong>This is where you need to go beyond code-level analysis and work on two main aspects – reproduction and early detection.<\/p>\n
The best and most reliable way to reproduce memory leaks<\/strong> is to simulate the usage patterns of a production environment as close as possible, with the help of a good suite of performance tests<\/a>.<\/p>\n
And early detection<\/strong> is where a\u00a0solid performance management solution<\/a>\u00a0and even an early detection solution<\/a> can make a significant difference, as it’s the only way to have the necessary insight into the runtime of your application in production.<\/p>\n
The\u00a0full implementation\u00a0of this tutorial can be found over on GitHub. This is a Maven based project, so it can simply be imported and run as it is.<\/p>\n","protected":false},"excerpt":{"rendered":"
Introduction to Memory Leaks In Java Apps One of the core benefits of Java is the JVM, which is an out-of-the-box memory management. Essentially, we can\u00a0create objects and the Java Garbage Collector will take care of allocating and freeing up memory for us. Nevertheless, memory leaks can still occur in Java applications. In this article, […]<\/p>\n","protected":false},"author":15,"featured_media":38269,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7],"tags":[40],"class_list":["post-12826","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-developers","tag-java"],"acf":[],"yoast_head":"\nUnderstand and Prevent Memory Leaks in a Java Application<\/title>\n<meta name=\"description\" content=\"Memory leaks are a very real problem in Java and the JVM can only help so much. Learn how to understand leaks, recognize them at runtime and deal with them.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/stackify.com\/memory-leaks-java\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Understand and Prevent Memory Leaks in a Java Application\" \/>\n<meta property=\"og:description\" content=\"Memory leaks are a very real problem in Java and the JVM can only help so much. Learn how to understand leaks, recognize them at runtime and deal with them.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/stackify.com\/memory-leaks-java\/\" \/>\n<meta property=\"og:site_name\" content=\"Stackify\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/Stackify\/\" \/>\n<meta property=\"article:published_time\" content=\"2017-08-14T10:37:48+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-03-04T07:07:03+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"881\" \/>\n\t<meta property=\"og:image:height\" content=\"441\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Eugen Paraschiv\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@stackify\" \/>\n<meta name=\"twitter:site\" content=\"@stackify\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Eugen Paraschiv\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/stackify.com\/memory-leaks-java\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/stackify.com\/memory-leaks-java\/\"},\"author\":{\"name\":\"Eugen Paraschiv\",\"@id\":\"https:\/\/stackify.com\/#\/schema\/person\/e372b6a6f64edbedafad33027d518482\"},\"headline\":\"How Memory Leaks Happen in a Java Application\",\"datePublished\":\"2017-08-14T10:37:48+00:00\",\"dateModified\":\"2024-03-04T07:07:03+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/stackify.com\/memory-leaks-java\/\"},\"wordCount\":1902,\"publisher\":{\"@id\":\"https:\/\/stackify.com\/#organization\"},\"image\":{\"@id\":\"https:\/\/stackify.com\/memory-leaks-java\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg\",\"keywords\":[\"Java\"],\"articleSection\":[\"Developer Tips, Tricks & Resources\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/stackify.com\/memory-leaks-java\/\",\"url\":\"https:\/\/stackify.com\/memory-leaks-java\/\",\"name\":\"Understand and Prevent Memory Leaks in a Java Application\",\"isPartOf\":{\"@id\":\"https:\/\/stackify.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/stackify.com\/memory-leaks-java\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/stackify.com\/memory-leaks-java\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg\",\"datePublished\":\"2017-08-14T10:37:48+00:00\",\"dateModified\":\"2024-03-04T07:07:03+00:00\",\"description\":\"Memory leaks are a very real problem in Java and the JVM can only help so much. Learn how to understand leaks, recognize them at runtime and deal with them.\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/stackify.com\/memory-leaks-java\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/stackify.com\/memory-leaks-java\/#primaryimage\",\"url\":\"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg\",\"contentUrl\":\"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg\",\"width\":881,\"height\":441},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/stackify.com\/#website\",\"url\":\"https:\/\/stackify.com\/\",\"name\":\"Stackify\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/stackify.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/stackify.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/stackify.com\/#organization\",\"name\":\"Stackify\",\"url\":\"https:\/\/stackify.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/stackify.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/stackify.com\/wp-content\/uploads\/2024\/05\/logo-1.png\",\"contentUrl\":\"https:\/\/stackify.com\/wp-content\/uploads\/2024\/05\/logo-1.png\",\"width\":1377,\"height\":430,\"caption\":\"Stackify\"},\"image\":{\"@id\":\"https:\/\/stackify.com\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/Stackify\/\",\"https:\/\/x.com\/stackify\",\"https:\/\/www.instagram.com\/stackify\/\",\"https:\/\/www.linkedin.com\/company\/2596184\",\"https:\/\/www.youtube.com\/stackify\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/stackify.com\/#\/schema\/person\/e372b6a6f64edbedafad33027d518482\",\"name\":\"Eugen Paraschiv\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/stackify.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/0c0bb39bd24aea78b56c6516a3e7dcab?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/0c0bb39bd24aea78b56c6516a3e7dcab?s=96&d=mm&r=g\",\"caption\":\"Eugen Paraschiv\"}}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Understand and Prevent Memory Leaks in a Java Application","description":"Memory leaks are a very real problem in Java and the JVM can only help so much. Learn how to understand leaks, recognize them at runtime and deal with them.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/stackify.com\/memory-leaks-java\/","og_locale":"en_US","og_type":"article","og_title":"Understand and Prevent Memory Leaks in a Java Application","og_description":"Memory leaks are a very real problem in Java and the JVM can only help so much. Learn how to understand leaks, recognize them at runtime and deal with them.","og_url":"https:\/\/stackify.com\/memory-leaks-java\/","og_site_name":"Stackify","article_publisher":"https:\/\/www.facebook.com\/Stackify\/","article_published_time":"2017-08-14T10:37:48+00:00","article_modified_time":"2024-03-04T07:07:03+00:00","og_image":[{"width":881,"height":441,"url":"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg","type":"image\/jpeg"}],"author":"Eugen Paraschiv","twitter_card":"summary_large_image","twitter_creator":"@stackify","twitter_site":"@stackify","twitter_misc":{"Written by":"Eugen Paraschiv","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/stackify.com\/memory-leaks-java\/#article","isPartOf":{"@id":"https:\/\/stackify.com\/memory-leaks-java\/"},"author":{"name":"Eugen Paraschiv","@id":"https:\/\/stackify.com\/#\/schema\/person\/e372b6a6f64edbedafad33027d518482"},"headline":"How Memory Leaks Happen in a Java Application","datePublished":"2017-08-14T10:37:48+00:00","dateModified":"2024-03-04T07:07:03+00:00","mainEntityOfPage":{"@id":"https:\/\/stackify.com\/memory-leaks-java\/"},"wordCount":1902,"publisher":{"@id":"https:\/\/stackify.com\/#organization"},"image":{"@id":"https:\/\/stackify.com\/memory-leaks-java\/#primaryimage"},"thumbnailUrl":"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg","keywords":["Java"],"articleSection":["Developer Tips, Tricks & Resources"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/stackify.com\/memory-leaks-java\/","url":"https:\/\/stackify.com\/memory-leaks-java\/","name":"Understand and Prevent Memory Leaks in a Java Application","isPartOf":{"@id":"https:\/\/stackify.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/stackify.com\/memory-leaks-java\/#primaryimage"},"image":{"@id":"https:\/\/stackify.com\/memory-leaks-java\/#primaryimage"},"thumbnailUrl":"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg","datePublished":"2017-08-14T10:37:48+00:00","dateModified":"2024-03-04T07:07:03+00:00","description":"Memory leaks are a very real problem in Java and the JVM can only help so much. Learn how to understand leaks, recognize them at runtime and deal with them.","inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/stackify.com\/memory-leaks-java\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/stackify.com\/memory-leaks-java\/#primaryimage","url":"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg","contentUrl":"https:\/\/stackify.com\/wp-content\/uploads\/2017\/08\/Java-Memory-Leaks-881x441-1.jpg","width":881,"height":441},{"@type":"WebSite","@id":"https:\/\/stackify.com\/#website","url":"https:\/\/stackify.com\/","name":"Stackify","description":"","publisher":{"@id":"https:\/\/stackify.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/stackify.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/stackify.com\/#organization","name":"Stackify","url":"https:\/\/stackify.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/stackify.com\/#\/schema\/logo\/image\/","url":"https:\/\/stackify.com\/wp-content\/uploads\/2024\/05\/logo-1.png","contentUrl":"https:\/\/stackify.com\/wp-content\/uploads\/2024\/05\/logo-1.png","width":1377,"height":430,"caption":"Stackify"},"image":{"@id":"https:\/\/stackify.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/Stackify\/","https:\/\/x.com\/stackify","https:\/\/www.instagram.com\/stackify\/","https:\/\/www.linkedin.com\/company\/2596184","https:\/\/www.youtube.com\/stackify"]},{"@type":"Person","@id":"https:\/\/stackify.com\/#\/schema\/person\/e372b6a6f64edbedafad33027d518482","name":"Eugen Paraschiv","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/stackify.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/0c0bb39bd24aea78b56c6516a3e7dcab?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/0c0bb39bd24aea78b56c6516a3e7dcab?s=96&d=mm&r=g","caption":"Eugen Paraschiv"}}]}},"_links":{"self":[{"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/posts\/12826"}],"collection":[{"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/users\/15"}],"replies":[{"embeddable":true,"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/comments?post=12826"}],"version-history":[{"count":2,"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/posts\/12826\/revisions"}],"predecessor-version":[{"id":42907,"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/posts\/12826\/revisions\/42907"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/media\/38269"}],"wp:attachment":[{"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/media?parent=12826"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/categories?post=12826"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/stackify.com\/wp-json\/wp\/v2\/tags?post=12826"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}