What is Memory Leak
and how it affects everything in your server? First, Memory Leak is not good. Memory
leaks are hard to detect especially when using frameworks or third party
library that you didn’t created. Seconds, it affects everything when you deploy
it in production environment and don’t care about memory leak until your server
is down. If you want to keep the server run 24 x 7, check for memory leak.
In Java, Garbage
Collector (GC) is your friend, it collects and handles most of the memory leak
issue by default but it still requires help from your code. The GC is just a
temporary workaround. When creating an application that use memory as storage, make
sure that you clean your own mess. Don’t depend on GC because GC sometimes it
ignores your object to be collected because GC doesn’t have a way to identify if
your application is really using the object. Memory leak usually cause when an
object in JVM are not accessible by a running thread and also caused by a Rogue
Thread.
Rogue Thread is an
unmanageable thread. No application can control it and it is caused when there
is an application running and in the middle, the application stop. Another
cause of memory leak is a Circular Reference, on my previous job, I always tell
my colleagues to make sure that they’re not doing a circular reference because
it’s like doing an infinite loop.
Lesson learned about
Memory Leak and what to do:
1.
Stress testing is
necessary if you’re application is for multithreaded.
2.
Utilize the tools
that Java JDK provided.
3.
Take care of your
code before sending it to production.
4.
NEVER EVER BLAME THE
SERVER. Server is just another folder in your windows OS.
5.
To be continued…
Basic tips for
performance:
1.
Try to minimize the
use of STATIC object.
2.
Convert “+”
concatenation into StringBuffer or StringBuilder.
3.
Understand GC.
How I search for memory leak?
Simple, use the
tools that you already have. The question is how to use it? Anyway, I listed
the approach below. Note: You must use JDK 6 or higer
HotSpotDiagnosticMXBean
ManagementFactory.getDiagnosticMXBean().dumpHeap("\temp\heapdump_apps.bin",
true);
After getting the
heapdump, use the jVisualVM to find the leak.
-XX:HeapDumpOnCtrlBreak
The
-XX:HeapDumpOnCtrlBreak option adds the hprofdump diagnostic command to the
list of commands that run automatically when the Ctrl-break keys are pressed
(similar to the print_threads diagnostic command). The HPROF dump file is
written to the location defined by the -XX:HeapDumpPath option. Add this option
when running JVM. It will create heap dump every time ctrl+break (kill -3)
signal is sent to JVM.
-XX:+HeapDumpOnOutOfMemoryError
If you application
throws an OutOfMemoryError, it will create a heap dump (.hprof file) into a binary format. You need to add –XX:HeapDumpPath
option to define the location of your heap dump file.
jMap –dump:file=.bin
jMap is the tools
that I’ve been using to generate heap dump. It comes with JDK install.
is just file name and is your
application process_id. In unix, you can get this by “ ps eaf”, in windows use
the “jps” to get the process ID.
Use jMap in the code
All you need to do
is create a simple java class and add the code to your main method.
String appName= ManagementFactory.getRuntimeMXBean().getName()String processId =
appName.substring(0, appName.indexOf("@"));String [] myCmd = {"jmap",
"-dump:file=/tmp/appHeapDump.bin", processId};Process proc = Runtime.getRuntime().exec(cmd); 