framework Java NIO per i filesystem invece di reti?

Question

Ci sono diversi framework di alta qualità che nascondono la complessità della programmazione di rete basata NIO (Mina, Netty, Grizzly, etc.). Ci sono strutture simili che semplificano basato NIO programmazione del file-system?

Per esempio, come un esercizio di apprendimento, vorrei realizzare un disco di backup mappa in base a questo articolo (incredibile!): http://www.javaworld.com/javaworld/jw-01-1999/jw-01-step.html .

Answer 1

No (ma ...)

Ma questo è perché NIO Java FileChannel e MappedByteBuffer non sono altrettanto complesso o difficile da comprendere e utilizzare come il networking e Selettore roba java.nio.

Ecco un esempio di creazione di una mappa di appoggio del disco (noto come un 'buffer di byte mappato' in NIO-land) che sarebbe opportuno per l'allenamento:

File file = new File("/Users/stu/mybigfile.bin");
FileChannel fc = (new FileInputStream(file)).getChannel(); 
MappedByteBuffer buf = fc.map(MapMode.READ_WRITE, 0, file.length());

È possibile accedere al buffer come qualsiasi altro Buffer . I dati si muove magicamente e rapidamente tra disco e della memoria, il tutto gestito da Java e virtuale del sistema di gestione della memoria sottostante del sistema operativo. Si ha un certo grado di controllo di questo, però. Ad esempio: MappedByteBuffer di .force() ( 'forze eventuali modifiche apportate ai contenuti di questo buffer da scrivere alla periferica di archiviazione che contiene il file mappato.' ) e .load() ( 'I carichi contenuti di questo buffer nella memoria fisica.' ) non ho mai avuto bisogno di questi personalmente.

Answer 2

Per aggiungere a @ commento di Stu. È opportuno tenere presente che le connessioni di socket non hanno tutti i loro dati contemporaneamente, ma invece può essere necessario per supportare numerose connessioni lente (esp connessioni aperte ma nessun dato è ancora inviati)

Tuttavia, per i file, tutti i dati sono disponibili in una sola volta e in genere solo bisogno di aprire alcuni file alla volta per ottenere le massime prestazioni (spesso uno alla volta va bene) Se si caricano i dati da più unità (rara ) o da più server (molto raro) o interfacce di rete multiple (ancora più raro) si potrebbe benissimo accesso alcuni file alla volta migliora le prestazioni. Anche allora la complessità non è elevato e si può solo creare un thread per ogni file che si sta caricando.

L'unica occasione in cui i file sono complicate è la lettura dei file di registro. Questo complicato come il file può crescere in termini di dimensioni, come si legge. È possibile raggiungere la fine dei file e poi trovare più dati. Anche i file di log possono essere ruotati che significa il file aperto non è più il file che si desidera. Anche così questo non è molto difficile da affrontare e un requisito piuttosto rara.