Java性能调优指南—-java.io.BufferedInputStream和java.util.zip.GZIPInputStream

最新推荐文章于 2024-04-13 20:44:36 发布

HabbyGe

最新推荐文章于 2024-04-13 20:44:36 发布

阅读量906

点赞数

分类专栏： Java

Java 专栏收录该内容

48 篇文章 0 订阅

订阅专栏

原文链接： Java Performance Tuning Guide 翻译： ImportNew.com - 曾柏羲
译文链接： http://www.importnew.com/9363.html

BufferedInputStream和GZIPInputStream是在读取文件数据中经常使用到的两个类(至少后者在Linux系统中被广泛使用)。一般来说，缓冲输入数据是一种很好的想法，这在许多关于Java性能的书籍中都有描述。对于这些流，仍然有许多问题值得我们了解。

何时不需要缓冲

缓冲是用来减少来自输入设备的单独读取操作数的数量，许多开发者往往忽视这一点，并经常将InputStream包含进BufferedInputStream中，如

final InputStream is = new BufferedInputStream(new FileInputStream(file));

是否使用缓冲的简略规则如下：当你的数据块足够大的时候(100K+)，你不需要使用缓冲，你可以处理任何长度的块(不需要保证在缓冲前缓冲区中至少有N bytes可用字节)。在所有的其他情况下，你都需要缓冲输入数据。最简单的不需要缓冲的例子就是手动复制文件的过程。

public static void copyFile(final File from, final File to) throws IOException {
    final InputStream is = new FileInputStream(from);
    try {
        final OutputStream os = new FileOutputStream(to);
        try {
            final byte[] buf = new byte[8192];
            int read = 0;
            while ((read = is.read(buf)) != -1) {
                os.write(buf, 0, read);
            }
        } finally {
            os.close();
        }
    } finally {
        is.close();
    }
}

注1:衡量文件复制的性能是非常困难的，因为这很大程度上收到操作系统写入缓存的影响。在我的机器上复制一个4.5G的文件到相同的硬盘所花费的时间在68至107s之间变化。

注2:文件复制经常通过Java NIO实现，使用FileChannel.transferTo或者transferFrom 的方法。使用这些方法不需要再在内核和用户态之间频繁的转换(在用户的java程序中将读入数据转换为字节缓存，再通过内核调用将它复制回输出文件中)。相反它们在内核模式中传输尽可能多的数据(直达231-1字节)，尽可能做到不返回用户的代码中。因此，Java NIO会使用较少的CPU周期，并腾出留给其他程序。然而，只有高负荷的环境下才能看到这当中的差异(在我的机器中，NIO模式的CPU总占用率为4%，而旧的流模式CPU总占用率则为8-9%)。以下是一个可能的Java NIO实现:

private static void copyFileNio(final File from, final File to) throws IOException {
    final RandomAccessFile inFile = new RandomAccessFile(from, "r");
    try {
        final RandomAccessFile outFile = new RandomAccessFile(to, "rw");
        try {
            final FileChannel inChannel = inFile.getChannel();
            final FileChannel outChannel = outFile.getChannel();
            long pos = 0;
            long toCopy = inFile.length();
            while (toCopy > 0) {
                final long bytes = inChannel.transferTo(pos, toCopy, outChannel);
                pos += bytes;
                toCopy -= bytes;
            }
        } finally {
            outFile.close();
        }
    } finally {
        inFile.close();
    }
}

缓冲大小

BufferedInputStream中默认的缓冲大小是8192个字节。缓冲大小实际上是从输入设备中准备读取的块的平均大小。这就是为什么它经常值得精确地提高至64K(65536)，万一有非常大的输入文件 — 那些在512K和2M的文件，为了更深一层地减少磁盘读入的数量。许多专家也建议将此值设置为4096的整数倍 — 一个普通磁盘扇区的大小。所以，不要将缓冲区的大小设置为，像125000这样的大小，取而代之的应该是像131072（128K）这样的大小。

java.util.zip.GZIPInputStream 是一个能够很好处理gzip文件输入的输入流。它经常被用来做这样的事情：

final InputStream is = new GZIPInputStream(new BufferedInputStream(new FileInputStream(file)));

这样的初始化已经足够好了，不过BufferedInputStream在此处是多余的，因为GZIPInputStream已经拥有了自己的内建缓冲区，它里面有一个字节缓冲区(实际上，它是InflaterInputStream的成员)，被用做此从底层流中读取压缩的数据，并且将其传递给一个inflater。这个缓冲区默认的大小是512字节，所以它必须被设置成一个更高的数值。一个更理想地使用GZIPInputStream的方式如下:

