linea - filewriter java

Cuándo vaciar un BufferedWriter

Question

En un programa Java (Java 1.5), tengo un BufferedWriter que envuelve un Filewriter, y llamo a write () muchas veces ... El archivo resultante es bastante grande ...

Entre las líneas de este archivo, algunas están incompletas ...

¿Debo llamar a flush cada vez que escribo algo (pero sospecho que sería ineficiente) o usar otro método de BufferedWriter o usar otra clase ...?

(Como tengo un montón de líneas por escribir, quiero tener algo bastante eficiente.) ¿Cuál sería el momento ideal para "enrojecer"? (cuando alcanzo la capacidad del BufferedWriter) ...

En eso:

try {
  analysisOutput = new BufferedWriter(new FileWriter(
      "analysisResults", true));
  analysisOutput.newLine();
  analysisOutput.write("Processing File " + fileName + "/n");
} 
catch (FileNotFoundException ex) {
  ex.printStackTrace();
} 
catch (IOException ex) {
  ex.printStackTrace();
}

Escritura:

private void printAfterInfo(String toBeMoved,HashMap<String, Boolean> afterMap, Location location)
  throws IOException {
    if(afterMap != null) {
      for (Map.Entry<String, Boolean> map : afterMap.entrySet()) {
        if (toBeMoved == "Condition") {
          if (1 <= DEBUG)
            System.out.println("###" + toBeMoved + " " + location + " "
                + conditionalDefs.get(conditionalDefs.size() - 1)
                + " After " + map.getKey() + " "
                + map.getValue() + "/n");

          analysisOutput.write("###" + toBeMoved + " " + location + " "
              + conditionalDefs.get(conditionalDefs.size() - 1)
              + " After " + map.getKey() + " " + map.getValue()
              + "/n");
        } else {
          if (1 <= DEBUG)
            System.out.println("###" + toBeMoved + " " + location + " "
                + map.getKey() + " After " 
                + map.getValue() + "/n");
          if (conditionalDefs.size() > 0)
            analysisOutput.write("###" + toBeMoved + " " + location + " "
                + conditionalDefs.get(conditionalDefs.size() - 1) + " "
                + map.getKey() + " After " + map.getValue()
                + "/n");
          else
            analysisOutput.write("###" + toBeMoved + " " + location + " " + map.getKey() + " After " + map.getValue() + "/n");


        }
      }
    }

Me acabo de dar cuenta de que las líneas que están incompletas son las que están justo antes de "Procesar archivo" ... así ocurre cuando cambio de un archivo que analizo a otro ...

Clausura:

dispatch(unit);

try {
  if (analysisOutput != null) {
    printFileInfo();
    analysisOutput.close();
  }
} 
catch (IOException ex) {
  ex.printStackTrace();
}

A veces, la información impresa por printFileInfo no aparece en el archivo de resultados ...

Answer 1

El BufferedWriter ya se vaciará cuando llene su búfer. De los documentos de BufferedWriter.write :

Normalmente, este método almacena caracteres de la matriz dada en el búfer de esta secuencia, vaciando el búfer a la secuencia subyacente según sea necesario .

(Énfasis mío)

El objetivo de BufferedWriter es básicamente consolidar muchas escrituras pequeñas en muchas menos escrituras grandes, ya que generalmente es más eficiente (pero más difícil de codificar). Sin embargo, no debería necesitar hacer nada especial para que funcione correctamente, aparte de asegurarse de que se vacía cuando haya terminado - y llamar a close() hará esto y enjuagar / cerrar el escritor subyacente de todos modos.

En otras palabras, relájate, solo escribe, escribe, escribe y cierra :) La única vez que normalmente debes llamar al flush manual es si realmente, realmente necesitas que los datos estén en el disco ahora. (Por ejemplo, si tiene un registrador perpetuo, es posible que desee enjuagarlo de vez en cuando para que quien lea los registros no tenga que esperar hasta que el búfer esté lleno para poder ver nuevas entradas de registro).

Answer 2

El momento ideal de enjuague es cuando necesita que otro programa lea el archivo para ver los datos que se han escrito, antes de que se cierre el archivo. En muchos casos, eso nunca es.