How can I create a memory leak in Java

Question

I just had an interview  and I was asked to create a memory leak with Java  Needless to say  I felt pretty dumb having no clue on how to even start creating one  What would an example be

User · Answer

One possibility is to create a wrapper for an ArrayList that only provides one method  one that adds things to the ArrayList   Make the ArrayList itself private   Now  construct one of these wrapper objects in global scope  as a static object in a class  and qualify it with the final keyword  e g  public static final ArrayListWrapper wrapperClass   new ArrayListWrapper      So now the reference cannot be altered   That is  wrapperClass   null won t work and can t be used to free the memory   But there s also no way to do anything with wrapperClass other than add objects to it   Therefore  any objects you do add to wrapperClass are impossible to recycle

User · Answer

A common example of this in GUI code is when creating a widget component and adding a listener to some static application scoped object and then not removing the listener when the widget is destroyed  Not only do you get a memory leak  but also a performance hit as when whatever you are listening to fires events  all your old listeners are called too

User · Answer

there are many different situations memory will leak  One i encountered  which expose a map that should not be exposed and used in other place    public class ServiceFactory    private Map lt String  Service gt  services   private static ServiceFactory singleton   private ServiceFactory         services   new HashMap lt String  Service gt        public static synchronized ServiceFactory getDefault          if  singleton    null            singleton   new ServiceFactory              return singleton     public void addService String name  Service serv        services put name  serv      public void removeService String name        services remove name      public Service getService String name  Service serv        return services get name         the problematic api  which expose the map    and user can do quite a lot of thing from this api    for example  create service reference and forget to dispose or set it null   in all this is a dangerous api  and should not expose  public Map lt String  Service gt  getAllServices         return services           resource class is a heavy class class Service

User · Answer

You are able to make memory leak with sun misc Unsafe class  In fact this service class is used in different standard classes  for example in java nio classes   You can t create instance of this class directly  but you may use reflection to do that   Code doesn t compile in Eclipse IDE - compile it using command javac  during compilation you ll get warnings   import java lang reflect Constructor  import java lang reflect Field  import sun misc Unsafe    public class TestUnsafe        public static void main String   args  throws Exception          Class unsafeClass   Class forName  sun misc Unsafe            Field f   unsafeClass getDeclaredField  theUnsafe            f setAccessible true           Unsafe unsafe    Unsafe  f get null           System out print  4  3  2  1               try                       for                     unsafe allocateMemory 1024 1024             catch Error e                System out println  Boom                   e printStackTrace

User · Answer

I don t think anyone has said this yet  you can resurrect an object by overriding the finalize   method such that finalize   stores a reference of this somewhere  The garbage collector will only be called once on the object so after that the object will never destroyed

User · Answer

import sun misc Unsafe  import java lang reflect Field   public class Main       public static void main String args              try               Field f   Unsafe class getDeclaredField  quot theUnsafe quot                f setAccessible true                 Unsafe  f get null   allocateMemory 2000000000             catch  Exception e                e printStackTrace

User · Answer

A simple thing to do is to use a HashSet with an incorrect  or non-existent  hashCode   or equals    and then keep adding  duplicates    Instead of ignoring duplicates as it should  the set will only ever grow and you won t be able to remove them   If you want these bad keys elements to hang around you can use a static field like   class BadKey         no hashCode or equals       public final String key     public BadKey String key    this key   key       Map map   System getProperties    map put new BadKey  key     value       Memory leak even if your threads die

User · Answer

A few suggestions    use commons-logging in a servlet container  a bit provocative perhaps  start a thread in a servlet container and don t return from it s run method load animated gifs in a servlet container  this will start an animation thread    The above effects could be  improved  by redeploying the application     Recently stumbled upon this     Calling  new java util zip Inflater     without calling  Inflater end    ever   Read http   bugs sun com bugdatabase view bug do bug id 5072161 and linked issues for an in-depth-discussion

User · Answer

Static field holding object reference  esp final field   class MemorableClass       static final ArrayList list   new ArrayList 100       Calling String intern   on lengthy String  String str readString       read lengthy string any source db textbox jsp etc      This will place the string in memory pool from which you can t remove str intern       Unclosed  open streams   file   network etc       try       BufferedReader br   new BufferedReader new FileReader inputFile                      catch  Exception e        e printStacktrace        Unclosed connections  try       Connection conn   ConnectionFactory getConnection                      catch  Exception e        e printStacktrace        Areas that are unreachable from JVM s garbage collector  such as memory allocated through native methods  In web applications  some objects are stored in application scope until the application is explicitly stopped or removed   getServletContext   setAttribute  SOME MAP   map     Incorrect or inappropriate JVM options  such as the noclassgc option on IBM JDK that prevents unused class garbage collection   See IBM jdk settings

User · Answer

I came across a more subtle kind of resource leak recently  We open resources via class loader s getResourceAsStream and it happened that the input stream handles were not closed   Uhm  you might say  what an idiot    Well  what makes this interesting is  this way  you can leak heap memory of the underlying process  rather than from JVM s heap   All you need is a jar file with a file inside which will be referenced from Java code  The bigger the jar file  the quicker memory gets allocated   You can easily create such a jar with the following class   import java io File  import java io FileOutputStream  import java io IOException  import java util zip ZipEntry  import java util zip ZipOutputStream   public class BigJarCreator       public static void main String   args  throws IOException           ZipOutputStream zos   new ZipOutputStream new FileOutputStream new File  big jar              zos putNextEntry new ZipEntry  resource txt             zos write  not too much in here  getBytes             zos closeEntry            zos putNextEntry new ZipEntry  largeFile out             for  int i 0   i lt 10000000   i                  zos write  int   Math round Math random   100  20                      zos closeEntry            zos close              Just paste into a file named BigJarCreator java  compile and run it from command line    javac BigJarCreator java java -cp   BigJarCreator   Et voil    you find a jar archive in your current working directory with two files inside   Let s create a second class   public class MemLeak       public static void main String   args  throws InterruptedException           int ITERATIONS 100000          for  int i 0   i lt ITERATIONS   i                  MemLeak class getClassLoader   getResourceAsStream  resource txt                      System out println  finished creation of streams  now waiting to be killed             Thread sleep Long MAX VALUE              This class basically does nothing  but create unreferenced InputStream objects  Those objects will be garbage collected immediately and thus  do not contribute to heap size  It is important for our example to load an existing resource from a jar file  and size does matter here   If you re doubtful  try to compile and start the class above  but make sure to chose a decent heap size  2 MB    javac MemLeak java java -Xmx2m -classpath   big jar MemLeak   You will not encounter an OOM error here  as no references are kept  the application will keep running no matter how large you chose ITERATIONS in the above example  The memory consumption of your process  visible in top  RES RSS  or process explorer  grows unless the application gets to the wait command  In the setup above  it will allocate around 150 MB in memory   If you want the application to play safe  close the input stream right where it s created   MemLeak class getClassLoader   getResourceAsStream  resource txt   close      and your process will not exceed 35 MB  independent of the iteration count   Quite simple and surprising

