解压ZIP文件时写入磁盘的最佳缓冲区大小是多少？

我正在为Kotlin应用编写unzip函数，为了上报解压进度，没有使用copyTo方法，而是通过缓冲区实现。我看到的示例均采用1024字节的缓冲区，请问选择该大小有何特殊原因？在特定场景下是否适合使用更小或更大的缓冲区？

更新说明：此前我未意识到存在多个缓冲区（一个用于解压，一个用于写入），本问题所指为写入缓冲区。以下是我的代码：

fun ZipEntry.extract(zipFile: ZipFile, newFile: File, progress: (BytesWritten) -> Unit) : BytesUnzipped {
    var bytesUnzipped = 0L
    zipFile.getInputStream(this).use { input ->
        newFile.outputStream().use { output ->
            val buffer = ByteArray(DEFAULT_BUFFER_SIZE)
            var bytesRead: Int
            while (input.read(buffer).also { bytesRead = it } > 0) {
                output.write(buffer, 0, bytesRead)
                bytesUnzipped += bytesRead
                progress(BytesWritten(bytesRead))
            }
        }
    }
    return BytesUnzipped(bytesUnzipped)
}

@JvmInline
value class BytesWritten(val value: Int)

@JvmInline
value class BytesUnzipped(val value: Long)

1024字节缓冲区的特殊原因 #

• 历史兼容性：1024字节（1KB）是早期操作系统、文件系统的经典块大小，很多传统IO示例沿用这个值，逐渐成为约定俗成的默认选择。
• 内存与效率的平衡：1KB缓冲区内存开销极低，哪怕在内存受限的设备（如早期移动端）也不会造成负担；同时能避免单字节读写带来的频繁系统调用——批量读写可大幅减少内核态与用户态的切换次数，显著提升IO效率。
• 底层IO对齐：不少底层IO操作的最小单位是512字节或1KB，1KB缓冲区刚好能对齐这些单位，减少碎片化IO操作。

特定场景下的缓冲区大小选择 #

适合使用更大缓冲区的场景 #

• 大文件解压：处理GB级大文件时，可将缓冲区调整为4KB、8KB甚至64KB。更大的缓冲区能进一步减少IO系统调用次数，充分利用磁盘连续读写性能，提升解压速度。建议选择操作系统页大小（通常4KB或8KB）的整数倍，避免内存浪费。
• 现代高性能设备：在内存充足的PC或高端移动端，8KB-32KB的缓冲区不会带来内存压力，反而能让IO效率更高。
• 降低进度回调开销：若进度回调过于频繁导致性能损耗，可增大缓冲区，减少回调触发次数（比如每写入8KB才上报一次进度）。

适合使用更小缓冲区的场景 #

• 极小文件处理：如果解压的都是几KB以内的小文件，1KB缓冲区已足够，甚至可用512字节——不过这种场景下性能差异几乎可忽略，无需刻意调整。
• 精细进度上报：若需要非常精准的进度更新（比如每写入128字节就上报），可使用更小的缓冲区，但要注意频繁回调可能带来的性能损耗，需做好权衡。

另外，你代码中使用的DEFAULT_BUFFER_SIZE在Kotlin/Java中实际是8192字节（8KB），这是更贴合现代系统的默认值，比1KB更适合大多数场景。如果看到的示例用1KB，大概率是较老旧的代码，建议优先使用DEFAULT_BUFFER_SIZE，它已经兼顾了现代系统的IO性能与内存平衡。

内容的提问来源于stack exchange，提问作者t3chb0t