java.io.RandomAccessFile可伸縮性（或其他選項）

我正在研究一些Java代碼，它們最終將在應用程序服務器中用於訪問一些非常大的文件（超過1GB，20GB以下），可能託管在NFS分享。維修單個請求會涉及這樣做：java.io.RandomAccessFile可伸縮性（或其他選項）

找到大文件，我需要在這個文件
從文件中讀取（通常在1MB）
讀取字節
導航到一個隨機點返回這些字節

我有，僅僅打開一個新的只讀文件和關閉的那一刻有些高興簡單POC代碼：

RandomAccessFile raf=new RandomAccessFile(myFileName, "r"); 
try{ 
    byte[] buffer = new byte[size]; 
    raf.seek(position); 
    raf.reafFully(buffer); 
    return buffer; 
} 
finally{ 
    raf.close(); 
}

我在想，如果這是一個非常簡單的方法，應該工作得很好，或者是一個愚蠢的簡單方法，在負載很重的時候會有很多問題（也許我需要創建一個線程安全的池讀者等）。顯然測試這個假設是最好的，但我想知道是否有任何最佳做法或任何一種方法的已知問題。到目前爲止，我還沒有能夠找出很多谷歌搜索...

謝謝！

PS。目前尚不清楚最終版本是否會在Windows或* nix上託管。目前還不清楚如何分享大文件。 PPS。應用程序服務器可能在集羣中配置，因此兩個不同的應用程序服務器可能需要同時讀取同一個大型共享文件。

來源

2012-11-29 Dave

看起來不錯。除非將文件緩存在本地磁盤或內存中，否則無法獲得更快的速度 – irreputable

因此，打開和釋放文件句柄的開銷可以忽略不計？即使跨越，比如NFS共享？ – Dave

即使在本地文件上也可能不會忽略。如果這是一個問題，你可以保持一個手柄池。或者，保持1'FileChannel'打開，通過'read（dst，position）'併發讀取' – irreputable

另一種選擇是Java NIO，即FileChannel。 FileChannel也可導航，它可能比RandomAccessFile更快，因爲它可以使用所謂的直接緩衝區。它有一些更有趣的功能，例如它可以中斷。

來源

2012-11-29 15:54:48

良好的調用。是的，我已經測試過這些。它看起來好像速度可以忽略不計，但速度不足以保證* this *特殊用例的複雜性。我最近因爲另一個應用程序的JVM中的物理窗口內存泄漏而被nio燒了，所以從那以後我一直有點猶豫。老實說，如果隨機訪問方法在加載情況下執行以及它在單線程測試中執行，它對我來說是完美的。 – Dave

對，仍然檢查這個如果還沒有http://stackoverflow.com/questions/1605332/java-nio-filechannel-versus-fileoutputstream-performance-usefulness –

java.io.RandomAccessFile可伸縮性（或其他選項）

回答

相關問題