Si puede acceder al objeto, es trivialmente no coleccionable.

El sistema JVMTI (Java Virtual Machine Tool Interface) permite que otros procesos se conecten a una JVM y obtengan estadísticas de ella. Es lo que usan los depuradores y perfiladores; visualvm (se incluye con la mayoría de los JDK) puede hacer esto, al igual que muchas ofertas comerciales. Le dan algunas ideas de GC.

El propio JDK también puede hacerlo, utilizando -XX:+PrintGCDetails ; lea este artículo para obtener más información.

Desde dentro de la misma JVM, puede usar las clases en java.lang.ref para hacer referencias a objetos sin impedir la recolección de basura. Trivialmente:

 class Test { private final WeakReference<String> weakRef; public void test() { String y = new String(""); weakRef = new WeakReference<>(y); } public boolean hasItBeenCollectedYet() { // weak refs don't impede collection; `.get()` returns null once // the object begins its collection process. return weakRef.get() == null; } }

Pero, ¿usar ese sistema solo para recopilar estadísticas generales? No es bueno en eso, las otras dos opciones son mucho mejores.

La respuesta corta es que no hay una buena manera.

Y no hay forma de hacerlo dentro de un programa que no altere (de varias maneras) el comportamiento del objeto que intenta examinar.

Las formas "no buenas" son:

• Mediante el uso de tipos de Reference . El problema es que esto altera la vida útil del objeto y solo le informa el estado del objeto en el último momento en que se ejecutó el GC.

• Tomando un volcado de pila y examinándolo con un analizador de volcado de pila. El problema es que hacer un volcado de almacenamiento dinámico es un evento costoso de "detener el mundo", usa mucho espacio en disco y necesita mucha RAM para cargar y analizar el volcado.

Finalmente, probablemente no aprenda mucho al hacer esto a menos que esté buscando una pérdida de memoria sospechosa.