Java 使用SoftReference的测试代码<；T>；

要使任何带有

SoftReference

的代码得到全面测试，必须想出某种方法来测试“是的，它已被置空”的情况。通过使用“for test”代码路径强制引用为null，可以或多或少地模拟这种情况，但这不会像GC那样完全管理队列。我想知道是否有人可以分享建立一个可重复、受控的环境的经验，在这个环境中，GC实际上被激发进行收集和置零？

我将把这个问题分为两部分：

在返回null时测试代码路径

测试软参考

对于#1，我将使用一个返回null并带有足够变化（有时为null，有时为real object）的Mock来测试您认为将使用GC的所有相关场景。这就是单元测试

---

下一步是真正的集成测试，以查看GC的行为WRT SoftReference是否如您所期望的那样。我不确定我是否会致力于完全自动化这样的测试，除非是在更大的负载测试环境中，但如果这很重要，我会使用非常紧凑的最大内存量启动JVM，并加载足够的内存来触发软引用收集。失败的路径是代码不使用软引用，加载的内存应导致OutOfMemory错误。然后通过转换为软引用使测试通过。测试的目的应该是断言单元测试中对行为所做的假设。

解释了如何使用“满内存”强制垃圾收集。通过尝试分配比您拥有的更多的资源，这将失败，但直到所有

SoftReference

都清理完毕

我从未做过正式的单元测试，但我签出代码的方式是运行一个保证会出现OutOfMemory错误的场景，然后将代码更改为使用软引用并再次运行。可重复和GC？这将很困难。