闭包内对象生命周期及Spark中HBase连接资源回收问题

一、JVM闭包中对象的内存留存问题 #

咱们先把基础逻辑讲清楚：闭包执行完毕后，只要JVM还在运行，这个对象会不会留在堆内存里，核心看有没有存活的引用指向它。

• 如果这个对象只是闭包内部的局部变量，闭包执行完后没有任何外部代码能引用到它，那它会被标记为垃圾，等JVM触发垃圾回收（GC）时就会被清理掉，不会一直占着堆内存。
• 但要是闭包捕获了外部变量，或者这个对象被其他还在使用的对象（比如全局缓存、存活的线程变量）引用着，那它就会一直留在堆里，直到所有指向它的引用都消失。

二、Spark场景下的HBase连接问题 #

先把你贴的代码整理成更清晰的格式：

rdd.foreachPartition(par => { 
  // 创建HBase连接
  val connection = ConnectionFactory.createConnection(conf) 
  par.foreach(item => { 
    // 处理RDD元素的业务逻辑
  }) 
  // 关闭连接
  connection.close() 
})

针对你的两个问题，逐个拆解：

1. 任务完成后从未关闭connection会发生什么？ #

这会引发严重的资源泄漏问题：

• HBase的Connection本质是封装了TCP连接、文件描述符等底层资源的对象，如果你不主动调用close()，即使这个对象后续被GC回收，它的finalize方法也不一定会及时执行（JVM不保证finalize的执行时机），底层的TCP连接、文件描述符这些资源不会被主动释放。
• 如果你的Executor是长期运行的（比如YARN上的持久化Executor），每次任务泄漏一个连接，积累多了会把Executor的文件描述符耗尽，导致后续任务无法创建新的连接、Socket，直接报错失败。
• 同时HBase集群端会一直维护这些无效的连接，占用集群的内存、线程资源，时间久了会拖慢HBase的响应速度，甚至引发集群异常。

2. 推测执行终止任务时，connection是否仍会被JVM持有？ #

Spark的推测执行终止任务时，通常是直接杀死执行该任务的线程（不会终止整个Executor进程）。这种情况下：

• 任务线程被强制终止，connection.close()根本没机会执行。此时connection是任务线程的局部变量，线程销毁后，这个变量的引用就不存在了，所以connection对象会被标记为可回收，等JVM GC的时候就会被清理出堆内存。
• 但核心问题还是底层资源泄漏：虽然对象会被GC，但HBase的底层TCP连接因为没被主动close，会一直处于挂起状态，直到TCP的keepalive超时（这个时间通常很长，可能几分钟甚至更久）才会被释放。这段时间里，Executor和HBase集群都会占用不必要的资源。

内容的提问来源于stack exchange，提问作者mychaint