java.io.RandomAccessFile 可扩展性（或其他选项）答案

【问题标题】：java.io.RandomAccessFile scalability (or other options)java.io.RandomAccessFile 可扩展性（或其他选项）
【发布时间】：2012-11-17 14:43:39
【问题描述】：

我正在编写一些 Java 代码，这些代码最终将在应用服务器中用于访问一些非常大的文件（超过 1GB，低于 20GB），这些文件可能托管在 NFS 共享上。为单个请求提供服务将涉及执行以下操作：

找到我需要阅读的大文件
导航到该文件中的随机点
从该文件中读取字节（通常小于 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();
}

我想知道这是否是一种优雅简单的方法，应该可以很好地工作，还是一种愚蠢的简单方法，在重负载下会出现很多问题（也许我需要建立一个线程安全的读者池，等等）。显然测试该假设是最好的，但我想知道这两种方法是否有任何最佳实践或已知问题。到目前为止，我还没有能够弄清楚很多谷歌搜索......

谢谢！

附言。目前尚不清楚最终版本是托管在 Windows 还是 *nix 上。也不清楚如何共享大文件。聚苯乙烯。应用服务器很可能配置在集群中，因此两个不同的应用服务器可能需要同时读取同一个大型共享文件。

【问题讨论】：

对我来说看起来不错。除非您将文件缓存在本地磁盘或内存中，否则您无法获得比这更快的速度
那么打开和释放文件句柄的成本可以忽略不计？甚至跨 NFS 共享？
这可能不可忽略，即使在本地文件上也是如此。如果这是一个问题，你可以保留一个句柄池。或者，保持 1 个FileChannel 打开，由read(dst,position) 并发阅读

标签： java multithreading io

【解决方案1】：

另一个选择是java NIO，即FileChannel。 FileChannel 也是可导航的它可能比 RandomAccessFile 更快，因为它可以使用所谓的直接缓冲区。它有一些更有趣的特性，例如它是可中断的。

【讨论】：

好电话。是的，我已经用这些进行了测试。它似乎确实快得可以忽略不计，但速度还不足以保证 this 特定用例的复杂性。实际上，由于另一个应用程序的 JVM 中的物理 Windows 内存泄漏，我最近被 nio 烧毁了，所以从那时起我就有点犹豫要不要使用它。老实说，如果随机访问方法在负载下的性能与单线程测试一样好，那么它对我来说是完美的。
对，如果还没有的话，还是检查一下吧stackoverflow.com/questions/1605332/…