Memory leaks in Java can occur due to objects remaining reachable even when no longer needed. The four main causes are unknown references, long-living objects, failure to clean up native resources, and bugs. To detect leaks, one can use verbose GC logging, monitor the Java process, dump the heap to analyze which objects are retaining others, and use profiling tools. Profiling works by insertion of code, sampling, or instrumenting the virtual machine and helps identify where time is being spent and what objects are being allocated.

1. Memory Leaks in Java
By:- Ashish Bhasin
ashbhasin@yahoo.com

2. Agenda
• Introduction
• Resolving Memory Leaks

3. Then why are we
here???
Memory Management
is done by Java
Introduction

4. Memory Manager – Garbage collector (GC)
• A key feature of memory management in
Java is its garbage-collected heap
– Garbage collector (GC) that comes with
Java is a tracing collector, which determines
which objects should be preserved in
memory by tracing all objects reachable
from a set of roots.
– These reachable objects survive collections
because they may be used in the course of
program execution.

5. Memory Manager – Garbage collector (GC)

6. What is Memory Leak in Java ?
Note :-
When no more memory is remaining, an OutOfMemoryError alert will be
thrown and generate an exception like this:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at

7. 7
What is memory leak in java?
(Memory Map)
Java Memory
leak
Allocated
Reachable
Live
Handled by
JVM

8. 8
Why Memory Leak is BAD…
• Memory-related issues affect
execution speed and reliability of
application.

9. Causes of memory leaks in Java
• The four typical causes of memory leaks in a Java
program are:
– Unknown or unwanted object references: These objects are no longer
needed, but the garbage collector can not reclaim the memory
because another object still refers to it.
– Long-living (static) objects: These objects stay in the memory for the
application's full lifetime. Objects tagged to the session may also have
the same lifetime as the session, which is created per user and
remains until the user logs out of the application.
– Failure to clean up or free native system resources: Native system
resources are resources allocated by a function external to Java,
typically native code written in C or C++. Java Native Interface (JNI)
APIs are used to embed native libraries/code into Java code.
– Bugs in the JDK or third-party libraries: Bugs in various versions of the
JDK or in the Abstract Window Toolkit and Swing packages can
cause memory leaks.

10. Types of Memory Leaks in Objects
Lapsed Listener Object added to collection, not removed
e.g. event listener, observer
collection size can grow without bound
iteration over “dead” objects degrades
performance
Lingerer Reference used transiently by
long-term object
Reference always reset on next use
e.g. associations with menu items
e.g. global action or service
Limbo Reference pinned by long-running thread
references on stack
GC doesn’t do local liveness analysis

11. Lapsed Listener – An Example (1/2)
• Listeners are commonly used to specify event
handlers for events that occur to the object.
Some commonly used event types are:
– GUI events: listener classes implementing
java.util.EventListener interface for GUI events in
AWT, Swing, and other GUI libraries.
– Database connection events; listeners implement
ConnectionEventListener interface in javax.sql.
Note :-
• The listener pattern, a specific class of the observer pattern, consists of a subject and an
observer.
• The listener pattern is widespread, it is error-prone and may cause memory leaks if not
used properly.

12. • Listener registration:
object.addMyListener(n
ewMyListener(...));
• unregistering the
listener and allowing
object to be garbage-
collected.object.remov
eMyListener(l);
A typical large-scale application with a GUI and a database back end may use
dozens of different types of listeners, all of which have to be unregistered to avoid
memory leaks.
Lapsed Listener – An Example (2/2)

13. We will see how
to catch Memory
leaks
Oops, Java has
memory leaks
Resolving Memory
Leaks

14. Resolving Memory Leaks
• What to look in your program
– Is My Program actually leaking Memory
– Monitoring Process
– Dump the heap
– Analyze the heap

15. Note
• FIG 1 :- The graph below shows the memory usage in a healthy Java application that does not suffer from
memory leaks, with the peak load occurring around 10 AM and application usage drastically decreasing at 5 PM.
Naturally, the peak load on business applications often correlates with normal business hours.
• FIG 2 :- let's suppose that we have a memory leak in the application. The primary characteristic of memory leaks
is that memory requirements increase as a function of time, not as a function of the load. Let's see how the
application would look after running for a few days with a memory leak and the same peak user loads reached
around 10 AM every day:
• There is one special case that should be noted here: a program that needs to be restarted periodically in order to
prevent it from crashing with an OutOfMemoryError alert.
Is My Program Leaking Memory?

16. Monitoring Memory Leaks
- Verbose GC log
Monitoring using GC which shows that we might
have leak in the program

17. Monitoring Java Process

18. Dump the Heap
• Note
– Before you dump heap, be sure to keep the following issues in
mind:
• Programs in the JVM should be paused for the duration of the heap dump,
• Heap dumps are saved on disk, and the files might be fairly large.

