使用ADL2存储同步I/O降低Java内存占用的技术问询

我们已经在用同步API，但内存占用依然失控的核心原因是：SDK默认的并行分块上传逻辑会为每个线程加载完整的分块数据到内存，总内存占用基本等于并行线程数 × 单块大小，再加上SDK内部的额外缓冲开销。以下是具体的解决办法：

1. 调整分块与并行参数，直接降低内存基数 #

• 不要使用过大的分块（如200MB/400MB）搭配高并行线程数，建议将单块大小控制在4MB~100MB之间（ADLS Gen2最小分块为4MB），同时将并行线程数降至4~8以内。
• 例如：将8线程200MB分块调整为8线程8MB分块，总内存占用会从1.6GB左右直接降到64MB左右（不含SDK额外开销）。

2. 使用SDK原生uploadFromFile方法，避免自定义流的额外缓冲 #

不要自行实现MarkableFileInputStream后手动分块，直接用SDK提供的文件上传方法，通过ParallelTransferOptions严格控制内存：

import com.azure.storage.blob.BlobClient;
import com.azure.storage.blob.models.ParallelTransferOptions;

public void uploadWithControlledMemory(BlobClient blobClient, String filePath) {
    ParallelTransferOptions transferOpts = new ParallelTransferOptions()
        .setBlockSizeLong(8 * 1024 * 1024) // 单块8MB
        .setMaxConcurrency(4) // 并行4线程
        .setProgressReceiver(progress -> {
            // 可选：上传进度回调
        });

    // SDK会自动处理分块，仅缓冲当前正在上传的分块数据
    blobClient.uploadFromFile(filePath, transferOpts);
}

这个方法内部会直接读取文件内容，不会一次性加载整个文件或分块到内存，内存占用严格受blockSize和maxConcurrency控制。

3. 针对自定义流场景，强制配置缓冲大小 #

如果必须使用自定义流（如你的MarkableFileInputStream），需要在上传配置中显式设置缓冲大小，避免SDK内部额外的大缓冲：

import com.azure.storage.blob.BlobClient;
import com.azure.storage.blob.models.BlobUploadOptions;
import com.azure.storage.blob.models.ParallelTransferOptions;
import java.io.InputStream;

public void uploadFromCustomStream(BlobClient blobClient, InputStream customStream, long fileSize) {
    ParallelTransferOptions transferOpts = new ParallelTransferOptions()
        .setBlockSizeLong(8 * 1024 * 1024)
        .setMaxConcurrency(4)
        .setBufferSize(8 * 1024 * 1024); // 缓冲大小与分块一致，消除额外缓冲

    BlobUploadOptions uploadOpts = new BlobUploadOptions(customStream)
        .setParallelTransferOptions(transferOpts)
        .setLength(fileSize); // 必须指定文件长度，否则SDK会缓冲整个流

    blobClient.uploadWithResponse(uploadOpts, null, null);
}

注意：自定义流必须支持mark()/reset()，但SDK仅在需要重试时才会使用标记功能，正常上传时不会预加载整个分块。

4. 升级SDK到最新稳定版 #

旧版本的SDK可能存在内存泄漏或不必要的缓冲逻辑，建议升级到Azure Storage Blob Java SDK v12的最新稳定版（如v12.25.x及以上），官方可能已修复部分内存相关问题。

5. 手动控制分块上传，完全掌握内存 #

如果上述方法都无法满足需求，可以直接使用低级别分块API，手动逐块读取并上传，每次仅加载一个分块到内存：

import com.azure.storage.blob.BlobClient;
import com.azure.storage.blob.specialized.BlockBlobClient;
import java.io.ByteArrayInputStream;
import java.io.RandomAccessFile;
import java.util.Base64;
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

public void manualBlockUpload(BlobClient blobClient, String filePath) throws Exception {
    BlockBlobClient blockBlobClient = blobClient.getBlockBlobClient();
    long blockSize = 8 * 1024 * 1024; // 8MB单块

    try (RandomAccessFile raf = new RandomAccessFile(filePath, "r")) {
        long fileSize = raf.length();
        int blockCount = (int) Math.ceil((double) fileSize / blockSize);

        // 逐块读取并上传
        for (int i = 0; i < blockCount; i++) {
            long start = i * blockSize;
            long end = Math.min(start + blockSize, fileSize);
            int chunkSize = (int) (end - start);
            byte[] blockData = new byte[chunkSize];
            
            raf.seek(start);
            raf.readFully(blockData);

            // 上传单个分块
            String blockId = Base64.getEncoder().encodeToString(String.format("%05d", i).getBytes());
            blockBlobClient.stageBlock(blockId, new ByteArrayInputStream(blockData), chunkSize);
        }

        // 提交所有分块，完成上传
        List<String> blockIds = IntStream.range(0, blockCount)
            .mapToObj(i -> Base64.getEncoder().encodeToString(String.format("%05d", i).getBytes()))
            .collect(Collectors.toList());
        blockBlobClient.commitBlockList(blockIds);
    }
}

这种方式的内存占用仅为单块大小加上少量SDK开销，完全可控。

补充说明 #

同步API本身并不能直接降低内存消耗，关键是要控制SDK加载到内存中的数据量——通过减小分块大小、降低并行度，或者直接接管分块逻辑，才能从根源上解决内存过高的问题。

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