Java中内存溢出和内存泄露详解

最新推荐文章于 2024-09-19 18:19:17 发布

全栈行动派

最新推荐文章于 2024-09-19 18:19:17 发布

阅读量953

点赞数 1

分类专栏： jvm 文章标签： java jvm 内存泄露内存溢出 Powered by 金山文档

本文链接：https://blog.csdn.net/u011837804/article/details/129368743

版权

jvm 专栏收录该内容

36 篇文章 2 订阅

订阅专栏

1、内存溢出（OOM）

在程序中导致程序崩溃的两种原因有：

①、空指针、下标越界等异常，这类问题主要原因是因为代码写的有问题

②、还有一类问题是，代码看着也没有问题，在进行GC时，回收也没有空出足够的空间，报了一个OOM。

在JDK每个新版本新特性中多多少少的都会提到GC相关的内容，正是因为官方对GC的注重，GC的性能也是越来越好，到目前为止，一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现OOM的情况（这也是我们优化GC的重要关注点之一）。

大多数情况下，GC会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的Full GC操作，这时候会回收大量的内存，供应用程序继续使用。

JavaDoc中对OutOfMemoryError的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。

Java虚拟机中内存不够的原因，一般有以下几点

①、 Java虚拟机的堆内存设置不够。
比如：可能存在内存泄漏问题；也很有可能就是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显式指定JVM堆大小或者指定数值偏小。我们可以通过参数-Xms 、-Xmx来调整。

②、代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）
对于老版本的Oracle JDK，因为永久代的大小是有限的，并且JVM对永久代垃圾回收（如，常量池回收、卸载不再需要的类型）非常不积极，所以当我们不断添加新类型的时候，永久代出现OutOfMemoryError也非常多见，尤其是在运行时存在大量动态类型生成的场合；类似intern字符串缓存占用太多空间，也会导致OOM问题。对应的异常信息，会标记出来和永久代相关：“java.lang.OutOfMemoryError: PermGen space"。

随着元数据区的引入，方法区内存已经不再那么窘迫，所以相应的ooM有所改观，出现OOM，异常信息则变成了：“java.lang.OutofMemoryError:Metaspace"。直接内存不足，也会导致OOM。

这里面隐含着一层意思是，在抛出OutOfMemoryError之前，通常垃圾收集器会被触发，尽其所能去清理出空间，如果清理出的空间足够，则不会报出OOM，否则报出OOM。

例如：在引用机制分析中，涉及到JVM会去尝试回收软引用指向的对象等。

在java.nio.BIts.reserveMemory()方法中，我们能清楚的看到，System.gc()会被调用，以清理空间。

当然，也不是在任何情况下垃圾收集器都会被触发的

比如，我们去分配一个超大对象，类似一个超大数组超过堆的最大值，JVM可以判断出垃圾收集并不能解决这个问题，所以直接抛出OutOfMemoryError。

2、内存泄露

内存泄露也称作“存储渗漏”。严格来说，只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏。

但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致00M，也可以叫做宽泛意义上的“内存泄漏”。

尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现OutOfMemory异常，导致程序崩溃。

注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。

内存泄露场景：

①、静态集合类

public class StaticCollectionClass {
  private static List<String> list = new ArrayList<>();

  public static void add(String s) {
    list.add(s);
  }

  public static List<String> getList() {
    return list;
  }
}

上面这个类中的 list 是静态的，也就是说只会被实例化一次。如果在 list 中添加元素，但没有及时清空，那么这些对象将一直存在于内存中，导致内存泄漏。

解决方法：在适当的时候清空集合或者使用弱引用。

②、没有关闭文件或数据库连接

public class FileOrDbClass {
  public static void readFile(String fileName) throws IOException {
    BufferedReader br = new BufferedReader(new FileReader(fileName));
    String line;
    while ((line = br.readLine()) != null) {
      System.out.println(line);
    }
    br.close();
  }
  
  public static void getConnection() throws SQLException {
    Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
            "user=monty&password=greatsqldb");
    // 执行操作
    conn.close();
  }
}

上述代码中，readFile 方法没有关闭 BufferedReader，而 getConnection 方法也没有关闭 Connection。如果这些资源没有被适当地关闭，它们将一直存在于内存中。

解决方法：使用 try-with-resources 语句关闭资源。

③、匿名内部类

匿名内部类可能导致内存泄漏的原因是，它通常会持有外部类的引用，并且可能会长时间保持这些引用而不释放，这样就会造成内存泄漏。为了证明这一点，如下代码：

public class AnonymousClassDemo {
    private static Object obj;

    public static void main(String[] args) {
        for (int i = 0; i < 10000; i++) {
            obj = new Object() {
                @Override
                protected void finalize() throws Throwable {
                    System.out.println("Finalize method called");
                }
            };
        }
        obj = null;
        System.gc();
        System.out.println("Finish");
    }
}

在上面的代码中，创建了10000个匿名内部类对象，并在匿名内部类中重写了 finalize() 方法，以便在垃圾回收器对这些对象进行垃圾回收时输出一条消息。然后，将 obj 设置为 null，并请求垃圾回收器进行垃圾回收。

如果匿名内部类并不导致内存泄漏，那么所有的匿名内部类对象应该都会被垃圾回收器回收，并输出一条消息。但是实际情况并非如此，运行上述代码，会发现程序并没有打印出足够条数的信息。这表明，匿名内部类对象被持续引用而无法被垃圾回收器回收，从而导致内存泄漏。

运行结果：