在具有自己生命周期的类中随意使用非静态内部类。

在Java中，非静态内部类和匿名类对其外部类具有隐式引用。另一方面，静态内部类则不然。

下面是一个常见的Android内存泄漏示例，但这并不明显：

public class SampleActivity extends Activity {

  private final Handler mLeakyHandler = new Handler() { // Non-static inner class, holds the reference to the SampleActivity outer 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();
  }}

这将防止活动上下文被垃圾收集。

面试官可能一直在寻找一个循环参考解决方案：

    public static void main(String[] args) {
        while (true) {
            Element first = new Element();
            first.next = new Element();
            first.next.next = first;
        }
    }

这是引用计数垃圾收集器的典型问题。然后，您可以礼貌地解释JVM使用了一种更复杂的算法，它没有这种限制。

创建一个只包含while true循环的JNI函数，并用另一个线程的大型对象调用它。GC不太喜欢JNI，并且会将对象永久保存在内存中。

这是一个简单/险恶的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);
    }
}

因为子字符串指的是原始字符串的内部表示，所以原始字符串会保留在内存中。因此，只要你有一个StringLeaker在玩，你的记忆中也有整个原始字符串，即使你可能认为你只是在保存一个字符串。

避免存储对原始字符串的不需要的引用的方法如下：

...
this.muchSmallerString = new String(veryLongString.substring(0, 1));
...

为了增加坏处，您还可以.intern（）子字符串：

...
this.muchSmallerString = veryLongString.substring(0, 1).intern();
...

这样做将在内存中保留原始的长字符串和派生的子字符串，即使在StringLeaker实例被丢弃之后也是如此。

我最近遇到了一种更微妙的资源泄漏。我们通过类加载器的getResourceAsStream打开资源，但碰巧输入流句柄没有关闭。

嗯，你可能会说，真是个白痴。

嗯，有趣的是：通过这种方式，您可以泄漏底层进程的堆内存，而不是JVM的堆内存。

您只需要一个jar文件，其中包含一个将从Java代码中引用的文件。jar文件越大，分配内存的速度越快。

您可以使用以下类轻松创建这样的jar：

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<10000000 ; i++) {
            zos.write((int) (Math.round(Math.random()*100)+20));
        }
        zos.closeEntry();
        zos.close();
    }
}

只需粘贴到名为BigJarCreator.java的文件中，从命令行编译并运行它：

javac BigJarCreator.java
java -cp . BigJarCreator

等等：您在当前工作目录中找到一个jar存档，其中包含两个文件。

让我们创建第二个类：

public class MemLeak {
    public static void main(String[] args) throws InterruptedException {
        int ITERATIONS=100000;
        for (int i=0 ; i<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);
    }

}

这个类基本上什么都不做，只创建未引用的InputStream对象。这些对象将立即被垃圾收集，因此不会影响堆大小。对于我们的示例来说，从jar文件加载现有资源很重要，这里的大小很重要！

如果您有疑问，请尝试编译并启动上面的类，但确保选择了合适的堆大小（2MB）：

javac MemLeak.java
java -Xmx2m -classpath .:big.jar MemLeak

在这里您不会遇到OOM错误，因为没有保留引用，所以无论您在上面的示例中选择了多大的ITERATIONS，应用程序都将继续运行。除非应用程序执行wait命令，否则进程的内存消耗（在顶部（RES/RSS）或进程资源管理器中可见）会增加。在上面的设置中，它将分配大约150 MB的内存。

如果希望应用程序安全运行，请在创建输入流的位置关闭输入流：

MemLeak.class.getClassLoader().getResourceAsStream("resource.txt").close();

并且您的进程不会超过35MB，与迭代计数无关。

非常简单和令人惊讶。

我最近修复的一个示例是创建新的GC和Image对象，但忘记调用dispose（）方法。

GC javadoc代码段：

应用程序代码必须显式调用GC.dispose（）方法以在以下情况下释放每个实例管理的操作系统资源不再需要这些实例。这一点尤为重要在Windows95和Windows98上可用的设备上下文数。

图像javadoc片段：

应用程序代码必须显式调用Image.dispose（）方法在以下情况下释放每个实例管理的操作系统资源不再需要这些实例。