private static final float[] X = new float[]{1,2,3,4,5,6,7,8,9,1,0};

public void testTensorFlowMemory() {
    // create a graph and session
    try (Graph g = new Graph(); Session s = new Session(g)) {
        // create a placeholder x and a const for the dimension to do a cumulative sum along
        Output x = g.opBuilder("Placeholder","x").setAttr("dtype",DataType.FLOAT).build().output(0);
        Output dims = g.opBuilder("Const","dims").setAttr("dtype",DataType.INT32).setAttr("value",Tensor.create(0)).build().output(0);
        Output y = g.opBuilder("Cumsum","y").addInput(x).addInput(dims).build().output(0);
        // loop a bunch to test memory usage
        for (int i=0; i<10000000; i++){
            // create a tensor from X
            Tensor tx = Tensor.create(X);
            // run the graph and fetch the resulting y tensor
            Tensor ty = s.runner().Feed("x",tx).fetch("y").run().get(0);
            // close the tensors to release their resources
            tx.close();
            ty.close();
        }

        System.out.println("non-threaded test finished");
    }
}

有什么明显的东西我做错了吗？基本流程是在该图形上创建图形和会话,创建占位符和常量,以便在以x为单位的张量上执行累积和.运行生成的y操作后,我关闭x和y张量以释放其内存资源.

我相信到目前为止帮助的事情：

>这不是Java对象内存问题.根据jvisualvm,堆不会增长,JVM中的其他内存不会增长.根据Java的本机内存跟踪,似乎不是JVM内存泄漏.
>关闭操作正在帮助,如果他们不在那里,内存会突飞猛进.随着它们到位,它仍然会变得非常快,但几乎与没有它们一样多.
> cumsum运算符并不重要,它也适用于sum和其他运算符
>它发生在带有TF 1.1的Mac OS和带有TF 1.1和1.2_rc0的CentOS 7上
>评论Tensor ty线可以消除泄漏,因此它似乎在那里.

有任何想法吗？谢谢！此外,here’s a Github project that demonstrates this issue同时进行了线程测试(以更快地增长内存)和无线测试(以显示它不是由于线程).它使用maven,可以简单地运行：

mvn test