Java中正确计算InputStream/字符串MB/GB大小的实现方法

当前自定义计算方法的输出值和实际落盘文件大小存在明显偏差，完全来自代码本身的逻辑错误，不存在“Java未提供大小计算预定义方法”的问题：

• 逻辑顺序错误：空值判断写在字节计算逻辑之后，当传入的data为null时，执行data.getBytes()会直接抛出空指针异常，根本走不到后续的空值返回分支。
• 冗余计算操作：手动给字节长度乘2的逻辑完全多余。String.getBytes(StandardCharsets.UTF_8)返回的已经是字符串按UTF-8编码转换后的实际字节数组长度，这个数值和将同一段字符串按UTF-8编码写入文件的实际大小完全一致，手动乘2会直接让计算结果翻倍，是大小偏差的核心来源。
• 精度缺陷：使用float类型存储大数值的大小结果，在2GB量级下，单精度浮点数的精度误差最高可达数MB，进一步放大计算值和实际值的偏差。

针对不同的内存开销场景，JDK本身就提供了多套无需自定义实现的大小计算能力，不需要手动拼接字节数：

小数据量场景 #

直接调用JDK原生API即可，结果和落盘文件大小100%对齐：

• 字符串转UTF-8字节数组后取长度：data.getBytes(StandardCharsets.UTF_8).length
• 基于字符串构造的ByteArrayInputStream，直接调用available()方法就能拿到流的总字节数，不需要逐段读流统计。

注意：这个方法会把完整的字节数组加载到内存，2GB规模的字符串转成字节数组时会占用2GB以上堆内存，有触发OOM的风险，不适合大体积数据场景。

大体积数据场景（2GB及以上规模） #

用JDK内置的CharsetEncoder直接计算编码后的字节总长度，不需要把完整字节数组加载到内存，内存开销极低，适配超大规模字符串的计算需求：

import java.nio.charset.StandardCharsets;
import java.nio.CharBuffer;
import java.nio.charset.CharsetEncoder;

public static long getEncodedStringSize(String data) {
    if (data == null) {
        return 0L;
    }
    CharsetEncoder encoder = StandardCharsets.UTF_8.newEncoder();
    // 仅计算编码需要的总字节数，不生成实际字节数组
    return encoder.calculateBytes(CharBuffer.wrap(data));
}

拿到字节总长度后，再换算成GB单位即可，换算时使用double精度避免误差：

double sizeInGB = byteSize / (1024.0 * 1024.0 * 1024.0);

• 不要用JVM内存中String的存储规则（UTF-16编码，每个char占2字节）计算落盘大小，落盘文件的大小完全由写入时指定的编码决定，和String在内存中的存储结构无关。
• 不要通过逐段读取InputStream流的方式统计大小，这种方式会重复占用流的读取逻辑，大流量场景下性能开销极高；基于字符串构造的流，完全可以在初始化时直接关联预计算的大小，不需要额外读流。

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