如何解决Azure AKS环境下PostgreSQL数据导出CSV时的Java堆内存溢出问题

兄弟，我一眼就看出问题出在哪了——你现在是把百万级数据一次性全加载到内存里啊！本地机器内存充裕，所以压得住，但AKS容器的内存是有硬限制的，可不就反复爆堆了嘛。结合你的代码和部署配置，给你几个实打实的解决思路：

1. 核心优化：分页查询+边处理边写CSV，别存全量数据 #

你当前的代码把所有查询结果存进objectList，再转成myEntityList，等于把百万条数据全放在内存里，这在容器环境里绝对扛不住。改成分页分批处理，而且处理一条就直接写入CSV，不要把所有实体存在列表里：

int pageSize = 1000; // 每次查1000条，可根据内存情况调整
int pageNum = 0;

while (true) {
    Query query = entityManager.createNativeQuery(sqlQuery)
            .setFirstResult(pageNum * pageSize)
            .setMaxResults(pageSize);
    
    List<Object[]> objectList = query.getResultList();
    if (objectList.isEmpty()) break; // 没有数据就退出循环

    // 直接处理当前页数据并写入CSV，不存全局列表
    objectList.forEach(glObject -> {
        MyEntity entity = MyEntity.builder()
                .supl_num(glObject[0])
                .detail(glObject[1])
                // ... 其他字段
                .build();
        writeToCsv(entity); // 这里直接写CSV，写完就释放内存
    });

    pageNum++;
    // 可选：手动触发GC，帮助容器及时回收内存
    System.gc();
}

2. 优化JVM堆内存配置，适配AKS容器限制 #

你的AKS容器limits设了2Gi内存，但JVM默认不会把所有容器内存都拿来当堆内存（默认MaxRAMPercentage是25%，也就是最多用512Mi堆）。你需要在应用启动参数里显式配置JVM堆的使用比例：

# 比如设置JVM可用堆内存为容器内存的75%，根据实际情况调整
java -XX:MaxRAMPercentage=75.0 -jar your-application.jar

注意：这只是辅助优化，核心还是要减少内存中的数据量，不然给再多堆内存也顶不住百万级全量加载。

3. 用JDBC流式查询绕过Hibernate的内存缓存 #

Hibernate的getResultList()会把所有查询结果加载到内存缓存里，哪怕分页也有一定开销。如果分页还不够，直接用JDBC的流式查询，逐行读取数据，完全不占大量内存：

Session session = entityManager.unwrap(Session.class);
session.doWork(connection -> {
    // PostgreSQL需要设置TYPE_FORWARD_ONLY和CONCUR_READ_ONLY，再把fetchSize设为Integer.MIN_VALUE开启流式
    try (PreparedStatement stmt = connection.prepareStatement(
            sqlQuery,
            ResultSet.TYPE_FORWARD_ONLY,
            ResultSet.CONCUR_READ_ONLY)) {
        stmt.setFetchSize(Integer.MIN_VALUE);
        
        try (ResultSet rs = stmt.executeQuery()) {
            while (rs.next()) {
                MyEntity entity = MyEntity.builder()
                        .supl_num(rs.getString(1))
                        .detail(rs.getString(2))
                        // ... 其他字段
                        .build();
                writeToCsv(entity); // 边读边写
            }
        }
    }
});

4. 检查AKS容器的实际内存分配 #

有时候虽然设置了limits为2Gi，但容器的requests只有256Mi，AKS调度时可能只给了刚好满足requests的内存，导致JVM堆内存被限制。你可以用命令查看Pod的实际内存使用：

kubectl top pods <你的Pod名称>

如果实际内存接近limits，要么适当调高limits（但这是治标），要么优先用前面的分页/流式方法从根源减少内存占用。

本质上，你遇到的问题就是内存中加载了超出容器承载能力的全量数据集，本地环境内存大所以没暴露，AKS的内存限制把这个问题放大了。优先用分页或流式处理，再配合JVM参数优化，就能彻底解决OOM问题。

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