User · Answer

Most examples here are  too complex   They are edge cases  With these examples  the programmer made a mistake  like don t redefining equals hashcode   or has been bitten by a corner case of the JVM JAVA  load of class with static      I think that s not the type of example an interviewer want or even the most common case   But there are really simpler cases for memory leaks  The garbage collector only frees what is no longer referenced  We as Java developers don t care about memory  We allocate it when needed and let it be freed automatically  Fine   But any long-lived application tend to have shared state  It can be anything  statics  singletons    Often non-trivial applications tend to make complex objects graphs  Just forgetting to set a reference to null or more often forgetting to remove one object from a collection is enough to make a memory leak   Of course all sort of listeners  like UI listeners   caches  or any long-lived shared state tend to produce memory leak if not properly handled  What shall be understood is that this is not a Java corner case  or a problem with the garbage collector  It is a design problem  We design that we add a listener to a long-lived object  but we don t remove the listener when no longer needed  We cache objects  but we have no strategy to remove them from the cache   We maybe have a complex graph that store the previous state that is needed by a computation  But the previous state is itself linked to the state before and so on   Like we have to close SQL connections or files  We need to set proper references to null and remove elements from the collection  We shall have proper caching strategies  maximum memory size  number of elements  or timers   All objects that allow a listener to be notified must provide both a addListener and removeListener method  And when these notifiers are no longer used  they must clear their listener list   A memory leak is indeed truly possible and is perfectly predictable  No need for special language features or corner cases  Memory leaks are either an indicator that something is maybe missing or even of design problems

User · Answer

The interviewer might have be looking for a circular reference solution       public static void main String   args            while  true                Element first   new Element                first next   new Element                first next next   first                    This is a classic problem with reference counting garbage collectors   You would then politely explain that JVMs use a much more sophisticated algorithm that doesn t have this limitation   -Wes Tarle

User · Answer

Maybe by using external native code through JNI   With pure Java  it is almost impossible   But that is about a  standard  type of memory leak  when you cannot access the memory anymore  but it is still owned by the application  You can instead keep references to unused objects  or open streams without closing them afterwards

User · Answer

Here s a simple sinister one via http   wiki eclipse org Performance Bloopers String substring 28 29   public class StringLeaker       private final String muchSmallerString       public StringLeaker                    Imagine the whole Declaration of Independence here         String veryLongString    We hold these truths to be self-evident                  The substring here maintains a reference to the internal char              representation of the original string          this muchSmallerString   veryLongString substring 0  1             Because the substring refers to the internal representation of the original  much longer string  the original stays in memory  Thus  as long as you have a StringLeaker in play  you have the whole original string in memory  too  even though you might think you re just holding on to a single-character string   The way to avoid storing an unwanted reference to the original string is to do something like this       this muchSmallerString   new String veryLongString substring 0  1          For added badness  you might also  intern   the substring       this muchSmallerString   veryLongString substring 0  1  intern          Doing so will keep both the original long string and the derived substring in memory even after the StringLeaker instance has been discarded

User · Answer

The interviewer was probably looking for a circular reference like the code below  which incidentally only leak memory in very old JVMs that used reference counting  which isn t the case any more    But it s a pretty vague question  so it s a prime opportunity to show off your understanding of JVM memory management   class A       B bRef     class B       A aRef     public class Main       public static void main String args              A myA   new A            B myB   new B            myA bRef   myB          myB aRef   myA          myA null          myB null             at this point  there is no access to the myA and myB objects                even though both objects still have active references              main        Then you can explain that with reference counting  the above code would leak memory   But most modern JVMs don t use reference counting any longer  most use a sweep garbage collector  which will in fact collect this memory   Next you might explain creating an Object that has an underlying native resource  like this   public class Main       public static void main String args              Socket s   new Socket InetAddress getByName  google com   80           s null             at this point  because you didn t close the socket properly                you have a leak of a native descriptor  which uses memory               Then you can explain this is technically a memory leak  but really the leak is caused by native code in the JVM allocating underlying native resources  which weren t freed by your Java code   At the end of the day  with a modern JVM  you need to write some Java code that allocates a native resource outside the normal scope of the JVM s awareness

User · Answer

