大数据量集合序列化最稳妥的办法是避免一次性把全部数据加载到内存，改用流式处理或分页查询。

快速处理思路

// 错误示范：List<Item> all = service.getAll(); // 会导致 OOM
// 正确示范：流式写入（配合流式查询）
try (OutputStream out = new FileOutputStream("data.json")) {
    JsonGenerator generator = mapper.getFactory().createGenerator(out);
    generator.writeStartArray();
    // 确保 cursorIterator 是流式获取的，而非 List
    for (Item item : cursorIterator) { 
        mapper.writeValue(generator, item);
    }
    generator.writeEndArray();
}

为什么会这样

Java 默认的对象序列化机制以及常见的 JSON 库（如直接调用 writeValueAsString）通常需要先构建完整的对象图。这意味着在开始写入磁盘或网络之前，整个集合及其引用对象都必须驻留在堆内存中。当数据量达到百万级时，对象头开销和引用链会导致堆内存迅速膨胀，极易触发 Full GC 甚至 OOM。

公开资料中没有看到可靠的量化数据表明某种序列化协议能固定节省多少内存，因为这与对象结构强相关。但工程共识是：流式处理能将内存占用从 O(N) 降低到 O(1) 或 O(BufferSize)。

数据库流式查询实战

序列化优化必须配合数据获取层的优化，否则内存依然会在查询阶段爆满。仅优化序列化而保留全量查询无法解决 OOM 问题。

1. MyBatis Cursor 模式

// Mapper 接口
@Select("SELECT * FROM items WHERE status = 1")
@Options(resultSetType = ResultSetType.FORWARD_ONLY, fetchSize = 1000)
Cursor<Item> selectCursor();

// 使用方式
try (Cursor<Item> cursor = mapper.selectCursor()) {
    for (Item item : cursor) {
        // 序列化逻辑
    }
}

2. Spring Data JPA Stream 模式

// Repository 接口
Stream<Item> findAllByStatus(int status);

// 使用方式
try (Stream<Item> stream = repository.findAllByStatus(1)) {
    stream.forEach(item -> {
        // 序列化逻辑
    });
}

注意：必须关闭流或 Cursor，且事务配置需允许长事务或手动控制事务边界，避免 Transaction Timeout。

分步处理

1. 确认内存瓶颈
使用 jmap 或 VisualVM 生成堆转储文件，检查是否存在巨大的数组或集合实例。如果确认是集合本身占用过高，继续下一步。

2. 改造数据获取层
参考上方“数据库流式查询实战”，避免使用 selectAll() 类方法。改为基于游标（Cursor）或分页（Pagination）的迭代器模式。如果是数据库查询，启用流式结果集（如 JDBC 设置 fetchSize）。

3. 启用流式序列化
不要将整个 List 传给 JSON 库。使用支持 Streaming API 的库（如 Jackson 的 JsonGenerator 或 CSVMapper）。逐条读取数据，逐条写入输出流，写完后立即丢弃对象引用，方便 GC 回收。

4. 考虑二进制协议
如果网络传输也是瓶颈，可评估 Protobuf 或 Avro。这些格式比 JSON 更紧凑，但同样需要注意不要一次性构建整个 Message 列表，应使用流式写入。

怎么验证是否生效

1. 监控堆内存
在应用启动参数中加入 -Xlog:gc* 或使用监控工具。观察序列化任务执行期间，老年代内存是否出现阶梯式增长后回落，而不是一直上升直到 OOM。

2. 检查响应时间
流式处理通常会降低首字节时间（TTFB），因为不需要等全部数据序列化完成才开始传输。对比改造前后的接口响应曲线。

3. 压力测试
逐步增加数据量（如从 1 万到 10 万），观察内存增长是否线性。如果优化得当，内存峰值应保持在设定阈值内，不随数据量无限增长。

常见坑

1. 隐式的全量加载
某些 ORM 框架（如 Hibernate）在遍历关联集合时可能会触发懒加载，导致意外加载全部数据。确保迭代器配置正确，避免 N+1 查询问题。

2. 静态集合缓存
检查代码中是否有 static List 或 Map 用于暂存数据。这类集合的生命周期与 JVM 相同，极易造成内存泄漏。

3. 压缩带来的错觉
使用 GZIP 压缩输出流可以减小网络包大小，但压缩过程本身需要缓冲部分数据，可能短暂增加 CPU 和内存负担，需权衡使用。

4. 事务超时
流式查询通常持有数据库连接较长时间，需调整事务超时时间或手动管理事务，避免 Transaction Timeout 错误。

参考来源

• Oracle Java Documentation: Java Object Serialization Specification
• FasterXML Jackson Documentation: Streaming API
• MyBatis Documentation: Cursor Support