final InputStream is = new GZIPInputStream(new FileInputStream(file), 65536);

BufferedInputStream.available

BufferedInputStream.available 方法有一个可能的性能问题，取决于你真正想要接收到的东西。它的标准实现将返回BufferedInputStream自身的内部缓冲区可用字节数和底层输入流调用avalibale()结果的总和。所以，它将尽可能地返回一个精确的数值。但是在很多案例中，用户想知道的仅仅是缓冲区中是否还有空间可用( available() > 0). 在这种情况下，即使BufferedInputStream的缓冲区中只有一个字节余留，我们都不需要去查询底层的输入流。这显得非常重要，如果我们有一个FileInputStream包含在BufferedInputStream中–这样的优化会节省我们在FileInputStream.available()中的磁盘访问时间。

幸运的是，我们可以简单地解决这样的问题。BufferedInputStream不是一个final类，所以我们可以继承并且重载available方法。我们可以看看JDK的源代码着手准备。从这里我们还可以发现Java 6中的实现有一个bug — 如果BufferedInputStream可用的字节数和底层流available()调用结果的总和大于Integer.MaxVALUE，这样就会因为溢出而返回一个负数结果，不过这在Java 7中已经得到了解决。

以下是我们改进的实现，它将返回BufferedInputStream的内置缓冲区中可用的字节数，又或者是，如果它里面没有剩余的字节数，底层流中的available()方法会被调用，并且返回调用后的结果。在大多数情况下，这种实现会极少调用到底层流中的available()方法，因为当BufferedInputStream缓冲区被读取到最后，这个类会读取从底层流中读取更多的数据，所以，我们只会在输入文件的末尾中调用底层流的available()方法。

public class FasterBufferedInputStream extends BufferedInputStream {
    public FasterBufferedInputStream(InputStream in, int size) {
        super(in, size);
    }
    //如果有东西可用，该方法将返回一个正数，否则它会返回0。
    public int available() throws IOException {
        if (in == null) {
            throw new IOException("Stream closed");
        }
        final int n = count - pos;
        return n > 0 ? n : in.available();
    }
}

为了测试这个实现，我尝试使用标准版的和改进版的BufferedInputStream去读取4.5G的文件，它们都有64K的缓冲区大小，并且每读取512或者1024字节的时候就调用一次available()方法。干净的测试需要操作系统在每一次测试之后重启以清除磁盘缓存。于是我决定在热身阶段读取文件，当文件已经在磁盘缓存时就用两种方法测试性能。测试显示，标准类的运行时间与available()调用的数量呈线性关系。而改进的方法运行时间看起来却与调用的次数无关。

	standard, once per 512 bytes	improved, once per 512 bytes	standard, once per 1024 bytes	improved, once per 1024 bytes
Java 6	17.062 sec	2.11 sec	9.592 sec	2.047 sec
Java 7	17.337 sec	2.125 sec	9.748 sec	2.044 sec

这里是测试的源代码:

private static void testRead(final InputStream is) throws IOException {
    final long start = System.currentTimeMillis();
    final byte[] buf = new byte[512];   //or 1024 bytes
    while (true) {
        if (is.available() == 0) {
            break;
        }
        is.read( buf );
    }
    final long time = System.currentTimeMillis() - start;
    System.out.println("Impl: " + is.getClass().getCanonicalName() + " time = " + time / 1000.0 + " sec");
}

使用以下的声明变量调用以上方法:
final InputStream is1 = new BufferedInputStream(new FileInputStream( file ), 65536);
and
final InputStream is2 = new FasterBufferedInputStream(new FileInputStream(file), 65536);

总结

BufferedInputStream和GZIPInputStream 都有内建的缓冲区。前者默认的缓冲大小是8192字节，后者则为512字节。一般而言，它值得增加任何它们的整数倍大小到至少65536。
不要使用BufferedInputStream作为GZIPInputStream的输入，相反，显示地在构造器中设置GZIPInputStream的缓存大小。虽然，保持BufferedInputStream仍然是安全的。
如果你有一个new BufferedInputStream( new FileInputStream( file ) )对象，并且需要频繁地调用它的available方法(例如，每输入一次信息都需要调用一次或者两次)，考虑重载 BufferedInputStream.available方法，它将极大地提高文件读取的速度。