Another way to create potentially huge memory leaks is to hold references to Map Entry lt K V gt  of a TreeMap   It is hard to asses why this applies only to TreeMaps  but by looking at the implementation the reason might be that  a TreeMap Entry stores references to its siblings  therefore if a TreeMap is ready to be collected  but some other class holds a reference to any of its Map Entry  then the entire Map will be retained into memory     Real-life scenario   Imagine having a db query that returns a big TreeMap data structure  People usually use TreeMaps as the element insertion order is retained   public static Map lt String  Integer gt  pseudoQueryDatabase      If the query was called lots of times and  for each query  so  for each Map returned  you save an Entry somewhere  the memory would constantly keep growing   Consider the following wrapper class   class EntryHolder       Map Entry lt String  Integer gt  entry       EntryHolder Map Entry lt String  Integer gt  entry            this entry   entry            Application   public class LeakTest        private final List lt EntryHolder gt  holdersCache   new ArrayList lt  gt         private static final int MAP SIZE   100 000       public void run                create 500 entries each holding a reference to an Entry of a TreeMap         IntStream range 0  500  forEach value - gt                   create map             final Map lt String  Integer gt  map   pseudoQueryDatabase                 final int index   new Random   nextInt MAP SIZE                   get random entry from map             for  Map Entry lt String  Integer gt  entry   map entrySet                      if  entry getValue   equals index                         holdersCache add new EntryHolder entry                        break                                                 to observe behavior in visualvm             try                   Thread sleep 500                 catch  InterruptedException e                    e printStackTrace                                          public static Map lt String  Integer gt  pseudoQueryDatabase             final Map lt String  Integer gt  map   new TreeMap lt  gt             IntStream range 0  MAP SIZE  forEach i - gt  map put String valueOf i   i            return map             public static void main String   args  throws Exception           new LeakTest   run              After each pseudoQueryDatabase   call  the map instances should be ready for collection  but it won t happen  as at least one Entry is stored somewhere else   Depending on your jvm settings  the application may crash in the early stage due to a OutOfMemoryError   You can see from this visualvm graph how the memory keeps growing     The same does not happen with a hashed data-structure  HashMap    This is the graph when using a HashMap     The solution  Just directly save the key   value  as you probably already do  rather than saving the Map Entry     I have written a more extensive benchmark here

User · Answer

Below there will be a non-obvious case where Java leaks  besides the standard case of forgotten listeners  static references  bogus modifiable keys in hashmaps  or just threads stuck without any chance to end their life-cycle    File deleteOnExit   - always leaks the string  if the string is a substring  the leak is even worse  the underlying char   is also leaked  - in Java nbsp 7 substring also copies the char    so the later doesn t apply   Daniel  no needs for votes  though    I ll concentrate on threads to show the danger of unmanaged threads mostly  don t wish to even touch swing    Runtime addShutdownHook and not remove    and then even with removeShutdownHook due to a bug in ThreadGroup class regarding unstarted threads it may not get collected  effectively leak the ThreadGroup  JGroup has the leak in GossipRouter  Creating  but not starting  a Thread goes into the same category as above  Creating a thread inherits the ContextClassLoader and AccessControlContext  plus the ThreadGroup and any InheritedThreadLocal  all those references are potential leaks  along with the entire classes loaded by the classloader and all static references  and ja-ja  The effect is especially visible with the entire j u c Executor framework that features a super simple ThreadFactory interface  yet most developers have no clue of the lurking danger  Also a lot of libraries do start threads upon request  way too many industry popular libraries   ThreadLocal caches  those are evil in many cases  I am sure everyone has seen quite a bit of simple caches based on ThreadLocal  well the bad news  if the thread keeps going more than expected the life the context ClassLoader  it is a pure nice little leak  Do not use ThreadLocal caches unless really needed  Calling ThreadGroup destroy   when the ThreadGroup has no threads itself  but it still keeps child ThreadGroups  A bad leak that will prevent the ThreadGroup to remove from its parent  but all the children become un-enumerateable  Using WeakHashMap and the value  in directly references the key  This is a hard one to find without a heap dump  That applies to all extended Weak SoftReference that might keep a hard reference back to the guarded object  Using java net URL with the HTTP S  protocol and loading the resource from     This one is special  the KeepAliveCache creates a new thread in the system ThreadGroup which leaks the current thread s context classloader  The thread is created upon the first request when no alive thread exists  so either you may get lucky or just leak  The leak is already fixed in Java nbsp 7 and the code that creates thread properly removes the context classloader  There are few more cases  like ImageFetcher  also fixed  of creating similar threads  Using InflaterInputStream passing new java util zip Inflater   in the constructor  PNGImageDecoder for instance  and not calling end   of the inflater  Well  if you pass in the constructor with just new  no chance    And yes  calling close   on the stream does not close the inflater if it s manually passed as constructor parameter  This is not a true leak since it d be released by the finalizer    when it deems it necessary  Till that moment it eats native memory so badly it can cause Linux oom killer to kill the process with impunity  The main issue is that finalization in Java is very unreliable and G1 made it worse till 7 0 2  Moral of the story  release native resources as soon as you can  the finalizer is just too poor  The same case with java util zip Deflater  This one is far worse since Deflater is memory hungry in Java  i e  always uses 15 nbsp bits  max  and 8 nbsp memory levels  9 is max  allocating several hundreds KB of native memory  Fortunately  Deflater is not widely used and to my knowledge JDK contains no misuses  Always call end   if you manually create a Deflater or Inflater  The best part of the last two  you can t find them via normal profiling tools available     I can add some more time wasters I have encountered upon request    Good luck and stay safe  leaks are evil

User · Answer

Just like this   public static void main String   args        List lt Object gt  objects   new ArrayList lt  gt         while true            objects add new Object

User · Answer

The answer depends entirely on what the interviewer thought they were asking    Is it possible in practice to make Java leak  Of course it is  and there are plenty of examples in the other answers   But there are multiple meta-questions that may have been being asked    Is a theoretically  perfect  Java implementation vulnerable to leaks  Does the candidate understand the difference between theory and reality  Does the candidate understand how garbage collection works  Or how garbage collection is supposed to work in an ideal case  Do they know they can call other languages through native interfaces  Do they know to leak memory in those other languages  Does the candidate even know what memory management is  and what is going on behind the scene in Java    I m reading your meta-question as  What s an answer I could have used in this interview situation   And hence  I m going to focus on interview skills instead of Java  I believe you re more likely to repeat the situation of not knowing the answer to a question in an interview than you are to be in a place of needing to know how to make Java leak  So  hopefully  this will help   One of the most important skills you can develop for interviewing is learning to actively listen to the questions and working with the interviewer to extract their intent  Not only does this let you answer their question the way they want  but also shows that you have some vital communication skills  And when it comes down to a choice between many equally talented developers  I ll hire the one who listens  thinks  and understands before they respond every time

