Java NIO FileChannel versus rendimiento/utilidad de FileOutputstream

Question

Estoy tratando de averiguar si hay alguna diferencia en el rendimiento (o ventajas) cuando usamos nio FileChannel frente a FileInputStream/FileOuputStream normal para leer y escribir archivos en el sistema de archivos. Observé que en mi máquina ambos funcionan al mismo nivel, también muchas veces la forma FileChannel es más lenta. ¿Puedo saber más detalles comparando estos dos métodos? Aquí está el código que utilicé, el archivo con el que estoy probando está alrededor de 350MB. ¿Es una buena opción utilizar clases basadas en NIO para E/S de archivos si no estoy buscando acceso aleatorio u otras características avanzadas de este tipo?

package trialjavaprograms; 

import java.io.File; 
import java.io.FileInputStream; 
import java.io.FileOutputStream; 
import java.io.InputStream; 
import java.nio.ByteBuffer; 
import java.nio.channels.FileChannel; 

public class JavaNIOTest { 
    public static void main(String[] args) throws Exception { 
     useNormalIO(); 
     useFileChannel(); 
    } 

    private static void useNormalIO() throws Exception { 
     File file = new File("/home/developer/test.iso"); 
     File oFile = new File("/home/developer/test2"); 

     long time1 = System.currentTimeMillis(); 
     InputStream is = new FileInputStream(file); 
     FileOutputStream fos = new FileOutputStream(oFile); 
     byte[] buf = new byte[64 * 1024]; 
     int len = 0; 
     while((len = is.read(buf)) != -1) { 
      fos.write(buf, 0, len); 
     } 
     fos.flush(); 
     fos.close(); 
     is.close(); 
     long time2 = System.currentTimeMillis(); 
     System.out.println("Time taken: "+(time2-time1)+" ms"); 
    } 

    private static void useFileChannel() throws Exception { 
     File file = new File("/home/developer/test.iso"); 
     File oFile = new File("/home/developer/test2"); 

     long time1 = System.currentTimeMillis(); 
     FileInputStream is = new FileInputStream(file); 
     FileOutputStream fos = new FileOutputStream(oFile); 
     FileChannel f = is.getChannel(); 
     FileChannel f2 = fos.getChannel(); 

     ByteBuffer buf = ByteBuffer.allocateDirect(64 * 1024); 
     long len = 0; 
     while((len = f.read(buf)) != -1) { 
      buf.flip(); 
      f2.write(buf); 
      buf.clear(); 
     } 

     f2.close(); 
     f.close(); 

     long time2 = System.currentTimeMillis(); 
     System.out.println("Time taken: "+(time2-time1)+" ms"); 
    } 
} 

Answer 1

Mi experiencia con los archivos de mayor tamaño ha sido que java.nio es más rápido que . Sólidamente más rápido. Me gusta en el rango> 250%. Dicho esto, estoy eliminando cuellos de botella obvios, que sugiero que su micro-referencia podría sufrir. Posibles áreas para investigar:

El tamaño del búfer. El algoritmo que básicamente tienen es

• copia del disco a la memoria intermedia
• copia de la memoria intermedia en el disco

Mi propia experiencia ha sido que este tamaño del búfer es madura para la sintonización. Me he conformado con 4 KB por una parte de mi aplicación, 256 KB por otra. Sospecho que tu código está sufriendo con un buffer tan grande. Ejecute algunos benchmarks con buffers de 1KB, 2KB, 4KB, 8KB, 16KB, 32KB y 64KB para demostrarlo.

No realice pruebas de rendimiento de java que lean y escriban en el mismo disco.

Si lo hace, entonces realmente está evaluando el disco, y no Java. También sugeriría que si tu CPU no está ocupada, entonces probablemente estés experimentando algún otro cuello de botella.

No utilice un buffer si no lo necesita.

¿Por qué copiar a la memoria si su destino es otro disco o una NIC? Con archivos más grandes, la latencia incured no es trivial.

Como otros han dicho, use FileChannel.transferTo() o FileChannel.transferFrom(). La principal ventaja aquí es que la JVM utiliza el acceso del sistema operativo a DMA (Direct Memory Access), si está presente. (Esto depende de la implementación, pero las versiones modernas de Sun e IBM en CPU de propósito general son buenas) Lo que sucede es que los datos van directamente a/desde el disco, al bus y luego al destino ... evitando cualquier circuito a través de la RAM o la CPU.

La aplicación web en la que pasé el día y la noche trabajando es muy pesado. También hice micro benchmarks y benchmarks del mundo real. Y los resultados son en mi blog, echar un vistazo-ver:

