为什么这个 Java 方法会泄漏——为什么内联它会修复泄漏？

Question

我编写了一个最小的有点惰性 (int) 序列类 GarbageTest.java，作为一个实验，看看我是否可以像在 Clojure 中那样在 Java 中处理非常长的惰性序列。

给定一个naturals() 方法，它返回惰性的、无限的自然数序列；一个drop(n,sequence) 方法，它删除sequence 的第一个n 元素并返回sequence 的其余部分；和一个简单返回的nth(n,sequence) 方法：drop(n, lazySeq).head()，我写了两个测试：

static int N = (int)1e6;

// succeeds @ N = (int)1e8 with java -Xmx10m
@Test
public void dropTest() {
    assertThat( drop(N, naturals()).head(), is(N+1));
}

// fails with OutOfMemoryError @ N = (int)1e6 with java -Xmx10m
@Test
public void nthTest() {
    assertThat( nth(N, naturals()), is(N+1));
}

请注意，dropTest() 的主体是通过复制 nthTest() 的主体然后在 nth(N, naturals()) 调用上调用 IntelliJ 的“内联”重构来生成的。所以在我看来dropTest() 的行为应该与nthTest() 的行为相同。

但它并不相同！ dropTest() 运行完成，N 最大为 1e8，而 nthTest() 失败，OutOfMemoryError N 小至 1e6。

我避免使用内部类。我已经尝试了我的代码的变体ClearingArgsGarbageTest.java，它在调用其他方法之前将方法参数设为空。我已经应用了 YourKit 分析器。我看过字节码。我只是找不到导致nthTest() 失败的泄漏。

“泄漏”在哪里？为什么nthTest() 有泄漏而dropTest() 没有？

这里是来自GarbageTest.java 的其余代码，以防您不想点击进入 Github 项目：

/**
 * a not-perfectly-lazy lazy sequence of ints. see LazierGarbageTest for a lazier one
 */
static class LazyishSeq {
    final int head;

    volatile Supplier<LazyishSeq> tailThunk;
    LazyishSeq tailValue;

    LazyishSeq(final int head, final Supplier<LazyishSeq> tailThunk) {
        this.head = head;
        this.tailThunk = tailThunk;
        tailValue = null;
    }

    int head() {
        return head;
    }

    LazyishSeq tail() {
        if (null != tailThunk)
            synchronized(this) {
                if (null != tailThunk) {
                    tailValue = tailThunk.get();
                    tailThunk = null;
                }
            }
        return tailValue;
    }
}

static class Incrementing implements Supplier<LazyishSeq> {
    final int seed;
    private Incrementing(final int seed) { this.seed = seed;}

    public static LazyishSeq createSequence(final int n) {
        return new LazyishSeq( n, new Incrementing(n+1));
    }

    @Override
    public LazyishSeq get() {
        return createSequence(seed);
    }
}

static LazyishSeq naturals() {
    return Incrementing.createSequence(1);
}

static LazyishSeq drop(
        final int n,
        final LazyishSeq lazySeqArg) {
    LazyishSeq lazySeq = lazySeqArg;
    for( int i = n; i > 0 && null != lazySeq; i -= 1) {
        lazySeq = lazySeq.tail();
    }
    return lazySeq;
}

static int nth(final int n, final LazyishSeq lazySeq) {
    return drop(n, lazySeq).head();
}

Answer 1

在你的方法中

static int nth(final int n, final LazyishSeq lazySeq) {
    return drop(n, lazySeq).head();
}

参数变量lazySeq 在整个drop 操作期间保存对序列第一个元素的引用。这可以防止整个序列被垃圾收集。

相比之下，与

public void dropTest() {
    assertThat( drop(N, naturals()).head(), is(N+1));
}

你的序列的第一个元素由naturals()返回并直接传递给drop的调用，因此从操作数堆栈中删除并且在drop执行期间不存在。

您尝试将参数变量设置为null，即