User · Answer

As a lot of people have suggested  Resource Leaks are fairly easy to cause - like the JDBC examples  Actual Memory leaks are a bit harder - especially if you aren t relying on broken bits of the JVM to do it for you     The ideas of creating objects that have a very large footprint and then not being able to access them aren t real memory leaks either  If nothing can access it then it will be garbage collected  and if something can access it then it s not a leak     One way that used to work though - and I don t know if it still does - is to have a three-deep circular chain  As in Object A has a reference to Object B  Object B has a reference to Object C and Object C has a reference to Object A  The GC was clever enough to know that a two deep chain - as in A  lt --  B - can safely be collected if A and B aren t accessible by anything else  but couldn t handle the three-way chain

User · Answer

Any time you keep references around to objects that you no longer need you have a memory leak   See Handling memory leaks in Java programs for examples of how memory leaks manifest themselves in Java and what you can do about it

User · Answer

Take any web application running in any servlet container  Tomcat  Jetty  Glassfish  whatever      Redeploy the app 10 or 20 times in a row  it may be enough to simply touch the WAR in the server s autodeploy directory   Unless anybody has actually tested this  chances are high that you ll get an OutOfMemoryError after a couple of redeployments  because the application did not take care to clean up after itself  You may even find a bug in your server with this test   The problem is  the lifetime of the container is longer than the lifetime of your application  You have to make sure that all references the container might have to objects or classes of your application can be garbage collected   If there is just one reference surviving the undeployment of your web app  the corresponding classloader and by consequence all classes of your web app cannot be garbage collected   Threads started by your application  ThreadLocal variables  logging appenders are some of the usual suspects to cause classloader leaks

User · Answer

Create a JNI function containing just a while-true loop and call it with a large object from another thread  The GC doesn t like JNI very much and is going to keep the object in memory forever

User · Answer

Most of the memory leaks I ve seen in java concern processes getting out of sync   Process A talks to B via TCP  and tells process B to create something  B issues the resource an ID  say 432423  which A stores in an object and uses while talking to B  At some point the object in A is reclaimed by garbage collection  maybe due to a bug   but A never tells B that  maybe another bug    Now A doesn t have the ID of the object it s created in B s RAM any more  and B doesn t know that A has no more reference to the object  In effect  the object is leaked

User · Answer

Carelessly Using a non-static inner Class inside a class who has its own life cycle   In Java  non-static inner and anonymous classes hold an implicit reference to their outer class  Static inner classes  on the other hand  do not   Here is a common example to have memory leak in Android which is not obvious though   public class SampleActivity extends Activity      private final Handler mLeakyHandler   new Handler       non-static inner class  holds the reference to the SampleActivity outter class      Override     public void handleMessage Message msg                               Override   protected void onCreate Bundle savedInstanceState        super onCreate savedInstanceState           Post a message and delay its execution for a long time      mLeakyHandler postDelayed new Runnable      here  the anonymous inner class holds the reference to the SampleActivity class too        Override       public void run                                 SOME TOME TIME           Go back to the previous Activity      finish           This will prevent the activity context from being garbage collected

User · Answer

What s a memory leak    It s caused by a bug or bad design  It s a waste of memory  It gets worse over time  The garbage collector cannot clean it    Typical example   A cache of objects is a good starting point to mess things up   private static final Map lt String  Info gt  myCache   new HashMap lt  gt      public void getInfo String key           uses cache     Info info   myCache get key       if  info    null  return info          if it s not in cache  then fetch it from the database     info   Database fetch key       if  info    null  return null          and store it in the cache     myCache put key  info       return info      Your cache grows and grows  And pretty soon the entire database gets sucked into memory  A better design uses an LRUMap  Only keeps recently used objects in cache    Sure  you can make things a lot more complicated     using ThreadLocal constructions  adding more complex reference trees   or leaks caused by 3rd party libraries    What often happens    If this Info object has references to other objects  which again have references to other objects  In a way you could also consider this to be some kind of memory leak   caused by bad design

User · Answer

I thought it was interesting that no one used the internal class examples   If you have an internal class  it inherently maintains a reference to the containing class   Of course it is not technically a memory leak because Java WILL eventually clean it up  but this can cause classes to hang around longer than anticipated   public class Example1     public Example2 getNewExample2         return this new Example2          public class Example2       public Example2              Now if you call Example1 and get an Example2 discarding Example1  you will inherently still have a link to an Example1 object   public class Referencer     public static Example2 GetAnExample2         Example1 ex   new Example1        return ex getNewExample2           public static void main String   args        Example2 ex   Referencer GetAnExample2           As long as ex is reachable  Example1 will always remain in memory          I ve also heard a rumor that if you have a variable that exists for longer than a specific amount of time  Java assumes that it will always exist and will actually never try to clean it up if cannot be reached in code anymore   But that is completely unverified

User · Answer

A thread that does not terminate  say sleeps indefinitely in its run method   It will not be garbage collected even if we loose a reference to it  You can add fields to make the thread object is a big as you want   The currently top answer lists more tricks around this but these seem redundant

User · Answer

a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in such a way that memory which is no longer needed is not released    wiki definition     It s kind of relatively context-based topic  you can just create one based on your taste as long as the unused references will never be used by clients but still stay alive   The first example should be a custom stack without nulling the obsolete references in effective java item 6   Of course there are many more as long as you want  but if we just take look at the java built-in classes  it could be some as  subList    Let s check some super silly code to produce the leak    public class MemoryLeak       private static final int HUGE SIZE   10 000       public static void main String    args            letsLeakNow               private static void letsLeakNow             Map lt Integer  Object gt  leakMap   new HashMap lt  gt             for  int i   0  i  lt  HUGE SIZE    i                leakMap put i   2  getListWithRandomNumber                            private static List lt Integer gt  getListWithRandomNumber             List lt Integer gt  originalHugeIntList   new ArrayList lt  gt             for  int i   0  i  lt  HUGE SIZE    i                originalHugeIntList add new Random   nextInt                       return originalHugeIntList subList 0  1             Actually there is another trick we can cause memory leak using HashMap by taking advantage of its looking process  There are actually two types    hashCode   is always the same but equals   are different  use random hashCode   and equals   always true    Why   hashCode   -  bucket    equals   to locate the pair    I was about to mention substring   first and then subList   but it seems this issue is already fixed as its source presents in JDK 8    public String substring int beginIndex  int endIndex        if  beginIndex  lt  0            throw new StringIndexOutOfBoundsException beginIndex             if  endIndex  gt  value length            throw new StringIndexOutOfBoundsException endIndex             int subLen   endIndex - beginIndex      if  subLen  lt  0            throw new StringIndexOutOfBoundsException subLen             return   beginIndex    0   amp  amp   endIndex    value length     this               new String value  beginIndex  subLen