• Real world performance metrics: java.io vs. java.nio
• Real world performance metrics: java.io vs. java.nio (The Sequel)

datos de uso y entornos de producción

micro-puntos de referencia son propensos a la distorsión . Si puede, haga el esfuerzo de recopilar datos de lo que planea hacer exactamente, con la carga que espera, en el hardware que espera.

Mis puntos de referencia son sólidos y confiables porque tuvieron lugar en un sistema de producción, un sistema fornido, un sistema bajo carga, reunido en registros. No de mi bloc de notas 7200 RPM 2.5" duro SATA mientras yo miraba intensamente como funciona la JVM mi disco duro.

¿Qué está ejecutando en? Importa.

Answer 2

Mi experiencia es que NIO es mucho más rápido con archivos pequeños. Pero cuando se trata de archivos grandes FileInputStream/FileOutputStream es mucho más rápido.

Answer 3

Si lo desea comparar es el rendimiento de la copia de archivos, a continuación, para la prueba de una vía que debe hacer esto en su lugar:

final FileInputStream inputStream = new FileInputStream(src); 
final FileOutputStream outputStream = new FileOutputStream(dest); 
final FileChannel inChannel = inputStream.getChannel(); 
final FileChannel outChannel = outputStream.getChannel(); 
inChannel.transferTo(0, inChannel.size(), outChannel); 
inChannel.close(); 
outChannel.close(); 
inputStream.close(); 
outputStream.close(); 

esto no será más lento de lo mismo buffering de un canal a otro , y será potencialmente masivamente más rápido. Según los Javadocs:

Muchos sistemas operativos pueden transferir bytes directamente desde el caché del sistema de archivos al canal de destino sin copiarlos.

Answer 4

Probé el rendimiento de FileInputStream frente a FileChannel para decodificar archivos codificados en base64. En mis experiencias probé un archivo bastante grande y el io tradicional siempre era un poco más rápido que nio.

FileChannel podría haber tenido una ventaja en las versiones anteriores de jvm debido a la sobrecarga de sincronización en varias clases relacionadas, pero los modernos jvm son bastante buenos para eliminar los bloqueos innecesarios.

Answer 5

Basado en mis pruebas (64 bits Win7, 6 GB de RAM , Java6), NIO transferFrom es rápido solo con archivos pequeños y se vuelve muy lento en archivos más grandes. NIO databuffer flip siempre supera el IO estándar.

• Copia 1000x2MB

  1. NIO (transferFrom) ~ 2300ms
  2. NIO (datababuffer directa 5000B flip) ~ 3500ms
  3. estándar IO (5000B buffer) ~ 6000ms

• Copia 100x20mb

  1. NIO (datababuffer directa 5000B flip) ~ 4000ms
  2. NIO (transferFrom) ~ 5000ms
  3. estándar IO (tampón 5000B) ~ 6500ms

• copia 1x1000mb

  1. NIO (directa datababuffer 5000b flip) ~ 4500s
  2. Standard IO (buffer 5000b) ~ 7000ms
  3. NIO (transferFrom) ~ 8000ms

El TransferTo() método funciona en trozos de un archivo; No fue concebido como un método de archivos de alto nivel de copia: How to copy a large file in Windows XP?

Answer 6

Si no está utilizando la función TransferTo o características de no bloqueo no notará una diferencia entre lo tradicional IO y NIO (2) debido a que el tradicional IO mapas a NIO.

Pero si puedes usar las funciones de NIO como transferFrom/To o quieres usar Buffers, entonces por supuesto NIO es el camino a seguir.

Answer 7

Responder a la parte de "utilidad" de la pregunta:

Una Gotcha bastante sutil de utilizar FileChannel sobre FileOutputStream es que la realización de cualquiera de sus operaciones de bloqueo (por ejemplo read() o write()) de un hilo que está en interrupted state hará que el canal para cerrar abruptamente con java.nio.channels.ClosedByInterruptException.

Ahora bien, esto podría ser algo bueno si se utilizó cualquiera de los FileChannel para la función principal de la secuencia, y el diseño tuvo esto en cuenta.

Pero también podría ser molesto si se utiliza con alguna función auxiliar, como una función de registro. Por ejemplo, puede encontrar que su salida de registro se cierra repentinamente si la función de registro es llamada por un hilo que también se interrumpe.

Es lamentable que esto sea tan sutil porque no tenerlo en cuenta puede dar lugar a errores que afectan la integridad de la escritura.^{[1] [2]}

• ^[1]https://bugs.openjdk.java.net/browse/JDK-4469683
• ^[2]http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6608965