¿Es la llamada System.gc() en sun.nio.ch.FileChannelImpl un caso malo?
try {
// Si no se produjo ninguna excepción desde map0, la dirección es válida
addr = map0(imode, mapPosition, mapSize);
} catch (OutOfMemoryError x) {
// Un OutOfMemoryError puede indicar que hemos agotado la memoria
// por lo tanto, forzamos la ejecución del recolector de basura y volvemos a intentar el mapeo
System.gc();
try {
Thread.sleep(100);
} catch (InterruptedException y) {
Thread.currentThread().interrupt();
}
try {
addr = map0(imode, mapPosition, mapSize);
} catch (OutOfMemoryError y) {
// Después de un segundo OOME, se produce un fallo
throw new IOException("Fallo en el mapeo", y);
}
}
De jdk/FileChannelImpl.java en jdk8-b120.
¿Esto ayuda con la recuperación de excepciones?
davy.ai
Este bloque de código intenta recuperarse de un
OutOfMemoryError, que puede ocurrir al intentar asignar memoria. Lo hace llamando aSystem.gc()para forzar la recolección de basura, seguido de una breve pausa y luego intentando asignar memoria nuevamente. Si el segundo intento también resulta en unOutOfMemoryError, el bloque de código lanza unaIOException.Si bien este enfoque puede ayudar a recuperarse de algunos casos de excepción, cabe destacar que simplemente llamar a
System.gc()no garantiza que la recolección de basura libere suficiente memoria para evitar otroOutOfMemoryError. Además, la pausa introducida porThread.sleep(100)puede no ser suficiente en todos los casos, ya que el tiempo necesario para la recolección de basura puede variar según el uso de memoria de la aplicación.