User · Answer

If Max heap size is X   Y1    Yn  no of instances  So total memory  number of instances X Bytes per instance If X1      Xn is bytes per instances Then total memory M  Y1   X1       Yn  Xn  So if M X  it exceeds heap space    following can be  the   problems in code  1 Use of more instances variable then local one  2 Creating instances every time instead of pooling object  3 Not Creating the object on demand  4 Making the object reference null after the completion of operation Again  recreating when it is demanded in program

User · Answer

I think that a valid example could be using ThreadLocal variables in an environment where threads are pooled    For instance  using ThreadLocal variables in Servlets to communicate with other web components  having the threads being created by the container and maintaining the idle ones in a pool  ThreadLocal variables  if not correctly cleaned up  will live there until  possibly  the same web component overwrites their values   Of course  once identified  the problem can be solved easily

User · Answer

One of the java memory leakings examples is MySQLs memory leaking bug resulting when ResultSets close method is forgotten to be called  For example   while true        ResultSet rs   database select query                  going to next step of loop and leaving resultset without calling rs close

User · Answer

One of the easiest way to implement memory leak sample is to use static method   For example  static List lt int gt  list   new ArrayList lt  gt     for  int i   0  i  lt  10000  i          list add i      system sleep      In this case  jvm can t release the memory of list  cuz it s a static class and it always remains memory on heap

User · Answer

A memory leak in java is not your typical C C   memory leak   To understand how the JVM works  read the Understanding Memory Management   Basically  the important part is      The Mark and Sweep Model      The JRockit JVM uses the mark and sweep garbage collection model for   performing garbage collections of the whole heap  A mark and sweep   garbage collection consists of two phases  the mark phase and the   sweep phase       During the mark phase all objects that are reachable from Java   threads  native handles and other root sources are marked as alive  as   well as the objects that are reachable from these objects and so   forth  This process identifies and marks all objects that are still   used  and the rest can be considered garbage       During the sweep phase the heap is traversed to find the gaps between   the live objects  These gaps are recorded in a free list and are made   available for new object allocation       The JRockit JVM uses two improved versions of the mark and sweep   model  One is mostly concurrent mark and sweep and the other is   parallel mark and sweep  You can also mix the two strategies  running   for example mostly concurrent mark and parallel sweep    So  to create a memory leak in Java  the easiest way to do that is to create a database connection  do some work  and simply not Close   it  then generate a new database connection while staying in scope  This isn t hard to do in a loop for example  If you have a worker that pulls from a queue and pushes to a database you can easily create a memory leak by forgetting to Close   connections or opening them when not necessary  and so forth   Eventually  you ll consume the heap that has been allocated to the JVM by forgetting to Close   the connection  This will result in the JVM garbage collecting like crazy  eventually resulting in java lang OutOfMemoryError  Java heap space errors  It should be noted that the error may not mean there is a memory leak  it could just mean you don t have enough memory  databases like Cassandra and ElasticSearch for example can throw that error because they don t have enough heap space   Its worth noting that this is true for all GC languages  Below  are some examples I ve seen working as an SRE    Node using Redis as a queue  the development team created new connections every 12 hours and forgot to close the old ones  Eventually node was OOMd because it consumed all the memory  Golang  I m guilty of this one   parsing large json files with json Unmarshal and then passing the results by reference and keeping them open  Eventually  this resulted in the entire heap being consumed by accidental refs I kept open to decode json

User · Answer

A real time example of memory leak before JDK 1 7  suppose you read a file of 1000 lines of text and keep in String object  String fileText   1000 characters from file  fileText   fileText subString 900  fileText length       In above code I initially read 1000 char and then did substring to get only 100 last characters  Now fileText should only refer to 100 chars and all other characters should get garbage collected as I lost the reference but before JDK 1 7 substring function indirectly refer to original string of last 100 chars and prevents whole string from garbage collection and whole 1000 chars will be there in memory until you loose reference of substring   you can create memory leak example like the above

User · Answer

Probably one of the simplest examples of a potential memory leak  and how to avoid it  is the implementation of ArrayList remove int   public E remove int index        RangeCheck index        modCount        E oldValue    E  elementData index        int numMoved   size - index - 1      if  numMoved  gt  0          System arraycopy elementData  index   1  elementData  index                  numMoved       elementData --size    null         Let gc do its work      return oldValue     If you were implementing it yourself  would you have thought to clear the array element that is no longer used  elementData --size    null   That reference might keep a huge object alive

User · Answer

Here is a very simple Java program that will run out of space  public class OutOfMemory        public static void main String   arg             List lt Long gt  mem   new LinkedList lt Long gt             while  true                mem add new Long Long MAX VALUE

User · Answer

You can create a moving memory leak by creating a new instance of a class in that class s finalize method  Bonus points if the finalizer creates multiple instances  Here s a simple program that leaks the entire heap in sometime between a few seconds and a few minutes depending on your heap size   class Leakee       public void check             if  depth  gt  2                Leaker done                        private int depth      public Leakee int d            depth   d            protected void finalize             new Leakee depth   1  check            new Leakee depth   1  check             public class Leaker       private static boolean makeMore   true      public static void done             makeMore   false            public static void main String   args  throws InterruptedException              make a bunch of them until the garbage collector gets active         while  makeMore                new Leakee 0  check                         sit back and watch the finalizers chew through memory         while  true                Thread sleep 1000               System out println  memory                         Runtime getRuntime   freeMemory                                 Runtime getRuntime   totalMemory

