剂量q中的Clojure头部保留，运行！循环

Question

这里是 Clojure 初学者/中级，

我有一个很大的 XML 文件 (~ 240M)，为了 ETL 目的，我需要逐项懒惰地处理它。 有一些 run-processing 函数，它做了很多副作用，数据库交互，写入日志等。

当我将上述功能应用于文件时，一切运行顺利：

...
(with-open [source (-> "in.xml"
                       io/file
                       io/input-stream)]
   (-> source
       xml/parse
       ((fn [x]
          ;; runs fine
          (run-processing conn config x)))))

但是当我将相同的函数放入任何类型的循环（如doseq）时，我会得到 OutOfMemoryException（GC 开销）。

...
(with-open [source (-> "in.xml"
                       io/file
                       io/input-stream)]
  (-> source
      xml/parse
      ((fn [x]
         ;; throws OOM GC overhead exception
         (doseq [i [0]]
            (run-processing conn config x))))))

我不明白，导致GC开销异常的头部保留发生在哪里？我已经尝试过run! 甚至loop recur 而不是doseq——同样的事情发生了。

我的run-processing 函数一定有问题吗？那为什么当我直接运行它时它表现得很好？ 有点迷茫，希望有任何帮助。

Answer 1

您能否发布一个具体示例，即使它太小而无法生成 OOM 异常？

我看到的第一件事是您正在使用 (fn [x] ...) 创建一个函数，然后立即使用第二对括号调用它：

   (-> source
       xml/parse
       ((fn [x]
          ;; runs fine
          (run-processing conn config x)))))

这对我来说很奇怪。为什么要这样构造代码？

在失败的doseq 示例中，您具有相同的结构：

  (-> source
      xml/parse
      ((fn [x]
         ;; throws OOM GC overhead exception
         (doseq [i [0]]
            (run-processing conn config x))))))

你还会注意到doseq 的上限是一个单元素向量，里面有一个奇怪的符号。这意味着“无限”还是什么？如果是这样，为什么它被包裹在一个向量中？这看起来像是一个问题（或者可能是 clojure.core 错误），因为在单元素向量上的 doseq 循环应该只运行一次。

另外一点，循环变量i 从未使用过——这是故意的吗？它似乎与第一个（工作）示例非常不同。

此外，（取决于您的代码的详细信息）创建包含doseq 的函数与立即调用它之间的某些交互可能是问题的原因。

更新：

Re(fn [x] ...) 表单，我会这样写：

(->  source
     xml/parse
     #(run-processing conn config %)))

或

(->> source     ; note "thread-last" macro
     xml/parse
     (run-processing conn config)))