19. Tools to Analyze Heap Dump
Fast leak
Slow leak

20. Analyzing the Heap Dump for Fast Memory
Leaks
• Analyzing the heap dump is done in order to:
– Find objects that are "leaking"
– Find the root cause of the memory leak

21. Slow and Small Memory Leaks

22. Profiling

23. Profiling
• What is Profiling?
• What Profiling Tells You
• What Profiling Is Not
• Manual Profiling
• Profiling Techniques Overview
– Insertion
– Sampling
– Instrumented VM

24. What is Profiling?
• Profiling is measuring an application,
specifically:
– where is the time being spent?
• This is “classical” profiling
• which method takes the most time?
• which method is called the most?
– how is memory being used?
• what kind of objects are being created?
• this in especially applicable in OO, GC’ed
environments

25. What Profiling Tells You
• Basic information:
– How much time is spent in each
method? (“flat” profiling)
– How many objects of each type are
allocated?

26. What Profiling Tells You
• Beyond the basics:
– Program flow (“hierarchical” profiling)
• do calls to method A cause method B to take
too much time?
– Per-line information
• which line(s) in a given method are the most
expensive?
• Which methods created which objects?
– Visualization aspects
• Is it easy to use the profiler to get to the
information you’re interested in?

27. What Profiling Is Not
• Profiling is measuring performance
statistics on your particular
application
– regardless of the underlying platform
• Benchmarking is measuring the
performance of a particular platform
– not a specific application
• Optimization is an automatic
technique that applies generic
enhancements to speed up code
– regardless of the application or platform

28. Optimization
• Even though optimization isn’t always
enough, it’s a good place to start
• Java is designed to be optimized by
the JVM, not by the compiler
– even though there are optimizing
compilers
• JIT compilers help
• Sun’s next-generation JVM, HotSpot,
offers:
– generational garbage collection
– improved, profiling native compiler

29. Manual Profiling
• You don’t absolutely need to have a
profiling tool to profile your code… you
could
– build your own profiling tool
• see Dr. Dobb’s Journal, March 1998
• Or Dr. Dobbs, Sept. 1999
– use very simple code-insertion techniques
• System.out.println(System.getCurrentTimeMillis());

30. Profiling Techniques Overview
• Commercial profilers use one of three
techniques for profiling programs:
– insertion
– sampling
– instrumented virtual machine
• Why is it important to understand how a
profiler works?
– each different technique has its own pros &
cons
– different profilers may give different results

31. Insertion
• Multiple flavours:
– Source code insertion
• profiling code goes in with the source
• easy to do
– Object code insertion
• profiling code goes into the .o (C++) or
.class (Java) files
• can be done statically or dynamically
• hard to do
– modified class loader

32. Insertion Pros & Cons
• Insertion Pros:
– can be used across a variety of
platforms
– accurate (in some ways)
• can’t easily do memory profiling
• Insertion Cons:
– requires recompilation or relinking of the
app
– profiling code may affect performance
• difficult to calculate exact impact

33. Sampling
• In sampling, the processor or VM is
monitored and at regular intervals an
interrupt executes and saves a
“snapshot” of the processor state
• This data is then compared with the
program’s layout in memory to get an
idea of where the program was at
each sample

34. Sampling Pros & Cons
• Sampling Pros:
– no modification of app is necessary
• Sampling Cons:
– a definite time/accuracy trade-off
• a high sample rate is accurate, but takes a
lot of time
– more…

35. Sampling Pros & Cons
• Sampling Cons:
– very small methods will almost always
be missed
• if a small method is called frequently and
you have are unlucky, small but expensive
methods may never show up
– sampling cannot easily monitor memory
usage

36. Instrumented VM
• Another way to collect information is
to instrument the Java VM
• Using this technique each and every
VM instruction can be monitored
– highly accurate

37. Instrumented VM Pros&Cons
• Pros:
– The most accurate technique
– Can monitor memory usage data as well
as time data
– Can easily be extended to allow remote
profiling
• Cons:
– The instrumented VM is platform-
specific

38. Instrumented VMs
• Java 2 (JDK 1.2 and higher)
– information can be accessed through
JVMPI
– the Java Virtual Machine Profiling
Interface
• http://java.sun.com/products/jdk/1.3/docs/guide/jvmpi
/
• Microsoft JVM
– uses a COM-based interface to provide
profiling information
• JProbe Profiler

39. Common Bottlenecks
• Although profiling can yield some
surprises, often the bottlenecks are
fairly obvious once the profiler points
them out
– excessive heap expansion
– not using System.arraycopy()
– using the “+” operator with String
objects
– using unbuffered I/O streams
– excessive memory allocations
– excessive calls to slow library methods

40. Demo Time