JUnit @After teardown and WeakReference usage for reliable memory leak detection

When writing a JUnit test that aims to confirm a memory leak has been fixed, a common approach is to hold a java.lang.ref.WeakReference to the suspect object, clear strong references, and then check that the reference has been cleared.

The goal is to assert that after the test’s teardown phase (e.g., an @After or @AfterEach method) the weakly‑referenced object is no longer reachable, indicating that the leak‑fixing code succeeded.

Because garbage collection is nondeterministic and the JUnit runner may retain strong references indirectly, it is unclear how to reliably trigger reclamation within the test without relying on implementation‑specific calls such as System.gc().

What constraints does the JUnit test lifecycle place on using WeakReference for leak verification, and how can a test be written to remain portable across JVM implementations? Is it acceptable to invoke System.gc() in an @After method to increase the chance of reclamation, or does this introduce flakiness?