假设对象K与稀缺的系统资源相关联（例如，绑定到本地主机UDP上的开放端口，其中每台机器只有65535个可用）。JVM应用程序需要创建对象，使用资源执行任务，并在请求系统GC时释放它。（显然，将其定义为AutoClosable并在withResource块中使用它可能是一个更有效的选择，但这不是这个问题的主题）
根据2023，任何JVM语言都有几种实现（以Scala 2.13为例）：

import org.scalatest.funspec.AnyFunSpec

import java.lang.ref.Cleaner
import scala.concurrent.{ExecutionContext, ExecutionContextExecutor, Future}
import scala.ref.{PhantomReference, ReferenceQueue, WeakReference}

class GCCleaningSpike extends AnyFunSpec {

  import GCCleaningSpike._

  describe("System.gc() can dispose unreachable object") {

    it("with finalizer") {

      var v = Dummies._1()

      assertInc {
        v = null
      }
    }

    it("<: class with finalizer") {

      var v = Dummies._2()

      assertInc {
        v = null
      }
    }

    it("registered to a cleaner") {

      @volatile var v = Dummies._3()

      assertInc {
        v = null
      }
    }

    it("registered to a phantom reference cleanup thread") {

      @volatile var v = Dummies._4()

      assertInc {
        v = null
      }
    }

    it("registered to a weak reference cleanup thread") {

      @volatile var v = Dummies._4()

      assertInc {
        v = null
      }
    }
  }
}

object GCCleaningSpike {

  implicit lazy val ec: ExecutionContextExecutor = ExecutionContext.global

  case class WithFinalizer(fn: () => Unit) {

    case class _1() {
      override def finalize(): Unit = fn()
    }

    trait _2Base {
      override def finalize(): Unit = fn()
    }
    case class _2() extends _2Base

    final val _cleaner = Cleaner.create()
    case class _3() extends AutoCloseable {

      final private val cleanable = _cleaner.register(
        this,
        { () =>
          println("\ncleaned\n")
          fn()
        }
      )

      override def close(): Unit = cleanable.clean()
    }

    lazy val phantomQueue = new ReferenceQueue[_2Base]()
    case class _4() {
      val ref = new PhantomReference(this, phantomQueue)
    }

    val cleaningPhantom: Future[Unit] = Future {
      while (true) {
        val ref = phantomQueue.remove
        fn()
      }
    }

    lazy val weakQueue = new ReferenceQueue[_2Base]()
    case class _5() {
      val ref = new WeakReference(this, weakQueue)
    }

    val cleaningWeak: Future[Unit] = Future {
      while (true) {
        val ref = weakQueue.remove
        fn()
      }
    }
  }

  @transient var count = 0

  val doInc: () => Unit = () => count += 1

  def assertInc(fn: => Unit): Unit = {
    val c1 = count

    fn

    System.gc()

    Thread.sleep(1000)
    val c2 = count

    assert(c2 - c1 == 1)
  }

  object Dummies extends WithFinalizer(doInc)
}

字符串

• Finalizer方法（由class _1()说明），在上面的测试中工作，但从不可靠（例如，如果JVM进程被终止），它也在Java 11中被弃用
• 与引用清理器关联的可清理成员（如class _3()所示），在上述测试中，它们不能通过解引用和系统GC触发
• 与活动ReferenceQueue监视线程关联的WeakReference/RectomReference成员（分别由class _4()和_5()表示）。同样，它们也不能通过解引用和系统GC触发，此外，它们都需要在其生命周期的大部分时间内处于阻塞/休眠状态的昂贵监视线程。如果该线程可以用低成本的绿色线程或协程替换，则不清除。
• 第三方实现，由于选项太多，没有给出测试代码。

我无法感知这些实现是完美的，甚至是功能。有没有一个规范的，官方推荐和测试的方法来做到这一点？

**更新1：**我完全同意在管理系统资源（例如端口或堆外内存）时不应依赖和滥用GC机制。这就是为什么测试套件中显示的清理机制仅在资源已经绑定到范围/生命周期的实际情况下使用。并且无论GC如何都会被释放（例如，在JVM终止的情况下，它们将通过系统关闭钩子释放）。尽管如此，仍有可能在资源的生命周期之前很久就对资源进行解引用和GC，并且可以实现内存占用的轻微改善。在没有进一步澄清的情况下，让我们假设问题是关于这些特性/功能的有效用例，而不是资源管理

另外，最初的测试套件只是为了简短而用Scala编写的，稍后我将添加Java版本。