User · Answer

I want to give an advice on how to monitor application for the memory leaks with the tools that are available in JVM  It doesn t show how to generate the memory leak but explains how to detect it with minimum tools available   You need to monitor Java memory consumption first   The simplest way to do this is to use jstat utility that comes with JVM   jstat -gcutil  lt process id gt   lt timeout gt    It will report memory consumption for each generation  Young  Eldery and Old  and garbage collection times  Young and Full    As soon as you spot that Full Garbage Collection is executed too often and takes too much time  you can assume that application is leaking memory   Then you need to create a memory dump using jmap utility   jmap -dump live format b file heap bin  lt process id gt    Then you need to analyse heap bin file with Memory Analyser  Eclipse Memory Analyzer  MAT  for example   MAT will analyze the memory and provide you suspect information about memory leaks

User · Answer

Create a static Map and keep adding hard references to it   Those will never be garbage collected  public class Leaker       private static final Map lt String  Object gt  CACHE   new HashMap lt String  Object gt             Keep adding until failure      public static void addToCache String key  Object value    Leaker CACHE put key  value

User · Answer

There s no such thing as a memory leak in Java  Memory leak is a phrase borrowed from C et al  Java deals with memory allocation internally with the help of the GC  There s memory wastefulness  ie  leaving stranded objects   but not memory leak

User · Answer

In Java a  memory leak  is primarily just you using too much memory which is different than in C where you are no longer using the memory but forget to return  free  it  When an interviewer asks about Java memory leaks they are asking about JVM memory usage just appearing to keep going up and they determined that restarting the JVM on a regular basis is the best fix   unless the interviewer is extremely technically savvy   So answer this question as if they asked what makes JVM memory usage grow over time  Good answers would be storing too much data in a HttpSessions with overly long timeout or a poorly implemented in-memory cache  Singleton  that never flushes old entries  Another potential answer is having lots of JSPs or dynamically generated classes  Classes are loaded into an area of memory called PermGen that is usually small and most JVMs don t implement class unloading

User · Answer

The following is a pretty pointless example  if you do not understand JDBC  Or at least how JDBC expects a developer to close Connection  Statement and ResultSet instances before discarding them or losing references to them  instead of relying on the implementation of finalize   void doWork        try             Connection conn   ConnectionFactory getConnection           PreparedStatement stmt   conn preparedStatement  some query       executes a valid query        ResultSet rs   stmt executeQuery           while rs hasNext                           process the result set                  catch SQLException sqlEx              log sqlEx            The problem with the above is that the Connection object is not closed  and hence the physical connection will remain open  until the garbage collector comes around and sees that it is unreachable  GC will invoke the finalize method  but there are JDBC drivers that do not implement the finalize  at least not in the same way that Connection close is implemented  The resulting behavior is that while memory will be reclaimed due to unreachable objects being collected  resources  including memory  associated with the Connection object might simply not be reclaimed   In such an event where the Connection s finalize method does not clean up everything  one might actually find that the physical connection to the database server will last several garbage collection cycles  until the database server eventually figures out that the connection is not alive  if it does   and should be closed   Even if the JDBC driver were to implement finalize  it is possible for exceptions to be thrown during finalization  The resulting behavior is that any memory associated with the now  dormant  object will not be reclaimed  as finalize is guaranteed to be invoked only once   The above scenario of encountering exceptions during object finalization is related to another other scenario that could possibly lead to a memory leak - object resurrection  Object resurrection is often done intentionally by creating a strong reference to the object from being finalized  from another object  When object resurrection is misused it will lead to a memory leak in combination with other sources of memory leaks   There are plenty more examples that you can conjure up - like   Managing a List instance where you are only adding to the list and not deleting from it  although you should be getting rid of elements you no longer need   or Opening Sockets or Files  but not closing them when they are no longer needed  similar to the above example involving the Connection class   Not unloading Singletons when bringing down a Java EE application  Apparently  the Classloader that loaded the singleton class will retain a reference to the class  and hence the singleton instance will never be collected  When a new instance of the application is deployed  a new class loader is usually created  and the former class loader will continue to exist due to the singleton

User · Answer

There are many good examples of memory leaks in Java  and I will mention two of them in this answer  Example 1  Here is a good example of a memory leak from the book Effective Java  Third Edition  item 7  Eliminate obsolete object references      Can you spot the  quot memory leak quot   public class Stack       private static final int DEFAULT INITIAL CAPACITY   16      private Object   elements      private int size   0       public Stack             elements   new Object DEFAULT INITIAL CAPACITY              public void push Object e            ensureCapacity            elements size      e             public Object pop             if  size    0  throw new EmptyStackException            return elements --size                   Ensure space for at least one more element  roughly  doubling the capacity each time the array needs to grow        private void ensureCapacity             if  elements length    size  elements   Arrays copyOf elements  2   size   1            This is the paragraph of the book that describe why this implementation will cause a memory leak   If a stack grows and then shrinks  the objects that were popped off the stack will not be garbage collected  even if the program using  the stack  has  no  more  references  to  them   This  is  because  the stack  maintains obsolete references to these objects  An obsolete reference is simply a reference that will never be dereferenced again  In this case  any references outside of the    active portion    of the element array are obsolete  The active portion consists of the elements whose index is less than size  Here is the solution of the book to tackle this memory leak   The  fix  for  this  sort  of  problem  is  simple   null  out references  once  they become obsolete  In the case of our Stack class  the reference to an item becomes obsolete  as  soon  as  it   s  popped off  the  stack  The  corrected  version  of  the  pop method looks like this   public Object pop         if  size    0  throw new EmptyStackException        Object result   elements --size       elements size    null     Eliminate obsolete reference     return result     But how can we prevent a memory leak from happening  This is a good caveat from the book   Generally  speaking   whenever  a  class  manages  its  own  memory  the  programmer should be alert for memory leaks  Whenever an element is freed  any object references contained in the element should be nulled out   Example 2  The observer pattern also can cause a memory leak  You can read about this pattern in the following link  Observer pattern  This is one implementation of Observer pattern  class EventSource       public interface Observer           void update String event              private final List lt Observer gt  observers   new ArrayList lt  gt          private void notifyObservers String event            observers forEach observer - gt  observer update event      alternative lambda expression  observers forEach Observer  update              public void addObserver Observer observer            observers add observer              public void scanSystemIn             Scanner scanner   new Scanner System in           while  scanner hasNextLine                  String line   scanner nextLine                notifyObservers line                      In this implementation  EventSource  which is Observable in Observer design pattern  can hold link to Obeserver objects  but this link is never removed from the observers field in EventSource  So they will never be collected by the garbage collector  One solution to tackle this problem is providing another method to client for removing the aforementioned observers from observers field when they don t need those observers any more  public void removeObserver Observer observer        observers remove observer

