Buffered RandomAccessFile java

Question

RandomAccessFile es bastante lento para el acceso aleatorio a un archivo. A menudo lee acerca de la implementación de una capa almacenada en el búfer, pero no es posible encontrar el código en línea.

Así que mi pregunta es: ¿ustedes chicos que conocen alguna implementación de código abierto de esta clase comparten un puntero o comparten su propia implementación?

Sería bueno que esta pregunta se convirtiera en una colección de enlaces y códigos útiles sobre este problema, que estoy seguro es compartida por muchos y que SUN nunca ha abordado adecuadamente.

Por favor, no hay referencia a MemoryMapping, ya que los archivos pueden ser mucho más grandes que Integer.MAX_VALUE.

Answer 1

Bueno, no veo una razón para no usar java.nio.MappedByteBuffer incluso si los archivos son más grandes que Integer.MAX_VALUE.

Evidentemente, no se le permitirá definir un solo MappedByteBuffer para todo el archivo. Pero podría tener varios MappedByteBuffers accediendo a diferentes regiones del archivo.

La definición de la posición y el tamaño de FileChannenel.map es de tipo long, lo que implica que puede proporcionar valores más Integer.MAX_VALUE, lo único que tiene que cuidar es que el tamaño de la memoria intermedia no lo hará ser más grande que Integer.MAX_VALUE.

Por lo tanto, se podría definir varios mapas de la siguiente manera:

buffer[0] = fileChannel.map(FileChannel.MapMode.READ_WRITE,0,2147483647L); 
buffer[1] = fileChannel.map(FileChannel.MapMode.READ_WRITE,2147483647L, Integer.MAX_VALUE); 
buffer[2] = fileChannel.map(FileChannel.MapMode.READ_WRITE, 4294967294L, Integer.MAX_VALUE); 
... 

En resumen, el tamaño no puede ser más grande que Integer.MAX_VALUE, pero la posición de inicio puede estar en cualquier lugar en su archivo.

En el libro Java NIO, el autor Ron Hitchens afirma:

Acceso a un archivo a través del mecanismo mapeo de memoria puede ser mucho más eficiente que la lectura o escritura de datos por medios convencionales, incluso cuando usando canales. No es necesario realizar llamadas explícitas del sistema , que pueden ser que consumen mucho tiempo. Más importante aún, el sistema de memoria virtual del sistema operativo guarda automáticamente en memoria caché las páginas de memoria . Estas páginas se almacenarán en la memoria caché usando la memoria del sistema y no serán las que consuman espacio de la memoria de la JVM montón.

Una vez que una página de memoria se ha hecho válida (traídos de disco), que puede ser visitada de nuevo a velocidad completa por hardware sin la necesidad de realizar otra llamada sistema para obtener los datos. Grandes, archivos estructurados que contienen índices u otras secciones a las que se hace referencia o se actualizan frecuentemente pueden beneficiarse tremendamente de la asignación de memoria. Cuando combinado con bloqueo de archivos para proteger secciones críticas y control transaccional atomicity, comienza a ver cómo los buffers mapeados en la memoria pueden ser poner un buen uso.

Realmente dudo que encuentre una API de terceros que haga algo mejor que eso. Quizás pueda encontrar una API escrita sobre esta arquitectura para simplificar el trabajo.

¿No crees que este enfoque debería funcionar para ti?

Answer 2

Si está ejecutando en una máquina de 64 bits, entonces los archivos mapeados en memoria son su mejor enfoque. Simplemente asigne todo el archivo en una matriz de búferes de igual tamaño, luego elija un búfer para cada registro según sea necesario (es decir, respuesta de edalorzo, aunque quiera superponer búferes para que no tenga registros que abarquen límites) .

Si está ejecutando en una JVM de 32 bits, entonces está atrapado con RandomAccessFile. Sin embargo, puede usarlo para leer un byte[] que contenga su registro completo, luego use un ByteBuffer para recuperar valores individuales de esa matriz. En el peor de los casos, deberá hacer dos accesos a los archivos: uno para recuperar la posición/tamaño del registro y otro para recuperar el registro.

Sin embargo, tenga en cuenta que puede comenzar a estresar al recolector de basura si crea muchos byte[] s, y permanecerá vinculado a IO si rebota en todo el archivo.

Answer 3

RandomAccessFile es bastante lento para el acceso aleatorio a un archivo. A menudo lee acerca de la implementación de una capa almacenada en el búfer, pero no es posible encontrar el código en línea.

Bueno, es posible encontrarlo en línea.
Por un lado, el código fuente JAI en JPEG 2000 tiene una aplicación, así como un impl gravado no aun más en: http://www.unidata.ucar.edu/software/netcdf-java/

javadocs:

http://www.unidata.ucar.edu/software/thredds/v4.3/netcdf-java/v4.0/javadoc/ucar/unidata/io/RandomAccessFile.html

Answer 4

Se puede hacer una BufferedInputStream de un RandomAccessFile con código como,

RandomAccessFile raf = ... 
FileInputStream fis = new FileInputStream(raf.getFD()); 
BufferedInputStream bis = new BufferedInputStream(fis); 

Algunas cosas para tomar nota

1. Cerrando el FileInputStream se cerrará la RandomAccessFile y viceversa
2. El punto RandomAccessFile y FileInputStream a la misma posición, por lo que la lectura de la FileInputStream avanzará el puntero de archivo para el RandomAccessFile, y viceversa

Probablemente la forma que desea utilizar esto sería algo así como,

RandomAccessFile raf = ... 
FileInputStream fis = new FileInputStream(raf.getFD()); 
BufferedInputStream bis = new BufferedInputStream(fis); 

//do some reads with buffer 
bis.read(...); 
bis.read(...); 

//seek to a a different section of the file, so discard the previous buffer 
raf.seek(...); 
bis = new BufferedInputStream(fis); 
bis.read(...); 
bis.read(...);