[Bug] 1.5.0 mysql backend内存泄漏

[leshjmail]

Bug Type (问题类型)

performance (性能下降)

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• Server Version: 1.5.0 (Apache Release Version)
• Backend: Mysql
• OS: CentOS 7.x

Expected & Actual behavior (期望与实际表现)

• 问题描述：
  1、内存dump中mysql驱动实例呈线性增长趋势
  2、gc回收后占用空间没有下降，直至内存溢出
• 问题分析
  在ResultSetWrapper中创建和close方法中分别加入日志，发现存在一定比例的ResultSetWrapper没有正常调用关闭方法。
• 问题解决
  在ResultSetWrapper中加入finalize方法，在回收前判断resultSet和statement有没有正常关闭，未关闭则处理
  加入此处理后问题解决。
  @OverRide
  protected void finalize() {
  try {
  if (this.resultSet != null && !this.resultSet.isClosed()) {
  LOG.warn("resultSet was not closed properly, forcing close via finalize");
  this.resultSet.close();
  }
  } catch (SQLException e) {
  throw new BackendException("Failed to close ResultSet", e);
  } finally {
  try {
  if (this.statement != null && !this.statement.isClosed()) {
  LOG.warn("statement was not closed properly, forcing close via finalize");
  this.statement.close();
  }
  } catch (SQLException e) {
  throw new BackendException("Failed to close Statement", e);
  }
  }
  }

Vertex/Edge example (问题点 / 边数据举例)

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

[dosubot]

Hi @leshjmail! I'm Dosu and I'm helping the HugeGraph team.

Thanks for the detailed analysis — I can confirm this is a real resource leak pattern in the MySQL backend. Looking at the code, the root cause is architectural: ResultSetWrapper correctly implements AutoCloseable [1], but it gets wrapped inside MysqlEntryIterator, which is returned from MysqlStore.query() without any resource management enforcement at the API boundary [2]. If the caller doesn't fully consume or explicitly close the returned iterator, the underlying ResultSetWrapper (and its Statement/ResultSet) leak.

Some code paths handle this correctly — for example, MysqlTable.queryExist() uses a proper try-finally pattern [3], and MysqlTable.queryNumber() explicitly closes the ResultSetWrapper in a finally block [4]. But MysqlStore.query() returns the iterator directly to external callers with no cleanup guarantee.

This project has actually addressed similar MySQL resource leaks multiple times before:

• PR #1627 created ResultSetWrapper itself to fix a statement leak
• PR #1640 fixed count SQL statement leaks
• PR #1643 fixed statement leaks caused by Gremlin exec timeouts
• PR #2014 added iterator closure on error paths

However, none of these fully resolved the fundamental issue of unmanaged iterator returns from MysqlStore.query().

Regarding your proposed finalize() fix — while it resolves the symptom, finalize() is deprecated since Java 9 and has known issues (non-deterministic timing, GC overhead, potential resurrection). A more robust approach would be:

1. Ensure all callers of MysqlStore.query() use try-with-resources or try-finally to close iterators
2. Add defensive cleanup in MysqlTable.query() to close ResultSetWrapper if the parser throws an exception [5]
3. Consider using a Cleaner (Java 9+) instead of finalize() as a safety net, or implement PhantomReference-based cleanup

Would you be interested in opening a PR with a fix? The most impactful change would be auditing all call sites of MysqlStore.query() to ensure proper iterator closure.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[leshjmail]

MySQL 8.4.6
MySQL timeout 10368000