7

我遇到了一个错误，我们的一个服务器应用程序几乎每秒使用越来越多的内存，我设法过滤掉一个仍然显示该行为的简短示例：

public class TestGetLastModifiedTime {
    private static final Path PATH = Paths.get("D:\\test.txt");
    private static final ScheduledExecutorService SCHEDULER = Executors.newScheduledThreadPool(1);

    public static void main(String[] args) {
        SCHEDULER.scheduleAtFixedRate(() -> getLastModifiedTime(), 0, 1, TimeUnit.SECONDS);
    }

    private static void getLastModifiedTime() {
        try {
            FileTime lastModifiedTime = Files.getLastModifiedTime(PATH);
        } catch (IOException ex) {
            throw new UncheckedIOException(ex);
        }
    }
}

在 Windows 8.1 和 Java 8u20 上运行。

通过 VisualVM，我观察到最大堆大小没有增长，并且堆本身不断增加。同时我在 Windows 任务管理器中观察到生成的 java.exe 进程每秒继续使用（保留）更多内存。

有趣的是，当我在 VisualVM 中执行 GC时，所有使用的堆内存都被重置为几乎为零，并且 java.exe 进程的使用内存不会像预期的那样缩小，因为它被认为是保留的。

但是，在 GC 完成后，内存使用量仍然每秒增加，而现在肯定有足够的可用堆空间。

元空间也不受影响。

对我来说，这真的很难闻，看起来 JVM 有内存泄漏。

谁能帮我解释一下这里发生了什么？

4

1 回答 1

7

我不认为它是泄漏，原因如下：

  1. 您提到当您触发时gc，内存使用量会恢复到默认值。这不是泄漏的工作方式。当发生泄漏时，这些对象是可访问的，即使在重复垃圾收集之后，堆大小也不会显着减小。
  2. 堆增长并不意味着泄漏。它也可能真的意味着创建了太多的对象。这是正常的，完全没问题。在您的情况下，因为它在循环中被调用。是的
  3. 在我的机器上，java -Xmx20M TestGetLastModifiedTime在我终止进程之前，它运行得非常好 10 分钟。如果有泄漏，它最终会抛出OutOfMemoryError或有太多重复的 gc
  4. 如果你在 visualvm 中观察，内存消耗在 2mb 和 2.8mb 之间跳跃。这几乎没有任何泄漏的嫌疑。此外，预计会有这么多内存消耗，因为在Files.getLastModifiedTime(PATH)内部ExecutorService会在这里和那里创建小型实用程序对象。所以对我来说它看起来非常好。

我机器上的行为：

在此处输入图像描述

重要的是，Windows 管理器显示出更高的堆使用率。这是很有可能。如果需要，JVM 可以保留空间。增加堆利用率肯定比接受gc. 这完全有道理（当你有钱时，为什么你会经历紧缩？）。

这就是为什么像观察 Windows Manager/free -m等工具不能正确地观察内部发生的事情的原因。要快速估算，您可能需要执行以下操作：

jstat -gccapacity 9043  | tail -n 1 | awk '{ print $4, $5, $6, $10 }' | python -c "import sys; nums = [x.split(' ') for x in sys.stdin.readlines()]; print(str(sum([float(x) for x in nums[0]]) / 1024.0) + ' mb');"
# change the pid from 9043 to your jvm process id.
#jvm process id can be known by running `jcmd` command (available as part of jdk)

free -m这仍然比/ Windows Manager给你更好的估计

于 2014-12-10T08:22:09.037 回答