No dejes de divulgar nuestra página y códigos con otro, necesitamos de tu ayuda para hacer crecer nuestra comunidad.
Solución:
La respuesta E es la respuesta correcta. Si E no está allí, pronto se quedará sin memoria (o) No hay respuesta correcta.
El objeto debe ser inalcanzable para ser elegible para GC. JVM realizará múltiples escaneos y moverá objetos de una generación a otra para determinar la elegibilidad de GC y liberará la memoria cuando no se pueda acceder a los objetos.
Para aclarar por qué las otras respuestas no pueden funcionar:
-
System.gc()(junto conRuntime.getRuntime().gc(), que hace exactamente lo mismo) consejos que quieres cosas destruidas. Vagamente. La JVM es libre de ignorar las solicitudes para ejecutar un ciclo de GC, si no ve la necesidad de hacerlo. Además, a menos que haya anulado todas las referencias accesibles al objeto, GC no lo tocará de todos modos. Entonces A y B están descalificados. -
Runtime.getRuntime.gc()es mala gramática.getRuntimees una función, no una variable; necesitas paréntesis después para llamarlo. Entonces B está doblemente descalificado. -
Objectno tienedeletemétodo. Entonces C está descalificado. -
Mientras
Objectlo hace tener unfinalizemétodo, no destruye nada. Solo el recolector de basura puede eliminar un objeto. (Y en muchos casos, técnicamente ni siquiera se molestan en hacer ese; simplemente no lo copian cuando lo hacen con los demás, por lo que se queda atrás).finalizelo que hace es darle a un objeto la oportunidad de limpiarse antes de la JVM lo descarta. Es más, nunca deberías estar llamandofinalizedirectamente. (Comofinalizeestá protegido, la JVM no le permitirá llamarlo en un objeto arbitrario de todos modos). Entonces D está descalificado. -
Además de todo eso,
object.doAnythingAtAllEvenCommitSuicide()requiere que el código en ejecución tenga una referencia aobject. Eso solo lo hace “vivo” y, por lo tanto, no elegible para la recolección de basura. Entonces C y D están doblemente descalificados.
Respuesta corta – E
La respuesta esE dado que el resto está francamente mal, pero..
Respuesta larga: no es tan simple; depende …
El hecho simple es que el recolector de basura nunca puede decidir recolectar basura de cada objeto que sea un candidato viable para la recolección, a menos que la presión de la memoria sea extremadamente alta. Y luego está el hecho de que Java es tan susceptible a pérdidas de memoria como cualquier otro idioma, son simplemente más difíciles de causar y, por lo tanto, más difíciles de encontrar cuando los provocas.
El siguiente artículo tiene muchos buenos detalles sobre cómo funciona y cómo no funciona la administración de memoria y qué ocupa qué. Cómo funcionan los recolectores de basura generacionales y gracias por la memoria (Comprender cómo la JVM usa la memoria nativa en Windows y Linux)
Si lee los enlaces, creo que obtendrá la idea de que la gestión de la memoria en Java no es tan simple como una pregunta de opción múltiple.
Si para ti ha sido provechoso nuestro post, sería de mucha ayuda si lo compartieras con más programadores de esta forma nos ayudas a extender nuestro contenido.