java：将文件解压缩为字符串太慢

Question

以下是我如何将字符串压缩到文件中：

public static void compressRawText(File outFile, String src) {
    FileOutputStream fo = null;
    GZIPOutputStream gz = null;
    try {
        fo = new FileOutputStream(outFile);
        gz = new GZIPOutputStream(fo);
        gz.write(src.getBytes());
        gz.flush();
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        try {
            gz.close();
            fo.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

以下是我如何解压缩它：

static int BUFFER_SIZE = 8 * 1024;
static int STRING_SIZE = 2 * 1024 * 1024;
public static String decompressRawText(File inFile) {
    InputStream in = null;
    InputStreamReader isr = null;
    StringBuilder sb = new StringBuilder(STRING_SIZE);//constant resizing is costly, so set the STRING_SIZE
    try {
        in = new FileInputStream(inFile);
        in = new BufferedInputStream(in, BUFFER_SIZE);
        in = new GZIPInputStream(in, BUFFER_SIZE);
        isr = new InputStreamReader(in);
        char[] cbuf = new char[BUFFER_SIZE];
        int length = 0;
        while ((length = isr.read(cbuf)) != -1) {
            sb.append(cbuf, 0, length);
        }
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        try {
            in.close();
        } catch (Exception e1) {
            e1.printStackTrace();
        }
    }
    return sb.toString();
}

解压缩似乎需要很长时间才能完成。我有一种感觉，我在减压方面做了太多多余的步骤。知道如何加快速度吗？

编辑：已根据以下给出的建议将代码修改为上述内容，
1.我改变了模式，所以稍微简单一下我的代码，但是如果我不能使用IOUtils，那么使用这个模式仍然可以吗？
2. 我按照entonio的建议将StringBuilder缓冲区设置为2M，是否应该设置得大一点？内存仍然可以，我仍然有大约 10M 可用，正如 Eclipse 的堆监视器所建议的那样 3.我删除了BufferedReader并添加了BufferedInputStream，但我仍然不确定BUFFER_SIZE，有什么建议吗？

上述修改将循环所有 30 个 2M 文件所需的时间从近 30 秒缩短到 14 秒左右，但我需要将其减少到 10 秒以下，在 Android 上是否可能？好吧，基本上，我需要处理一个总共60M的文本文件，我把它们分成了30个2M，在开始处理每个字符串之前，我对时间成本做了上面的计时，只是为了循环所有文件并将文件中的String放入我的内存中。由于我没有太多经验，如果我用60个1M文件代替会更好吗？或者我应该采取任何其他改进？谢谢。

另外：由于物理 IO 非常耗时，并且由于我的文件压缩版本都非常小（大约 2K 到 2M 文本），我是否仍然可以执行上述操作，但在已经映射到的文件上记忆？可能使用java NIO？谢谢

Answer 1

BufferedReader 的唯一用途是您不使用的 readLine() 方法，那么为什么不直接从 InputStreamReader 读取呢？另外，也许减小缓冲区大小可能会有所帮助。此外，您可能应该在读取和写入时指定编码，但这不会对性能产生影响。

编辑：更多数据

如果您知道前面字符串的大小，则应该向 decompressRawText 添加长度参数，并使用它来初始化 StringBuilder 。否则，它将不断调整大小以适应结果，这是昂贵的。

编辑：澄清

2MB 意味着需要大量调整大小。如果您指定的容量大于读取后最终得到的长度（当然，除了暂时使用更多内存），也没有什么坏处。

Answer 2

您应该在使用 GZipInputStream 包装之前使用 BufferedInputStream 包装 FileInputStream，而不是使用 BufferedReader。

原因是，根据实现的不同，装饰层次结构中的任何各种输入类都可能决定逐字节读取（我想说 InputStreamReader 最有可能这样做）。一旦到达 FileInputStream，这就会转化为许多 read(2) 调用。

当然，这可能只是我个人的迷信。但是，如果您在 Linux 上运行，则始终可以使用 strace 进行测试。

---

编辑：构建一堆流委托时要遵循的一个很好的模式是使用单个 InputStream 变量。然后，您只需在 finally 块中关闭一件事（并且可以使用 Jakarta Commons IOUtils 来避免大量嵌套的 try-catch-finally 块）。

  InputStream in = null;
  try
  {
     in = new FileInputStream("foo");
     in = new BufferedInputStream(in);
     in = new GZIPInputStream(in);

     // do something with the stream
  }
  finally
  {
     IOUtils.closeQuietly(in);
  }

Answer 3

在 FileInputStream 和 GZIPInputStream 之间添加 BufferedInputStream。

写作的时候也是如此。