如何用Java编写一段代码引发内存泄露

Posted 2023-04-27

A1：通过以下步骤可以很容易产生内存泄露（程序代码不能访问到某些对象，但是它们仍然保存在内存中）:

应用程序创建一个长时间运行的线程（或者使用线程池，会更快地发生内存泄露）。
线程通过某个类加载器（可以自定义）加载一个类。
该类分配了大块内存（比如new byte[1000000]），在某个静态变量存储一个强引用，然后在ThreadLocal中存储它自身的引用。分配额外的内存new byte[1000000]是可选的(类实例泄露已经足够了)，但是这样会使内存泄露更快。
线程清理自定义的类或者加载该类的类加载器。
重复以上步骤。
由于没有了对类和类加载器的引用，ThreadLocal中的存储就不能被访问到。ThreadLocal持有该对象的引用，它也就持有了这个类及其类加载器的引用，类加载器持有它所加载的类的所有引用，这样GC无法回收ThreadLocal中存储的内存。在很多JVM的实现中Java类和类加载器直接分配到permgen区域不执行GC，这样导致了更严重的内存泄露。

这种泄露模式的变种之一就是如果你经常重新部署以任何形式使用了ThreadLocal的应用程序、应用容器（比如Tomcat）会很容易发生内存泄露（由于应用容器使用了如前所述的线程，每次重新部署应用时将使用新的类加载器）。

A2：

静态变量引用对象

class MemorableClass
static final ArrayList list = new ArrayList(100);

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

1
2
3
String str=readString(); // read lengthy string any source db,textbox/jsp etc..
// This will place the string in memory pool from which you cant remove
str.intern();
未关闭已打开流(文件，网络等)

try
BufferedReader br = new BufferedReader(new FileReader(inputFile));
...
...
catch (Exception e)
e.printStacktrace();

未关闭连接

try
Connection conn = ConnectionFactory.getConnection();
...
...
catch (Exception e)
e.printStacktrace();

JVM的GC不可达区域

比如通过native方法分配的内存。

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

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

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

session.setAttribute("SOME_MAP", map);

不正确或者不合适的JVM选项

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

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

如果你想要生成错误的键值对，可以像下面这样做：

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.
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()。 参考技术A 　　内存溢出是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于虚拟机能提供的最大内存。
所以我们应该明确：存在内存溢出的因不一定导致内存溢出的果

　　public class Know
　　public static void main(String [] args)
　　
　　int w = new Integer(args[0]).intValue();
　　int h = Integer.parseInt(args[1]);
　　
　　for(int i=0;i<h;i++)
　　
　　StringBuffer sb=new StringBuffer();
　　for(int j=0;i<w;j++)
　　
　　sb.append('*');
　　
　　System.out.println(sb.toString());
　　

　　
　　
　　这是我在网上找的一个例子，试验了一下，是对的，造成内存溢出的原因是
　　for(int j=0;i<w;j++)

sb.append('*');

　　是死循环，我原先是这么写的一个例子
　　public class Know
　　public static void main(String[] args)
　　while(true)
　　System.out.println("ok");
　　
　　
　　
　　但并没有导致内存溢出，应该是它消耗的内存比较小或者运行时间短，正如这句话所说“存在内存溢出的因不一定导致内存溢出的果”

如何用VS工具检测内存泄露

参考技术A 技术原理
检测内存泄漏的主要工具是调试器和 CRT 调试堆函数。若要启用调试堆函数，请在程序中包括以下语句：
#define CRTDBG_MAP_ALLOC
#include
#include
注意 #include 语句必须采用上文所示顺序。如果更改了顺序，所使用的函数可能无法正确工作。

通过包括 crtdbg.h，将 malloc 和 free 函数映射到其“Debug”版本_malloc_dbg 和_free_dbg，这些函数将跟踪内存分配和释放。此映射只在调试版本（在其中定义了 _DEBUG）中发生。发布版本使用普通的 malloc 和 free 函数。

#define 语句将 CRT 堆函数的基版本映射到对应的“Debug”版本。并非绝对需要该语句，但如果没有该语句，内存泄漏转储包含的有用信息将较少。

在添加了上面所示语句之后，可以通过在程序中包括以下语句来转储内存泄漏信息：
_CrtDumpMemoryLeaks();
当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“输出”窗口中显示内存泄漏信息。内存泄漏信息如下所示：
Detected memory leaks!

Dumping objects ->

C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : 18 normal block at 0x00780E80, 64 bytes long.

Data: <　　　　　　　　> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏转储如下所示：Detected memory leaks!
Dumping objects ->
18 normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

未定义 _CRTDBG_MAP_ALLOC 时，所显示的会是：

内存分配编号（在大括号内）。
块类型（普通、客户端或 CRT）。
十六进制形式的内存位置。
以字节为单位的块大小。
前 16 字节的内容（亦为十六进制）。
定义了 _CRTDBG_MAP_ALLOC 时，还会显示在其中分配泄漏的内存的文件。文件名后括号中的数字（本示例中为 20）是该文件内的行号。

转到源文件中分配内存的行

在"输出"窗口中双击包含文件名和行号的行。
-或-

在"输出"窗口中选择包含文件名和行号的行，然后按 F4 键。
_CrtSetDbgFlag

如果程序总在同一位置退出，则调用 _CrtDumpMemoryLeaks 足够方便，但如果程序可以从多个位置退出该怎么办呢？不要在每个可能的出口放置一个对 _CrtDumpMemoryLeaks 的调用，可以在程序开始包括以下调用：
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF 两个位域，如上所示。

说明
在VC++6.0的环境下，不再需要额外的添加
#define CRTDBG_MAP_ALLOC
#include
#include

只需要按F5，在调试状态下运行，程序退出后在"输出窗口"可以看到有无内存泄露。如果出现
Detected memory leaks!
Dumping objects ->

就有内存泄露。

确定内存泄露的地方
根据内存泄露的报告，有两种消除的方法：

第一种比较简单，就是已经把内存泄露映射到源文件的，可以直接在"输出"窗口中双击包含文件名和行号的行。例如
Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : 18 normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20)

就是源文件名称和行号。