Quería escribir un programa que escribe en varios archivos simultáneamente; pensé que sería posible con un hilo al usar el modo sin bloqueo. Pero FileChannel no es compatible con el modo sin bloqueo. ¿Alguien sabe por qué?¿Por qué FileChannel en Java no es de no bloqueo?
UNIX no admite E/S sin bloqueo para archivos, consulte Non-blocking I/O with regular files. Como Java debería (al menos intentar) proporcionar el mismo comportamiento en todas las plataformas, el FileChannel no implementa SelectableChannel.
Sin embargo Java 7 incluirá una nueva clase AsynchronousFileChannel que soporta asíncrono archivo de E/S, que es un mecanismo diferente al de E/S no bloqueante. Una de sus implementaciones WindowsAsynchronousFileChannelImpl se beneficia de la API de E/S sin bloqueo en Windows (consulte Asynchronous I/O in Windows).
Mientras tanto, puede usar varios hilos para lograr el mismo efecto. Pero esto ya está implementado en SimpleAsynchronousFileChannelImpl, que es portátil en todos los sistemas operativos.
En general, solo las tomas y tuberías son realmente compatibles con E/S sin bloqueo a través del mecanismo select().
@Trying comentarios así:
"AsynchronousFileChannel soporta E/S asíncrona en lugar de no-bloqueo."
En mi opinión, asíncrono I/O (usando, por ejemplo Future o una CompletionHandler) es una forma de I/O de no bloqueo.
read(...) en el canal.Future.isDone() para evitar el bloqueo posterior.(Y, por supuesto, I/O usando un Selector puede ser asíncrona también ... dependiendo de cómo se utiliza la API.)
Por el contrario, si usted lee en un FileChannel y no hay datos actualmente disponibles, los bloques de hilos ... (típicamente) hasta que los datos estén disponibles.
En pocas palabras, la mayoría de los sistemas operativos no tratan los archivos normales como algo que puede bloquear, por lo que no permiten configurarlos explícitamente en un estado sin bloqueo.
Las E/S de archivos solo pueden estar bloqueadas porque se consideran no bloqueantes. ¿Qué quieres decir con eso? En la programación, cada operación es bloqueante. – Val
@ Val Estoy de acuerdo en que la redacción no es la mejor aquí. En la programación, no todas las operaciones son bloqueantes (en el sentido de que pone el proceso o el hilo en un estado de bloqueo). Lo que quiero decir es que para un archivo normal, las API de nivel de sistema operativo asumen que read()/write()/open() y otras llamadas en un archivo regular no son de bloqueo, aunque una suposición falsa. Las API de nivel de sistema operativo regulares/estándar no pueden cambiar el identificador a un archivo de bloqueo a no bloqueo. (que es algo que puedes hacer con tomas de corriente y mangos de tubos). – nos
@nos Las API de nivel del sistema operativo suponen que 'lectura()/escritura()/abrir()' y otras llamadas son * bloqueando *. Incierto de lo que estás hablando. – EJP
+1. asynchronousFileChannel admite E/S asincrónicas en lugar de no bloquear. por favor, compruebe. Gracias. – Trying
@Trying - Me he dirigido a su comentario. (No estoy del todo de acuerdo ...) –
No veo nada en ['WindowsAsynchronousFileChannelImpl'] (http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40 -b43/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java) que 'se beneficia de la API sin bloqueo en Windows'. Por favor aclarar o corregir. La E/S asincrónica es mucho más parecida a bloquear E/S llevada a cabo en un subproceso diferente de lo que es como E/S sin bloqueo. – EJP