使用MicroStream与AWS S3作为Blob存储时遇内存溢出问题求助

问题原因分析 #

1. 内存累积过载：一次性向HashMap插入100万条数据，所有对象都驻留在堆内存中直接触发OOM；同时使用LazyStorer未分批提交，所有变更都缓存到内存直到最终commit，进一步加剧内存压力。
2. 类型转换错误：最后读取根对象时错误地将HashMap<Integer, Object>转为Map<String, Object>，后续会引发ClassCastException（当前OOM掩盖了这个问题）。
3. S3缓存未限制：默认的S3缓存可能存储大量Blob元数据或内容，占用额外内存。

解决方案 #

以下是修改后的代码及关键优化点：

修改后的完整代码

S3Client cli = S3Client.builder()
      .region(Region.US_EAST_1)
      .credentialsProvider(StaticCredentialsProvider.create(
            AwsSessionCredentials.create(accessKey, secret, token)))
      .build();

// 限制S3缓存条目数，避免缓存过多数据占用内存
BlobStoreFileSystem fileSystem = BlobStoreFileSystem.New(
      S3Connector.Caching(cli, 100)
);

final EmbeddedStorageManager storageManager = EmbeddedStorage.start(fileSystem.ensureDirectoryPath("s3-folder"));

HashMap<Integer, Object> database;

// 初始化或加载根对象
if (storageManager.root() == null) {
   database = new HashMap<>();
   storageManager.setRoot(database);
   storageManager.storeRoot();
   storageManager.commit(); // 提交初始根对象
} else {
   database = (HashMap<Integer, Object>) storageManager.root();
}

int batchSize = 10000; // 每10000条数据提交一次
for(int i=0; i < 1_000_000; i++) {
   database.put(i, UUID.randomUUID().toString());

   if (i == 500_000) {
      System.out.println("Value: " + database.get(500_000));
   }

   // 达到批次大小就提交，释放内存
   if ((i + 1) % batchSize == 0) {
      storageManager.store(database);
      storageManager.commit();
      // 可选：触发GC回收内存（生产环境按需使用）
      System.gc();
   }
}

// 提交最后一批剩余数据
storageManager.store(database);
storageManager.commit();

// 读取数据时使用正确的类型
System.out.println("*************************");
System.out.println(database.get(500_000));

storageManager.shutdown();

关键优化说明

• 分批提交：将100万条数据拆分为多个批次提交，每批次完成后将数据刷入S3并释放内存，避免单批次内存过载。
• 限制S3缓存：通过S3Connector.Caching(cli, 100)设置缓存条目数，防止缓存过多Blob对象占用额外内存。
• 修正类型转换：直接使用强转后的database对象读取数据，避免不必要的类型转换错误。
• 初始根对象提交：设置根对象后立即提交，确保MicroStream正确持久化初始状态，避免后续操作出现不一致。

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