2012-09-20 24 views
60

¿Por qué Eclipse me da el calentamiento "Pérdida de recursos: 'en' nunca se cierra 'en el siguiente código?Pérdida de recursos: 'in' nunca se cierra

public void readShapeData() { 
     Scanner in = new Scanner(System.in); 
     System.out.println("Enter the width of the Rectangle: "); 
     width = in.nextDouble(); 
     System.out.println("Enter the height of the Rectangle: "); 
     height = in.nextDouble(); 

Respuesta

43

Debido a que no cierra su escáner

in.close(); 
+28

Esto cerrará el 'Scanner' y silenciar la advertencia, pero también se cerrará' System.in' que por lo general no es deseable. –

+0

@StuartCook +1. Algo para vigilar. – informatik01

+3

¿Por qué tenemos que cerrar el escáner? ¿Qué se entiende por "fuga de recursos"? –

3

Debe close el escáner cuando haya terminado con él:

in.close(); 
2

En general, las instancias de clases que se ocupan de La E/S debe cerrarse después de que haya terminado con ellos. Entonces, al final de su código, puede agregar in.close().

6

Le indica que debe cerrar el escáner instanciado en System.in con Scanner.close(). Normalmente, todos los lectores deben estar cerrados.

Tenga en cuenta que si cierra System.in, no podrá leer de nuevo. También puedes echar un vistazo a la clase Console.

public void readShapeData() { 
    Console console = System.console(); 
    double width = Double.parseDouble(console.readLine("Enter the width of the Rectangle: ")); 
    double height = Double.parseDouble(console.readLine("Enter the height of the Rectangle: ")); 
    ... 
} 
+2

Ten en cuenta que 'System.console() 'no está disponible cuando se ejecuta una aplicación a través de Eclipse, lo que puede ser una molestia durante el desarrollo. –

0

El escáner debe estar cerrado. Es una buena práctica cerrar Readers, Streams ... y este tipo de objetos para liberar recursos y grandes pérdidas de memoria; y hacerlo en un bloque final para asegurarse de que estén cerrados incluso si se produce una excepción al manipular esos objetos.

+0

Esta respuesta realmente ayuda a OP a saber por qué debería cerrar la cosa. Claro, puede leer el documento y ver "' scanner.close() '", pero esta respuesta realmente lo ayuda a entender qué está pasando. + 1 – HyperNeutrino

36

Como han dicho otros, necesita llamar 'cerrar' en las clases IO. Voy a añadir que este es un excelente lugar para utilizar el intento - bloque finally sin capturas, así:

public void readShapeData() throws IOException { 
    Scanner in = new Scanner(System.in); 
    try { 
     System.out.println("Enter the width of the Rectangle: "); 
     width = in.nextDouble(); 
     System.out.println("Enter the height of the Rectangle: "); 
     height = in.nextDouble(); 
    } finally { 
     in.close(); 
    } 
} 

Esto asegura que su escáner está siempre cerrado, lo que garantiza la limpieza adecuada de los recursos.

De manera equivalente, en Java 7 o mayor, puede utilizar la sintaxis "try-con-recursos":

try (Scanner in = new Scanner(System.in)) { 
    ... 
} 
+1

¿Qué se entiende por fuga de recursos y cómo me afectará? –

+4

@Borat: "pérdida de recursos" implica que algunos recursos del sistema (generalmente la memoria) se pierden o desperdician innecesariamente. Por lo general, esto le afectará cuando comience a extraer OutOfMemoryErrors durante el funcionamiento normal de su programa. –

+0

Gracias eric. Sé que puede causar el error añadiendo una cadena a sí mismo en un bucle infinito. No estoy seguro de cómo un escáner podría causar ese error. –

0
private static Scanner in; 

lo fijé al declarar en una variable de clase estática privada escáner. No estoy seguro de por qué lo solucionó, pero eso es lo que el eclipse me recomendó.

+2

ha silenciado la advertencia pero ha creado una pérdida de recursos – zacheusz

8

Necesita llamar in.close(), en un bloque finally para asegurarse de que ocurra.

De la documentación de Eclipse, aquí es por qué lo marca este problema en particular (énfasis mío):

clases que implementan la interfaz java.io.Closeable (desde JDK 1.5) y java.lang.AutoCloseable (desde JDK 1.7) se consideran representan recursos externos, que deben cerrarse con el método close(), cuando ya no sean necesarios.

El compilador de Eclipse Java puede analizar si el código que utiliza tales tipos de cumple con esta política.

...

El compilador bandera [violaciónes] con "pérdida de recursos: 'arroyo' no se cierra nunca".

Explicación completa here.

1

sumando private static Scanner in; realmente no soluciona el problema, solo borra la advertencia. Al hacer que el escáner sea estático, significa que permanece abierto para siempre (o hasta que la clase se descargue, que casi es "para siempre"). El compilador no le avisa más, ya que le dijo "manténgalo abierto para siempre". Pero eso no es lo que realmente quería, ya que debe cerrar los recursos tan pronto como ya no los necesite.

HTH, Manfred.

3

Si está utilizando JDK7 u 8, puede usar try-catch con recursos. Esto cerrará automáticamente el escáner.

try (Scanner scanner = new Scanner(System.in);) 
    { 
    System.out.println("Enter the width of the Rectangle: "); 
    width = scanner.nextDouble(); 
    System.out.println("Enter the height of the Rectangle: "); 
    height = scanner.nextDouble(); 
    } 
catch(Exception ex) 
{ 
    //exception handling...do something (e.g., print the error message) 
    ex.printStackTrace(); 
} 
0
in.close(); 
scannerObject.close(); 

Se cerrará Scanner y cerrar la advertencia.

2
Scanner sc = new Scanner(System.in); 

//do stuff with sc 

sc.close();//write at end of code. 
3
// An InputStream which is typically connected to keyboard input of console programs 

Scanner in= new Scanner(System.in); 

encima de la línea se invocar Constructor de la clase de escáner con el argumento System.in, y devolver una referencia a objeto de nueva construcción.

Está conectado a un flujo de entrada que está conectado al teclado, por lo que ahora, en tiempo de ejecución, puede tomar la entrada del usuario para realizar la operación requerida.

//Write piece of code 

Para eliminar la pérdida de memoria -

in.close();//write at end of code. 
Cuestiones relacionadas