本文将会对常用的几个压缩算法的性能作一下比较。结果表明，某些算法在极端苛刻的CPU限制下仍能正常工作。
　　文中进行比较的算有：
　　JDK GZIP ——这是一个压缩比高的慢速算法，压缩后的数据适合长期使用。JDK中的java.util.zip.GZIPInputStream / GZIPOutputStream便是这个算法的实现。
　　JDK deflate ——这是JDK中的又一个算法（zip文件用的是这一算法）。它与gzip的不同之处在于，你可以指定算法的压缩级别，这样你可以在压缩时间和输出文件大小上进行平衡。可选的级别有0（不压缩），以及1(快速压缩)到9（慢速压缩）。它的实现是java.util.zip.DeflaterOutputStream / InflaterInputStream。
　　LZ4压缩算法的Java实现——这是本文介绍的算法中压缩速度快的一个，与快速的deflate相比，它的压缩的结果要略微差一点。如果想搞清楚它的工作原理，我建议你读一下这篇文章。它是基于友好的Apache 2.0许可证发布的。
　　Snappy——这是Google开发的一个非常流行的压缩算法，它旨在提供速度与压缩比都相对较优的压缩算法。我用来测试的是这个实现。它也是遵循Apache 2.0许可证发布的。
　　压缩测试
　　要找出哪些既适合进行数据压缩测试又存在于大多数Java开发人员的电脑中（我可不希望你为了运行这个测试还得个几百兆的文件）的文件也着实费了我不少工夫。后我想到，大多数人应该都会在本地安装有JDK的文档。因此我决定将javadoc的目录整个合并成一个文件——拼接所有文件。这个通过tar命令可以很容易完成，但并非所有人都是Linux用户，因此我写了个程序来生成这个文件：

 

public class InputGenerator {
private static final String JAVADOC_PATH = "your_path_to_JDK/docs";
public static final File FILE_PATH = new File( "your_output_file_path" );
static
{
try {
if ( !FILE_PATH.exists() )
makeJavadocFile();
} catch (IOException e) {
e.printStackTrace();
}
}
private static void makeJavadocFile() throws IOException {
try( OutputStream os = new BufferedOutputStream( new FileOutputStream( FILE_PATH )， 65536 ) )
{
appendDir(os， new File( JAVADOC_PATH ));
}
System.out.println( "Javadoc file created" );
}
private static void appendDir( final OutputStream os， final File root ) throws IOException {
for ( File f : root.listFiles() )
{
if ( f.isDirectory() )
appendDir( os， f );
else
Files.copy(f.toPath()， os);
}
}
}

　　在我的机器上整个文件的大小是354，509，602字节（338MB）。