LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
What is memory leak?
Implications of memory leak
How to locate memory leak?
Example Code for simple Memory Leak
Analyze the dump logs
When an application dynamically allocates memory, and
does not free that memory after using it, that program
is said to be having memory leak.
Memory Leak is the gradual loss of system available
memory when the application fails to return the memory
that it has consumed for temporary needs.
What is a memory leak?
Memory can neither be used by the system nor any other program.
Over a period of time; the system eventually runs out of memory
slow response time resulting in performance issues
Implications of memory leak:
Also known as unintentional object retention (the object that
is not needed anymore and should be unreachable is still
reachable, hence cannot be collected)
Basic Types of Memory Leaks
A single large object that is unintentionally held in memory
Small objects that are accumulated over time
Memory Leak Demo
Run the project in demo/MemoryManagement/MemoryLeak
Run Visual VM and open the project
Monitor the project
Heap Snapshots Comparison
Take memory snapshots in different points of time(advised to run garbage
collection before taking snapshot)
Compare the snapshots (e.g. in Visual VM)
Search for leaking objects within the objects that were identified as new
Heap dump (non intrusive)
• Generate a dump file as large as the heap
• Freezes application while dump is generated
• Need to reconfigure VM settings
• Attach a client profiler to introspect
Monitor memory usage
• prstat, top, ps
Monitor GC activity
• jstat, -verbose:gc, visualgc, jconsole
Track down where the problem is
Overview -> overview on the running application
Monitor -> view real-time, high-level data on the memory heap,
thread activity, and the classes loaded in the Java Virtual
Threads -> displays a timeline of current thread activity
Sampler -> provides a tool with performance and memory
Profiler -> enables you to start and stop the profiling session of
a local application
To detect memory leak, use JvisualVM/Jconsole and monitor any application.
Navigate to Profiler->Memory option
Analyze the memory consumption of the live bytes against Class Names.
If you are suspecting Memory Leak,
collect Heap Dump
Heap Summary shows the different generations (areas of the heap),
with the size, the amount used, and the address range. The address
range is especially useful if you are also examining the process with
tools such as pmap.
def new generation total 1152K, used 435K [0x22960000, 0x22a90000, 0x22e40000)
eden space 1088K, 40% used [0x22960000, 0x229ccd40, 0x22a70000)
from space 64K, 0% used [0x22a70000, 0x22a70000, 0x22a80000)
to space 64K, 0% used [0x22a80000, 0x22a80000, 0x22a90000)
tenured generation total 13728K, used 6971K [0x22e40000, 0x23ba8000, 0x269600 00)
the space 13728K, 50% used [0x22e40000, 0x2350ecb0, 0x2350ee00, 0x23ba8000)
compacting perm gen total 12288K, used 1417K [0x26960000, 0x27560000, 0x2a9600 00)
the space 12288K, 11% used [0x26960000, 0x26ac24f8, 0x26ac2600, 0x27560000)
ro space 8192K, 62% used [0x2a960000, 0x2ae5ba98, 0x2ae5bc00, 0x2b160000)
rw space 12288K, 52% used [0x2b160000, 0x2b79e410, 0x2b79e600, 0x2bd60000)
If the Java VM flag -XX:+PrintClassHistogram is set, then the Ctrl-Break handler will produce
a heap histogram.
Navigate to Classes -> select the suspected class -> Show in Instances View
Instances tab -> shows “out of memory”
Heap and lock contention issues:
• Avoid creating objects where primitives could be used (autoboxing
is not for free)
• Avoid String concatenations, use StringBuilder with append()
• Avoid StringBuilder overallocation, set initial size to reduce
• Avoid use of synchronized keyword, look for a java.util.concurrent
• Use java.util.concurrent API instead of "synchronized" Collections
• Don't use exceptions for flow control (Exception objects
allocation), use flow control constructs (if/else, return, switch).
• Don't generate stack traces, they're expensive operations.
• Reduce number of system calls:
Avoid accessing disk: use large buffers or direct buffering
Avoid accessing underlying OS
Avoid processing bytes and characters individually
Tools and Tips - Memory
1. Java heap space
• Low RAM memory
• Small heap
• Memory leak
• More physical memory
• Make heap larger
• Fix memory leaks
2. PermGen space
• Low memory for permanent generation area
• Classes on permanent generation are prevented to be
• Make permanent generation area, larger
• Disable hot deployment or class reloading – for classloader
Tools and Tips - Memory
3. Out of swap space
• Often is caused by JNI code
• No memory available for operating system
• Reserve more memory to operating system
• Lower the heap size
4. Unable to create new native thread
• Big stack size (-Xss)
• Small memory available
• Poor thread management
• Make stack size smaller
• Reserve more memory to operating system
• Lower heap size
• Better thread management
Java 5 thread pool
Tools and Tips - Memory
5. Requested array size exceeds VM limit
• Attempt to allocate an array that is larger than the heap
• Lower the array size
• Make heap larger
6. GC overhead limit exceeded
• Too much time spent on GC (98%) and little heap (2%) to be
• Similar to “java heap space”
• Tune GC behavior
Process and Threads
Thread dump and Analysis
What is a Process?
A program in execution
Provides the resources needed to execute a
One process can't access or modify another process
What is a Thread?
A basic unit of CPU utilization
Lightweight process (LWP)
Multiple threads are executed within a process
Multiple threads shares memory and resources of the
process in which it is created.
Threads in Java
Java language includes a powerful threading facility built into the
language. We can use the threading facility to:
Increases the responsiveness of GUI applications
Take advantage of multiprocessor systems
Simplify program logic when there are multiple independent
Thread is cheap
No need to worry about memory model in different
Thread T1 – has a lock on object O1
Thread T2 – has a lock on object O2
T1 is waiting to access O2, while T2 is
waiting to access O1.
A situation in which a thread has got an object, while waiting
for another object which is locked by another thread, which in
turn is waiting for the object locked by the first thread.
Race Condition and Synchronization
● Race conditions occur when multiple, asynchronously executing
threads access the same object (called a shared resource)
returning unexpected results.
● When two or more threads are trying to access the shared
object, the process of allowing only one thread access that
object is called Synchronization.
● Only one thread can execute the block of code protected by
the same lock at the same time.
• In the java application java thread waits for lock in synchronized method
• Occurs in multi threaded program
• Reduce frequency of synchronized method
• Synchronized block must be implemented to end as soon as possible
public void synchronized methodA(Object param)
Lock contention : Thread lock example
"ExecuteThread: '12' for queue: 'weblogic.kernel.Default'" daemon prio=10 tid=0x0055ae20
nid=23 lwp_id=3722788 waiting for monitor entry [0x2fb6e000..0x2fb6d530]
at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
- locked <0x329fcf50> (a java.lang.Class)
"ExecuteThread: '13' for queue: 'weblogic.kernel.Default'" daemon prio=10 tid=0x0055bde0 nid=24
lwp_id=3722789 waiting for monitor entry [0x2faec000..0x2faec530]
- waiting to lock <0x329fcf50> (a java.lang.Class)
"ExecuteThread: '15' for queue: 'weblogic.kernel.Default'" daemon prio=10 tid=0x0061dc20 nid=26
lwp_id=3722791 waiting for monitor entry [0x2f9ea000..0x2f9ea530]
- waiting to lock <0x329fcf50> (a java.lang.Class)at
Lock contention : Thread dump example
• CWC “Circular Waiting Condition”
• Commonly it makes WAS hang up
• Remove CWC by changing lock direction
• Some JVMs detect dead lock automatically
FOUND A JAVA LEVEL DEADLOCK:
"ExecuteThread: '12' for queue: 'default'":
waiting to lock monitor 0xf96e0 (object 0xbd2e1a20, a weblogic.servlet.jsp.JspStub),
which is locked by "ExecuteThread: '5' for queue: 'default'"
"ExecuteThread: '5' for queue: 'default'":
waiting to lock monitor 0xf8c60 (object 0xbd9dc460, a weblogic.servlet.internal.WebAppServletContext),
which is locked by "ExecuteThread: '12' for queue: 'default'" JAVA STACK INFORMATION FOR
THREADS LISTED ABOVE:
Java Stack for "ExecuteThread: '12' for queue: 'default'":
- waiting to lock <bd2e1a20> (a weblogic.servlet.jsp.JspStub)
Java Stack for "ExecuteThread: '5' for queue: 'default'":
- locked <bd2e1a20> (a weblogic.servlet.jsp.JspStub)
Found 1 deadlock.========================================================
What is "Thread dump“ ?
Thread dump" basically gives you information on what each
of the thread in the VM is doing at any given point of time.
Java's thread dumps are vital for server debugging. It helps us
Performance Related issues
Deadlock (System Locks)
Systems stops processing Traffic
The thread dump consists of the thread stack, including thread state, for all Java
threads in the virtual machine.
The header line contains the following information about each thread:
Indication if the thread is a daemon thread
Thread priority ( prio)
Thread ID ( tid), which is the address of a thread structure in memory
ID of the native thread ( nid)
Thread state: Indicates what the thread was doing at the time of the thread dump
Address range,: Estimate of the valid stack region for the thread
"DestroyJavaVM" prio=10 tid=0x00030400 nid=0x2 waiting on condition
[0x00000000..0xfe77fbf0] java.lang.Thread.State: RUNNABLE
"Thread2" prio=10 tid=0x000d7c00 nid=0xb waiting for monitor entry [0xf36ff000..0xf36ff8c0]
java.lang.Thread.State: BLOCKED (on object monitor) at
Deadlock$DeadlockMakerThread.run(Deadlock.java:32) - waiting to lock <0xf819a938> (a
java.lang.String) - locked <0xf819a970> (a java.lang.String)
"Low Memory Detector" daemon prio=10 tid=0x000c7800 nid=0x8 runnable
[0x00000000..0x00000000] java.lang.Thread.State: RUNNABLE
Java VisualVM (swiss army knife for JVM process monitoring and tracing)
Java VisualVM is an utility that can generate and analyze heap dumps, track down
memory leaks, perform and monitor garbage collection, and perform lightweight
memory and CPU profiling.
There are host of standard Java VisualVM plug-ins available which can expand its
existing functionality. E.g: Jconsole, VisualGC etc
For example, most of the functionality of the JConsole tool is available via the
MBeans tab and the JConsole plug-in wrapper tab
Java VisualVM features:
• View a list of local and remote Java applications.
• View application configuration and runtime environment data:
PID, host, main class, arguments passed to the process, JVM version, JDK home, JVM flags, JVM
arguments, system properties etc.
• Monitor application memory consumption, running threads, and loaded classes.
• Trigger Garbage Collection.
• Create a heap dump.
Multiple views: summary, by class, by instance and also save the heap dump.
• Profile application performance or analyze memory allocation (for local
applications only) and save the profiling data.
• Create thread dump (stack trace of the application's active threads).
• Analyze applications offline, by taking application snapshots.
• Get additional plug-ins contributed by the community.
Display local and remote Java applications.
VisualVM automatically detects and lists locally and remotely running Java applications (jstatd must
be running on the remote host). This way you can easily see what Java applications are running on
your system or check if a remote J2EE server process is alive.
Display application configuration and runtime environment
For each application VisualVM shows basic runtime information: PID, main class, arguments passed
to java process, JVM version, JDK home, JVM flags and arguments and system properties.
Monitor application performance and memory consumption.
VisualVM monitors application CPU usage, GC activity, heap and permanent generation memory,
number of loaded classes and running threads. You can easily detect suspicious memory consumption
and take an action - invoke garbage collection in the application or take a heap dump and browse the
contents of application heap.
Monitor application threads.
All threads running in a Java process are displayed in a timeline and table. You can track thread
activity and uncover inefficient patterns.
Profile application performance or analyze memory allocation. VisualVM includes a built-in
application profiler which can visualize where most of the time is being spent or which objects
consume most of the memory.
Take and display thread dumps. Taking and displaying a thread dump is as easy as clicking a mouse
button. Moreover, simultaneous thread dumps of multiple applications can be taken at once to start
uncovering distributed deadlocks.
Take and browse heap dumps. When you need to browse contents of application memory or
uncover a memory leak in your application, you'll find the built-in HeapWalker tool really handy. It
can read files written in hprof format and is also able to browse heap dumps created by the JVM on
Analyze core dumps. When a Java process crashes, a core dump can be generated by the JVM
containing important information about application state at the time of the crash. VisualVM is able
to display application configuration and runtime environment and to extract thread and heap dumps
from the core dump.
Analyze applications offline. VisualVM is able to save application configuration and runtime
environment together with all taken thread dumps, heap dumps and profiler snapshots into a single
application snapshot which can be later processed offline. This is especially useful for bug reports
where users can provide a single file containing all the necessary information to identify runtime
environment and application state.
VisualVM can be integrated with your IDE (Eclipse and NetBeans IDE) to monitor and analyze the
code iteratively during development.
• JConsole is a monitoring tool that uses built-in JMX instrumentation in the JVM to
provide information on performance and resource consumption of the running applications.
• Useful in high-level diagnosis on problems such as memory leaks, excessive class loading,
and running threads. It can also be used for tuning and heap sizing.
This pane displays graphs of heap memory usage, number of threads, number of
classes, and CPU usage.
For a selected memory area (heap, non-heap, various memory pools) provides
Graph of memory usage over time
Current memory size
Amount of committed memory
Maximum memory size.
Garbage collector information, including the number of collections performed, and
the total time spent performing GC.
Graph showing percentage of heap and non-heap memory currently used.
Link to request to perform GC.
Details about Graph of thread usage over time
Live threads - Current number of live threads
Peak - Highest number of live threads since the Java VM started
For a selected thread, the name, state, and stack trace.
Button for Deadlock Detection
Graph in number of classes loaded over time.
Number of classes currently loaded into memory.
Total number of classes loaded into memory since starting of Java VM, including
those subsequently unloaded.
Total number of classes unloaded from memory since start of Java VM.
• VM Summary
General information, such as the JConsole connection data, uptime for Java VM,
CPU time consumed by Java VM, complier name and total compile time etc.
Thread and class summary information.
Memory and garbage collection information, including number of objects pending
Information about the OS, including physical characteristics, amount of virtual
memory for the running process, swap space etc.
This pane displays a tree structure showing all platform and application MBeans
that are registered in the connected JMX agent. When you select an MBean in the
tree, its attributes, operations, notifications, and other information are displayed.
JMap utility can obtain memory map information, including a heap histogram, from a Java
process, a core file, or a remote debug server.
The jmap command-line utility prints memory related statistics for a running VM or core file.
If jmap is used with a process or core file without any command-line options, then it prints
the list of shared objects loaded.
For more specific information, we can use the options -heap, -histo, or -permstat. In addition,
we can use dump:format=b,file= filename option, which causes jmap to dump the Java heap in
binary HPROF format to a specified file. This file can then be analyzed with the jhat tool.
The jstack command-line utility attaches to the specified process or core file and
prints the stack traces of all threads that are attached to the virtual machine,
including Java threads and VM internal threads, and optionally native stack frames.
The utility also performs deadlock detection.
The stack trace of all threads can be useful in diagnosing a number of issues such as
deadlocks or hangs.
The jstat utility uses the built-in instrumentation in the HotSpot VM to
provide information on performance and resource consumption of running
applications. The tool can be used when diagnosing performance issues, and in
particular issues related to heap sizing and garbage collection.
The jstatd daemon is a Remote Method Invocation (RMI) server application
that monitors the creation and termination of instrumented Java HotSpot VMs
and provides an interface to allow remote monitoring tools to attach to Java
VMs running on the local host.
The visualgc tool attaches to an instrumented HotSpot JVM and
collects and graphically displays garbage collection, class loader,
and HotSpot compiler performance data. The target JVM is
identified by its virtual machine identifier, or vmid.
• Java Heap Analysis Tool
• Parses a java heap dump and launches a web server
• Basic web interface for browsing the heap dump
• Useful for analyzing memory leaks
• View all class instances
• View class classloader
• View all references to an object
• View reference chains from Rootset
• Use OQL (Object Query Language) to query heap dumps
• SQL-like query language to query Java heap
• Built-in objects and functions
• OQL help is available from the jhat OQL screen