ZipFile v.s. Zipinputstream in Java.util.zip

Online comments excerpt, you can poke the Web site, this is also the translation of foreign sites related comments:

Class Zipinputstream reads a sequence of zip files (simply read out how many files are compressed by this zip file), and class ZipFile uses an embedded random file access mechanism to read the contents of the file, so you do not have to read the sequence of zip files sequentially.
Another fundamental difference between Zipinputstream and ZipFile is the use of high-speed buffering. When files are read out using Zipinputstream and FileInputStream streams, the zip entry does not use high-speed buffering. However, if you use ZipFile (filename) to open the file, it will use an inline cache, so if zipfile (filename) is called repeatedly, the file is only opened once. The buffer value is used when the second time is opened. If you're working on a UNIX system, it doesn't work, because all the zip files opened with ZipFile have mappings in memory, so using zipfile performance is better than Zipinputstream. However, if the contents of the same zip file change frequently during the execution of the program, or if it is overloaded, using Zipinputstream becomes your first choice.

I used JMH to do a simple performance test, here is the code, note:

 Packagecom/* * Licensed to the Apache software Foundation (ASF) under one or more * Contributor license agreements. See the NOTICE file distributed with * This work for additional information regarding copyright ownership. * The ASF licenses this file to you under the Apache license, Version 2.0 * (the "license"); You are not a use of this file except in compliance with * the License. Obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * unless required by Applica BLE law or agreed into writing, software * Distributed under the License is distributed on a "as is" BASIS, * without WA Rranties or CONDITIONS of any KIND, either express OR implied. * See the license for the specific language governing permissions and * limitations under the license. */ImportJava.io.File;ImportJava.util.concurrent.TimeUnit;ImportOrg.openjdk.jmh.annotations.Benchmark;ImportOrg.openjdk.jmh.annotations.BenchmarkMode;ImportOrg.openjdk.jmh.annotations.Fork;ImportOrg.openjdk.jmh.annotations.Measurement;ImportOrg.openjdk.jmh.annotations.Mode;ImportOrg.openjdk.jmh.annotations.OutputTimeUnit;ImportOrg.openjdk.jmh.annotations.Scope;ImportOrg.openjdk.jmh.annotations.State;ImportOrg.openjdk.jmh.annotations.Threads;ImportOrg.openjdk.jmh.annotations.Warmup;/** * @author John kenrinus Lee * @version 2016-05-07 * *@Fork(1)@Warmup(iterations =4, time =4)@Measurement(iterations =4, time =4)@State(Scope.benchmark)@BenchmarkMode(Mode.averagetime)@OutputTimeUnit(timeunit.nanoseconds) Public  class unziptest {    @Benchmark    @Threads(1) Public void Zipinputstream() {File File =NewFile ("/USERS/TEMP/TEMP/WEIZHI21"); Ziputils.deleteexistswithnopermissioncheck (file);assertFile.mkdirs ();Try{Ziputils.unzipfilebyzipinputstream (NewFile ("/users/temp/temp/weizhi2/temp.zip"),"/USERS/TEMP/TEMP/WEIZHI21",true,NULL,NULL); }Catch(Exception e)        {E.printstacktrace (); }    }@Benchmark    @Threads(1) Public void ZipFile() {File File =NewFile ("/users/temp/temp/weizhi11"); Ziputils.deleteexistswithnopermissioncheck (file);assertFile.mkdirs ();Try{Ziputils.unzipfile (NewFile ("/users/temp/temp/weizhi1/temp.zip"),"/users/temp/temp/weizhi11",true,NULL,NULL); }Catch(Exception e)        {E.printstacktrace (); }    }}

Where ziputils can be downloaded from my GitHub, where only some Java classes are available, others are experimental, the code is messy, and it is strongly recommended that you ignore it .

Conclusion: [ZipFile is better than Zipinputstream]

    // Benchmark                     Mode  Samples         Score          Error  Units    // UnzipTest.zipfile             avgt        4  70085414.616 ± 19146631.125  ns/op    // UnzipTest.zipinputstream      avgt        4  81746111.179 ± 23409444.648  ns/op    // UnzipTest.zipinputstream      avgt        4  78950748.131 ± 48377116.992  ns/op    // UnzipTest.zipfile             avgt        4  68650953.926 ± 24305554.065  ns/op

Note:
TAR.GZ/TGZ compression [Tar+gzip] compatibility and compression ratio is high, but now look at the Java JDK, the Android SDK does not have a related class library, need to introduce Apache-ant.jar, for mobile phone This kind of computing power device is also slightly worse, and also less than the ZIP general , not to go into the deep;

ZipFile v.s. Zipinputstream in Java.util.zip