static int nth(final int n, /*final*/ LazyishSeq lazySeqArg) {
    final LazyishSeq lazySeqLocal = lazySeqArg;
    lazySeqArg = null;
    return drop(n,lazySeqLocal).head();
}

没有帮助，就像现在一样，lazySeqArg 变量是 null，但 lazySeqLocal 包含对第一个元素的引用。

一般来说，局部变量不会阻止垃圾回收，允许收集其他未使用的对象，但这并不意味着特定实现能够做到这一点。

在 HotSpot JVM 的情况下，只有优化的代码才能摆脱这些未使用的引用。但在这里，nth 并不是热点，因为在drop 方法中发生了重重的事情。

这就是为什么drop 方法中没有出现相同问题的原因，尽管它还包含对其参数变量中第一个元素的引用。 drop 方法包含执行实际工作的循环，因此很可能会被 JVM 优化，这可能会导致它消除未使用的变量，从而允许收集已处理的序列部分。

有很多因素可能会影响 JVM 的优化。除了代码的不同形状之外，似乎在未优化阶段快速分配内存也可能会降低优化器的改进。事实上，当我使用-Xcompile 运行时，为了完全禁止解释执行，两种变体都运行成功，即使int N = (int)1e9 也不再有问题。当然，强制编译会增加启动时间。

我不得不承认，我不明白为什么混合模式的性能那么要差得多，我会进一步调查。但通常，您必须注意垃圾收集器的效率取决于实现，因此在一个环境中收集的对象可能会留在另一个环境中的内存中。

Answer 2

Clojure 实施了一种策略来处理这种称为“本地清除”的场景。编译器支持它，使其在纯 Clojure 代码中需要时自动启动（除非在编译时禁用——这有时对调试很有用）。 Clojure 也确实在其 Java 运行时的各个地方清除了局部变量，但是，它可以在 Java 库甚至应用程序代码中使用它的方式，尽管它无疑会有些麻烦。

在深入了解 Clojure 的作用之前，先简要总结一下此示例中发生的情况：

1. nth(int, LazyishSeq) 是根据drop(int, LazyishSeq) 和LazyishSeq.head() 实现的。

2. nth 将其两个参数都传递给drop，并且不再使用它们。

3. drop 可以很容易地实现，避免卡住传入序列的头部。

这里nth 仍然保留它的序列参数的头部。运行时可能会丢弃该引用，但不能保证会丢弃。

Clojure 处理此问题的方式是在控制权移交给drop 之前明确清除对序列的引用。这是使用相当优雅的技巧 (link to the below snippet on GitHub as of Clojure 1.9.0) 完成的：

//  clojure/src/jvm/clojure/lang/Util.java

/**
 *   Copyright (c) Rich Hickey. All rights reserved.
 *   The use and distribution terms for this software are covered by the
 *   Eclipse Public License 1.0 (http://opensource.org/licenses/eclipse-1.0.php)
 *   which can be found in the file epl-v10.html at the root of this distribution.
 *   By using this software in any fashion, you are agreeing to be bound by
 *   the terms of this license.
 *   You must not remove this notice, or any other, from this software.
 **/

// … beginning of the file omitted …

// the next line is the 190th in the file as of Clojure 1.9.0
static public Object ret1(Object ret, Object nil){
        return ret;
}

static public ISeq ret1(ISeq ret, Object nil){
        return ret;
}

// …

鉴于上述情况，nth 内部对drop 的调用可以更改为

drop(n, ret1(lazySeq, lazySeq = null))

这里lazySeq = null在控制权转移到ret1之前被评估为一个表达式；值是null 并且还有将lazySeq 引用设置为null 的副作用。 ret1 的第一个参数将在此时进行评估，因此 ret1 在其第一个参数中接收对序列的引用并按预期返回它，然后将该值传递给 drop。

因此drop 接收到lazySeq 本地保存的原始值，但在控制权转移到drop 之前本地本身被清除。

因此nth 不再占据序列的头部。