Skip to main content

Five main types of Memory leaks in java.

 There are five main types of Memory leaks in java that can cause degrade your application performance.

JNI Memory Leaks

Java Native Interface (JNI) is used to call native code from java. These memory leaks are particularly hard to find.  This native code can handle, call, and also create Java objects. Every Java object created in a native method begins its life as a local reference, which means that the object is referenced until the native method returns. In some cases you want to keep the created object even after the native call has ended. To achieve this you can either ensure that it is referenced by some other Java object or you can change the local reference into a global reference. A global reference is a GC root and will never be removed until it is explicitly freed by the native code
The only way to discover JNI memory leaks is to use a heap-dump tool that explicitly marks native references. If possible, you should not use any global references. It's better to assign the desired object to the field of a normal Java class.

Mutable Static Fields and Collections

Static fields are de facto GC roots, which means they are never garbage-collected! For convenience alone, static fields and collections are often used to hold caches or share state across threads. The sort of careless programming means that static fields and collections have become the most common cause of memory leaks!
In short, never use mutable static fields—use only constants.

Thread-Local Variables

A thread-local variable is basically a member field in the Thread class. In a multithreaded application, every thread instance has its own instance of such a variable. As threads are often pooled and thus kept alive virtually forever, the object might never be removed by the garbage collector!
Since an active thread must be considered a GC root, a thread-local variable is very similar to a static variable. The developer, more specifically his code, needs to explicitly clean it up, which goes against the idea of a garbage collector. Just like a mutable static variable, it should be avoided unless there are very few good reasons to use it.
These kinds of memory leaks can be discovered with a heap dump.

Circular and Complex Bi-Directional References

Memory leaks due to overly complex and circular object structures are my personal favorites, because it's as if they've got their own personalities. The developer seems to be trying to trick the garbage collector so that it can't do its job correctly.
I've seen this and similar cases quite often, and they are rather hard to track down. If you do not know the code  by heart (which allows you to see the problem just by reading the code), you need to do a heap analysis and figure out why the document object has not been garbage-collected.

Classloader Leaks

Especially in application servers a there is another form of memory leak: the classloader leak. As classes are referenced by their class-loaders, they get removed when the classloader is garbage-collected. That will happen only when the application gets unloaded. Consequently, there are two general forms of classloader leak:
1)Classloader Cannot Be Garbage-Collected
if an application gets unloaded but one of its objects is still being held (e.g., by a cache or a thread-local variable), the underlying classloader cannot not be removed by the garbage collector!

2)Same Class Being Loaded Again and Again
the same class is loaded repeatedly without it being in memory multiple times.

Verbose GC Log

The Verbose GC log is defined when the JVM process is started. There are a couple of switches that can be used:

-verbose:gc — prints basic information about GC to the standard output
-XX:+PrintGCTimeStamps — prints the times that GC executes
-XX:+PrintGCDetails — prints statistics about different regions of memory in the JVM
-Xloggc:<file> — logs the results of GC in the given file
 You may also like:-

How to Reduce Garbage-Collection Pause Time?

4 Mains causes of Long Garbage Collection Pause?

How Application Performance get impacted by Garbage Collection?

Java Performance Tuning options Java heap

Why Memory leak in Java ?

What is a Memory Leak in java?

What is Garbage collector in java and how it works?

What is Garbage Collector Compaction in Java?

What are Java heap Young, Old and Permanent Generations?

What is difference between Web Server and Application Server ?

What is the maximum ram for 32 bits and 64 bits computer?

Some Amazing fact about memory (petabyte,exabyte,zettabyte) And How much data exists on the Web?




Popular posts from this blog

What are Java heap Young, Old and Permanent Generations?

The Java heap is dived into two parts i.e. Young generation and old generation. Young generationYoung generation  memory is 40% of Maximum Java Heap. It consists of two parts, Eden space and Survivor Space. Eden SpaceInitially objects are created in this  Part of Java Heap , here most objects die and quickly are cleaned up by the minor Garbage Collectors (It only runs in young generation and its frequency is high in compared to major garbage collector). Usually any new objects created inside a Java Method go into Eden space and the objects space is reclaimed once the method execution completes. Whereas the Instance Variables of a Class usually lives longer until the Object based on that class gets destroyed. When Eden fills up it causes a minor collection, in which some surviving objects are moved to Survivor Space or an older generation. Survivor Space  The pool containing objects that have survived the garbage collection of the Eden space The parameter Survivor Ratio can be used to tune…

Compression of HttpServletRequest and HttpServletResponse by gzip encoding

Description 
This filter is on HTTP headers in a HttpServletRequest, compress data written to the HttpServletResponse, or decompress data read from the request. When supported by the client browser, this can potentially greatly reduce the number of bytes written across the network from and to the client. As a Filter, this class can also be easily added to any J2EE 1.3+ web application.





Installation

1).Add the pjl-comp-filter-XX.jar file containing CompressingFilter to your web application's WEB-INF/lib directory.

2).Add the following entries to your web.xml deployment descriptor:

 <filter>
  <filter-name>CompressingFilter</filter-name>
  <filter-class>com.planetj.servlet.filter.compression.CompressingFilter</filter-class>
 </filter>

 <filter-mapping>
  <filter-name>CompressingFilter</filter-name>
  <url-pattern>/*</url-pattern>
 </filter-mapping>

The below data is of my application where i tested this compression technique…

4 mains causes of Long Garbage Collection Pause?

So a long GC Pause can have a direct impact on response time and throughput. But there are some causes for long GC pause which you can check and avoid to increase performance. They are as follows:-


1)Insufficient heap size:- If heap size is small then the size required then the allocation requests for new objects  fail and the JVM needs to invoke garbage collections in an attempt to reclaim space for the allocations. So these frequent Full GCs cause long pauses in the application run. To avoid long GC pause by this identify the average footprint of the application and then specify the heap size accordingly.
2)Fragmentation in the heap:-GCs can occur more frequently due to fragmentation in the Java Heap  and also sometimes causing long pauses in the GCs. This is more probable in the case of Concurrent Mark Sweep collector, also known as CMS, where the tenured generation space is not compacted with the concurrent collections. For more please go through the previous post about heap  compact…