User · Answer

Everyone always forgets the native code route   Here s a simple formula for a leak    Declare native method  In native method  call malloc   Don t call free  Call the native method    Remember  memory allocations in native code come from the JVM heap

User · Answer

Theoretically you can t  Java memory model prevents it  However  because Java has to be implemented  there are some caveats you can use  Depends on what you can use    If you can use native  you can allocate memory that you don not relinquish later   If that is not available  there is a dirty little secret about java that not much people know  You can ask for a direct access array that is not managed by GC  and therefor can be easily used to make a memory leak  This is provided by DirectByteBuffer  http   download oracle com javase 1 5 0 docs api java nio ByteBuffer html allocateDirect int     If you can t use any of those  you still can make a memory leak by tricking the GC  The JVM is implemented using a Generational garbage collection  What this means is that the heap is divided into areas  young  adults and elders  An object when its created starts at the young area  As he is used more and more  he progresses into adults up to elders  An object that reaches the eldery area most likely will not be garbaged collected  You cannot be sure that an object is leaked and if you ask for a stop and clean GC it may clean it but for a long period of time he will be leaked  More info at  http   java sun com docs hotspot gc1 4 2 faq html   Also  class objects are not required to be GC ed  Might me a way to do it

User · Answer

Lapsed Listerners is a good example of memory leaks  Object is added as a Listener  All references to the object are nulled when the object is not needed anymore  However  forgetting to remove the object from the Listener list keeps the object alive and even responding to events  thereby wasting both memory and CPU  See http   www drdobbs com jvm java-qa 184404011

User · Answer

Swing has it very easy with dialogs  Create a JDialog  show it  the user closes it  leak  You have to call dispose   or configure setDefaultCloseOperation DISPOSE ON CLOSE

User · Answer

Here s a good way to create a true memory leak  objects inaccessible by running code but still stored in memory  in pure Java    The application creates a long-running thread  or use a thread pool to leak even faster   The thread loads a class via an  optionally custom  ClassLoader  The class allocates a large chunk of memory  e g  new byte 1000000    stores a strong reference to it in a static field  and then stores a reference to itself in a ThreadLocal   Allocating the extra memory is optional  leaking the class instance is enough   but it will make the leak work that much faster  The application clears all references to the custom class or the ClassLoader it was loaded from  Repeat    Due to the way ThreadLocal is implemented in Oracle s JDK  this creates a memory leak    Each Thread has a private field threadLocals  which actually stores the thread-local values  Each key in this map is a weak reference to a ThreadLocal object  so after that ThreadLocal object is garbage-collected  its entry is removed from the map  But each value is a strong reference  so when a value  directly or indirectly  points to the ThreadLocal object that is its key  that object will neither be garbage-collected nor removed from the map as long as the thread lives    In this example  the chain of strong references looks like this   Thread object   threadLocals map   instance of example class   example class   static ThreadLocal field   ThreadLocal object    The ClassLoader doesn t really play a role in creating the leak  it just makes the leak worse because of this additional reference chain  example class   ClassLoader   all the classes it has loaded  It was even worse in many JVM implementations  especially prior to Java 7  because classes and ClassLoaders were allocated straight into permgen and were never garbage-collected at all    A variation on this pattern is why application containers  like Tomcat  can leak memory like a sieve if you frequently redeploy applications which happen to use ThreadLocals that in some way point back to themselves  This can happen for a number of subtle reasons and is often hard to debug and or fix   Update  Since lots of people keep asking for it  here s some example code that shows this behavior in action

User · Answer

Threads are not collected until they terminate  They serve as roots of garbage collection  They are one of the few objects that won t be reclaimed simply by forgetting about them or clearing references to them   Consider  the basic pattern to terminate a worker thread is to set some condition variable seen by the thread  The thread can check the variable periodically and use that as a signal to terminate  If the variable is not declared volatile  then the change to the variable might not be seen by the thread  so it won t know to terminate  Or imagine if some threads want to update a shared object  but deadlock while trying to lock on it   If you only have a handful of threads these bugs will probably be obvious because your program will stop working properly  If you have a thread pool that creates more threads as needed  then the obsolete stuck threads might not be noticed  and will accumulate indefinitely  causing a memory leak  Threads are likely to use other data in your application  so will also prevent anything they directly reference from ever being collected   As a toy example   static void leakMe final Object object        new Thread             public void run                 Object o   object              for                        try                       sleep Long MAX VALUE                     catch  InterruptedException e                                   start        Call System gc   all you like  but the object passed to leakMe will never die     edited

User · Answer