也许对于doseq`，你想要的更像是这样的：

(-> source
    xml/parse
    #(doseq [single-item %]
      (run-processing conn config single-item)))

但是，在这种情况下，我们一次为单个项目调用 run-processing 多次，而之前我们调用 run-processing 一次并从 xml/parse 传递整个惰性结果。

Answer 2

虽然我不知道究竟是什么导致了 OOM，但我想提供一些一般性建议，并详细说明我们在 cmets 中的讨论。

所以当我使用任何类型的循环时，序列都会保存在内存中， 但如果我直接调用运行处理不会？但是在doseq 文档字符串中 它明确指出“不保留序列的头部”。 那么当我需要多次调用run-processing时该怎么办 （例如，使用不同的论点）？

这是我们的函数：

(defn process-file! [conn config name]
  (with-open [source (io/input-stream (io/file name))]
    (-> (xml/parse source)
        ((fn [x]
           (doseq [i [0]]
             (run-processing conn config x)))))))

其中x 是lazy-seq（如果您使用的是data.xml），例如：

x <- xml iterator <- file stream

如果run-proccessing 一切正常，（完全消耗x 并返回nil）就没有问题——问题在于x 绑定本身。在run-processing 运行时，它完全实现了序列x 是头部的。

(defn process-xml! [conn config x]
  (run-processing conn config x)
  ;; X IS FULLY REALIZED IN MEMORY
  (run-reporting conn config x))

(defn process-file! [conn config name]
  (with-open [source (io/input-stream (io/file name))]
    (->> (xml/parse source)
         (process-xml! conn config))))

如您所见，我们不会逐项使用文件并立即将其丢弃 — 这一切都归功于x。 doseq 与此无关：它“不保留序列的头部”它消耗，在我们的例子中是 [0]。

---

这种方法不是很惯用，原因有两个：

1。 run-processing 做的太多了

它知道数据来自何处、以何种形式、如何处理以及如何处理数据。更典型的proccess-file! 如下所示：

(defn process-file! [conn config name]
  (with-open [source (io/input-stream (io/file name))]
    (->> (xml/parse source)
         (find-item-nodes)
         (map node->item)
         (run! (partial process-item! conn config)))))

这并不总是可行的，也不适合所有用例，但这样做还有一个理由。

2。 process-file! 应该（理想情况下）永远不要将x 给任何人

查看您的原始代码可以立即看出这一点：它使用的是with-open。 query 来自 clojure.java.jdbc 就是一个很好的例子。它所做的是获取ResultSet，将其映射到纯Clojure 数据结构，并强制它被完全读取（使用doall 的result-set-fn）以释放连接。

注意它永远不会泄漏ResultSet，唯一的选择是获得结果seq (result-set-fn)，这是一个“回调”：query 想要控制ResultSet 生命周期和确保它在query 返回后关闭。不然太容易犯类似的错误了。

（但是如果我们将类似于process-xml! 的函数传递给result-set-fn，我们可以。）

---

对cmets的回答

正如我所说，我无法准确告诉您导致 OOM 的原因。可能是：

1. run-processing 本身。无论如何，JVM 内存不足，添加一个简单的doseq 会导致 OOM。这就是为什么我建议稍微增加堆大小作为测试的原因。

2. Clojure 优化了 x 绑定。

3. (fn [x] (run-processing conn config x)) 仅由 JVM 内联，随后通过 x 绑定解决了该问题。

那么为什么在doseq 中包装运行处理会使x 保留头部？在 我的例子我不多次使用 x （与你的相反 “运行处理 x THEN 在相同的 x 上运行报告”）。

问题的根源不在于重用 x，而在于x 的唯一事实存在。让我们做一个简单的lazy-seq：

(let [x (range 1 1e6)])

（让我们忘记range 是作为Java 类实现的。）

什么是x？ x 是一个惰性序列头，它是构造下一个值的秘诀。

x = (recipe)

让我们推进它：

(let [x (range 1 1e6)
      y (drop 5 x)
      z (first y)])

现在是x、y 和y：

x = (1) -> (2) -> (3) -> (4) -> (5) -> (6) -> (recipe)
y = (6) -> (recipe)
z = 6

希望您现在能明白我所说的“x 是一个 seq 头并且运行处理实现它”的意思。

关于“进程文件！应该（理想情况下）永远不要将 x 给任何人” - 如果我错了，请纠正我，但不会映射到纯 Clojure 数据 带有 doall 的结构使它们驻留在内存中，这很糟糕 如果文件太大（如我的情况）？

process-file! 不使用doall。 run! 是一个 reduce 并返回 nil。

Answer 3

要了解您的doseq 为何不起作用，我们首先必须了解(run-processing conn config x) 为何起作用：

Clojure 的神奇之处在于清除本地变量：它分析任何代码，并且在最后一次使用本地绑定后，在运行该表达式之前将其设置为 (Java) null。所以对于

(fn [x])
   (run-processing conn config x))

x 将在运行 run-processing 之前被清除。注意：禁用本地清除（编译器选项）时，您可能会遇到相同的 OOM 错误。

现在你写的时候会发生什么：

(doseq [_ [0])
   (run-processing conn config x))

编译器应该如何知道最后一次使用x 并清除它？我不可能知道：它在循环中使用。所以它永远不会被清除，x 将保留头部。

注意：当智能 JVM 实现知道调用函数不能再访问本地内存位置并提供与垃圾收集器的绑定时，它可能会在未来改变这一点。不过，目前的实现并不那么聪明。

当然它很容易解决：不要在循环中使用x。使用像run! 这样的其他构造，它只是一个函数调用，在调用run! 之前会正确清除本地。但是，如果您将 seq 的头部传递给函数，则该函数将保留头部，直到函数（闭包）超出范围。