The second scenario may be hard to diagnose if the used heap size is not monitored.
In the second one that usually occurs when on each GC invocation a little memory can be reclaimed, the app may run into another problem: it would not crash, but it would spend almost all its time in GC, giving the impression of hanging. In the first one, the app would crash soon with an OutOfMemoryError.
Then, depending on some secondary factors, there are two scenarios. First, the GC pauses will become more frequent and take longer. But if your cache has no size limit or other purge mechanisms the amount of external data is high relative to the JVM heap and if the app runs for long enough - you may run into problems. Improving performance by avoiding repeated slow reads from the external storage, at the expense of some extra memory, is generally a smart choice. Alternatively, some data generated at runtime, such as operation history, may be periodically dumped to disk, but also retained in memory, again to speed up access to it. One common source of memory leaks is memory caches that are used to avoid slow operations, such as repeated retrieval of the same objects from the database. This is the main reason why suboptimal code causing a memory leak can sneak in. However, there is one caveat: unit tests are rarely written to model real-life amounts of data and/or real-life run duration. Well-tested libraries and app code ensure a well-behaved application. The catch? They would likely have a limited understanding of how exactly this app, or at least some of its parts, work.įortunately, a large part of such concerns can be addressed by unit tests. A loose group or even a single developer can quickly put together a really big application that works. Presently, with the rich set of JDK library classes and an even richer choice of third-party open-source code, with powerful IDEs and, above all, the powerful yet "forgiving" language that Java has become, the situation is different. In the old, pre-Java days, writing a big program in C++ was a slow, sometimes painful, process that required a serious effort of a well-coordinated group of developers. One can argue that they are a side effect of the power of the language and its ecosystem. So, why is "memory leak" still one of the common problems with memory in Java apps? If you are wondering about it or have ever struggled to try to understand why your app's used memory keeps growing, read on.īriefly speaking, memory leaks in Java are not real leaks - they are simply data structures that grow uncontrolled due to errors or suboptimal code. become inaccessible to the running program yet use up memory - not for long time, anyway. So, no object in Java can really "leak," i.e. The most common GC roots are local variables in methods and static data fields an object is reachable when a GC root points to it directly or through a chain of other objects. At runtime, any object that is not reachable from a GC root will be automatically destroyed and its memory recycled (sooner or later). One of the main reasons for Java's popularity is Garbage Collection.