I recently encountered a memory leak situation caused in a way by log4j   Log4j has this mechanism called Nested Diagnostic Context NDC   which is an instrument to distinguish interleaved log output from different sources  The granularity at which NDC works is threads  so it distinguishes log outputs from different threads separately   In order to store thread specific tags  log4j s NDC class uses a Hashtable which is keyed by the Thread object itself  as opposed to say the thread id   and thus till the NDC tag stays in memory all the objects that hang off of the thread object also stay in memory  In our web application we use NDC to tag logoutputs with a request id to distinguish logs from a single request separately  The container that associates the NDC tag with a thread  also removes it while returning the response from a request  The problem occurred when during the course of processing a request  a child thread was spawned  something like the following code   pubclic class RequestProcessor       private static final Logger logger   Logger getLogger RequestProcessor class       public void doSomething                           final List lt String gt  hugeList   new ArrayList lt String gt  10000           new Thread                public void run                    logger info  Child thread spawned                  for String s hugeList                                                                    start                  So an NDC context was associated with inline thread that was spawned  The thread object that was the key for this NDC context  is the inline thread which has the hugeList object hanging off of it  Hence even after the thread finished doing what it was doing  the reference to the hugeList was kept alive by the NDC context Hastable  thus causing a memory leak

User · Answer

There are many answers on how to create a memory leak in Java  but please note the point asked during the interview    how to create a memory leak with Java   is an open-ended question  whose purpose is to evaluate the degree of experience a developer has   If I ask you  Do you have experience troubleshooting memory leaks in Java    your answer would be a simple  Yes   I would have then to follow up with  Could you give me examples where you hat to troubleshoot memory leaks    to which you would give me one or two examples   However  when the interviewer asks  how to create a memory leak with Java   the expected answer should follow alongs these lines    I ve encountered a memory leak      say when   that shows me experience  The code that was causing it was     explain code   you fixed it yourself  The fix I applied was based on      explain fix   this gives me a chance to ask specifics about the fix  The test I did was      gives me the chance of asking other testing methodologies  I documented it this way      extra points  Good if you documented it  So  it is reasonable to think that  if we follow this in reverse order  which is  get the code I fixed  and remove my fix  that we would have a memory leak    When the developer fails to follow this line of thought I try to guide him her asking  Could you give me an example of how could Java leak memory    followed by  Did you ever have to fix any memory leak in Java    Note that I am not asking for an example on how to leak memory in Java  That would be silly  Who would be interested in a developer who can effectively write code that leaks memory

User · Answer

I can copy my answer from here  Easiest way to cause memory leak in Java    A memory leak  in computer science  or leakage  in this context   occurs when a computer program consumes memory but is unable to release it back to the operating system    Wikipedia   The easy answer is  You can t  Java does automatic memory management and will free resources that are not needed for you  You can t stop this from happening  It will ALWAYS be able to release the resources  In programs with manual memory management  this is different  You cann get some memory in C using malloc    To free the memory  you need the pointer that malloc returned and call free   on it  But if you don t have the pointer anymore  overwritten  or lifetime exceeded   then you are unfortunately incapable of freeing this memory and thus you have a memory leak   All the other answers so far are in my definition not really memory leaks  They all aim at filling the memory with pointless stuff real fast  But at any time you could still dereference the objects you created and thus freeing the memory --  NO LEAK  acconrad s answer comes pretty close though as I have to admit since his solution is effectively to just  crash  the garbage collector by forcing it in an endless loop    The long answer is  You can get a memory leak by writing a library for Java using the JNI  which can have manual memory management and thus have memory leaks  If you call this library  your java process will leak memory  Or  you can have bugs in the JVM  so that the JVM looses memory  There are probably bugs in the JVM  there may even be some known ones since garbage collection is not that trivial  but then it s still a bug  By design this is not possible  You may be asking for some java code that is effected by such a bug  Sorry I don t know one and it might well not be a bug anymore in the next Java version anyway

User · Answer

String substring method in java 1 6 create a memory leak  This blog post explains it   http   javarevisited blogspot com 2011 10 how-substring-in-java-works html

User · Answer

Throw an unhandled exception from the finalize method

User · Answer

An example I recently fixed is creating new GC and Image objects  but forgetting to call dispose   method   GC javadoc snippet      Application code must explicitly invoke the GC dispose   method to   release the operating system resources managed by each instance when   those instances are no longer required  This is particularly important   on Windows95 and Windows98 where the operating system has a limited   number of device contexts available    Image javadoc snippet      Application code must explicitly invoke the Image dispose   method to   release the operating system resources managed by each instance when   those instances are no longer required

User · Answer

If you don t use a compacting garbage collector  you can have some sort of a memory leak due to heap fragmentation

User · Answer

I have had a nice  memory leak  in relation to PermGen and XML parsing once  The XML parser we used  I can t remember which one it was  did a String intern   on tag names  to make comparison faster  One of our customers had the great idea to store data values not in XML attributes or text  but as tagnames  so we had a document like    lt data gt      lt 1 gt bla lt  1 gt      lt 2 gt foo lt   gt          lt  data gt    In fact  they did not use numbers but longer textual IDs  around 20 characters   which were unique and came in at a rate of 10-15 million a day  That makes 200 nbsp MB of rubbish a day  which is never needed again  and never GCed  since it is in PermGen   We had permgen set to 512 nbsp MB  so it took around two days for the out-of-memory exception  OOME  to arrive

User · Answer

From effective java book    whenever a class manages its own memory  the programmer should be alert for memory leaks      public class Stack   private Object   elements  private int size   0  private static final int DEFAULT INITIAL CAPACITY   16   public Stack         elements   new Object DEFAULT INITIAL CAPACITY      public void push Object e        ensureCapacity        elements size      e     public Object pop         if  size    0          throw new EmptyStackException        return elements --size             Ensure space for at least one more element  roughly doubling the capacity    each time the array needs to grow      private void ensureCapacity         if  elements length    size          elements   Arrays copyOf elements  2   size   1          Can you spot the memory leak  So where is the memory leak  If a stack grows and then shrinks  the objects that were popped off the stack will not be garbage collected  even if the program using the stack has no more references to them  This is because the stack maintains obsolete references to these objects  An obsolete reference is simply a reference that will never be dereferenced again  In this case  any references outside of the    active portion    of the element array are obsolete  The active portion consists of the elements whose index is less than size

[java] How can I create a memory leak in Java?

Examples related to java

Examples related to memory

Examples related to memory-leaks