怎样用Java编写一段代码引起内存泄露

经过下面步骤可以很是easy产生内存泄露（程序代码不能訪问到某些对象，但是它们仍然保存在内存中）:java

应用程序建立一个长时间执行的线程（或者使用线程池，会更快地发生内存泄露）。
线程经过某个类载入器（可以本身定义）载入一个类。
该类分配了大块内存（比方new byte[1000000]），在某个静态变量存储一个强引用，而后在ThreadLocal中存储它自身的引用。分配额外的内存new byte[1000000]是可选的(类实例泄露已经足够了)，但是这样会使内存泄露更快。
线程清理本身定义的类或者载入该类的类载入器。
反复以上步骤。

由于没有了对类和类载入器的引用，ThreadLocal中的存储就不能被訪问到。ThreadLocal持有该对象的引用，它也就持有了这个类及其类载入器的引用，类载入器持有它所载入的类的所有引用，这样GC没法回收ThreadLocal中存储的内存。在很是多JVM的实现中Java类和类载入器直接分配到permgen区域不运行GC，这样致使了更严重的内存泄露。linux

这样的泄露模式的变种之中的一个就是假设你经常又一次部署以不论什么形式使用了ThreadLocal的应用程序、应用容器（比方Tomcat）会很是easy发生内存泄露（由于应用容器使用了如前所述的线程，每次又一次部署应用时将使用新的类载入器）。web

A2：缓存

静态变量引用对象安全

 
        1 
        class MemorableClass { 
      
        2 
            static final ArrayList list = new ArrayList(100); 
      
        3 
        }

调用长字符串的String.intern()网络

 
        1 
        String str=readString(); // read lengthy string any source db,textbox/jsp etc.. 
      
        2 
        // This will place the string in memory pool from which you cant remove 
      
        3 
        str.intern();

未关闭已打开流(文件，网络等)session

 
        1 
        try { 
      
        2 
            BufferedReader br = new BufferedReader(new FileReader(inputFile)); 
      
        3 
            ... 
      
        4 
            ... 
      
        5 
        } catch (Exception e) { 
      
        6 
            e.printStacktrace(); 
      
        7 
        }

未关闭链接app

 
        1 
        try { 
      
        2 
            Connection conn = ConnectionFactory.getConnection(); 
      
        3 
            ... 
      
        4 
            ... 
      
        5 
        } catch (Exception e) { 
      
        6 
            e.printStacktrace(); 
      
        7 
        }

JVM的GC不可达区域框架

比方经过native方法分配的内存。jsp

web应用在application范围的对象，应用未从新启动或者没有显式移除

getServletContext().setAttribute("SOME_MAP", map);

web应用在session范围的对象，未失效或者没有显式移除

session.setAttribute("SOME_MAP", map);

不对或者不合适的JVM选项

比方IBM JDK的noclassgc阻止了无用类的垃圾回收

A3：假设HashSet未正确实现(或者未实现)hashCode()或者equals(),会致使集合中持续添加�“副本”。假设集合不能地忽略掉它应该忽略的元素，它的大小就仅仅能持续增加，而且不能删除这些元素。

假设你想要生成错误的键值对，可以像如下这样作：

 
        1 
        class BadKey { 
      
        2 
           // no hashCode or equals(); 
      
        3 
           public final String key; 
      
        4 
           public BadKey(String key) { this.key = key; } 
      
        5 
        } 
      
        6 
          
        7 
        Map map = System.getProperties(); 
      
        8 
        map.put(new BadKey("key"), "value"); // Memory leak even if your threads die.

A4：除了被遗忘的监听器，静态引用，hashmap中key错误/被改动或者线程堵塞不能结束生命周期等典型内存泄露场景，如下介绍一些不太明显的Java发生内存泄露的状况，主要是线程相关的。

Runtime.addShutdownHook后没有移除，即便使用了removeShutdownHook，因为ThreadGroup类对于未启动线程的bug，它可能不被回收，致使ThreadGroup发生内存泄露。
建立但未启动线程，与上面的情形一样
建立继承了ContextClassLoader和AccessControlContext的线程，ThreadGroup和InheritedThreadLocal的使用，所有这些引用都是潜在的泄露，以及所有被类载入器载入的类和所有静态引用等等。这对ThreadFactory接口做为重要组成元素整个j.u.c.Executor框架(java.util.concurrent)的影响很是明显，很是多开发者没有注意到它潜在的危急。而且很是多库都会依照请求启动线程。
ThreadLocal缓存，很是多状况下不是好的作法。有很是多基于ThreadLocal的简单缓存的实现，但是假设线程在它的指望生命周期外继续执行ContextClassLoader将发生泄露。除非真正必要不要使用ThreadLocal缓存。
当ThreadGroup自身没有线程但是仍然有子线程组时调用ThreadGroup.destroy()。发生内存泄露将致使该线程组不能从它的父线程组移除，不能枚举子线程组。
使用WeakHashMap，value直接(间接)引用key，这是个很是难发现的情形。这也适用于继承Weak/SoftReference的类可能持有对被保护对象的强引用。
使用http(s)协议的java.net.URL下载资源。KeepAliveCache在系统ThreadGroup建立新线程，致使当前线程的上下文类载入器内存泄露。没有存活线程时线程在第一次请求时建立，因此很是有可能发生泄露。(在Java7中已经修正了，建立线程的代码合理地移除了上下文类载入器。)
使用InflaterInputStream在构造函数(比方PNGImageDecoder)中传递new java.util.zip.Inflater()，不调用inflater的end()。不过new的话很是安全，但假设本身建立该类做为构造函数參数时调用流的close()不能关闭inflater，可能发生内存泄露。这并不是真正的内存泄露因为它会被finalizer释放。但这消耗了很是多native内存，致使linux的oom_killer杀掉进程。因此这给咱们的教训是：尽量早地释放native资源。
java.util.zip.Deflater也同样，它的状况更加严重。好的地方多是很是少用到Deflater。假设本身建立了Deflater或者Inflater记住必须调用end()。