1. 项目概述千万级数据导出的核心挑战去年负责某金融系统的数据迁移项目时我第一次真正体会到千万级数据导出的恐怖之处。当导出任务运行到300万条时JVM突然抛出OOM异常整个服务直接崩溃。这种量级的数据处理早已超出简单循环遍历的范畴而是对内存管理、IO效率、资源调度的全方位考验。千万级数据导出的典型特征包括数据体积按每条记录1KB计算1000万条数据≈10GB内存压力传统分页查询仍会导致堆内存积压时间成本单线程导出可能耗时数小时稳定性风险长时间运行易受网络/硬件波动影响2. 技术方案选型与对比2.1 常规方案的问题分析先看一个典型反例——使用MyBatis直接分页查询int pageSize 5000; for(int i0; ;i) { ListData list mapper.selectByPage(i*pageSize, pageSize); if(list.isEmpty()) break; // 导出操作 }这种方案存在三大致命缺陷深分页性能衰减页码越大查询越慢内存堆积每批数据都存活到Full GC事务风险长事务导致数据库连接占用2.2 优化方案技术栈经过多次压测验证最终采用的架构方案数据获取层游标查询 二级缓存 内存管理软引用队列 堆外内存 任务调度Spring Batch分区处理 输出处理NIO文件通道 ZIP流压缩3. 核心实现细节剖析3.1 游标查询的魔鬼细节使用JDBC游标时要注意这几个关键参数stmt.setFetchSize(5000); // 必须小于JDBC驱动缓冲区 conn.setAutoCommit(false); // 禁用自动提交 stmt.setFetchDirection(ResultSet.FETCH_FORWARD); // 单向遍历重要提示MySQL默认会无视fetchSize参数需要在连接串添加useCursorFetchtrue3.2 内存控制的三大防线对象池化复用DTO对象减少GC压力private static final ThreadLocalDataDTO dtoPool ThreadLocal.withInitial(DataDTO::new);堆外缓存对于大字段内容使用DirectBufferByteBuffer buffer ByteBuffer.allocateDirect(1024*1024);智能释放通过PhantomReference监控对象回收ReferenceQueueData queue new ReferenceQueue(); PhantomReferenceData ref new PhantomReference(data, queue);3.3 性能优化实战技巧写入优化采用NIO的FileChannel比普通FileOutputStream快3-5倍设置合适的Buffer大小建议8KB-32KB区间压缩技巧try(ZipOutputStream zos new ZipOutputStream(new FileOutputStream(...))) { zos.setLevel(Deflater.BEST_SPEED); // 速度优先 // 每20万条生成一个ZIP条目 }4. 分布式环境下的特殊处理当单机无法满足要求时需要考虑4.1 数据分片策略// 按照ID哈希分片 int shard recordId.hashCode() % shardCount;4.2 分布式事务控制采用最终一致性模式先快速导出到临时文件通过消息队列通知校验服务校验完成后执行原子替换5. 监控与异常处理体系5.1 内存监控看板MemoryMXBean memoryBean ManagementFactory.getMemoryMXBean(); MemoryUsage heapUsage memoryBean.getHeapMemoryUsage(); System.out.printf(已使用堆内存: %.2fMB%n, heapUsage.getUsed()/1024.0/1024);5.2 断点续传实现记录三个关键状态最后成功记录ID当前文件写入位置已处理分片标识6. 实战中的血泪教训OOM杀手发现JVM占用内存持续增长时立即用jmap生成堆转储jmap -dump:formatb,fileheap.hprof pid文件锁陷阱Windows系统下文件被占用时采用临时文件重命名策略连接泄漏务必在finally块关闭游标推荐使用try-with-resources时间校准分布式环境下所有节点必须使用NTP时间同步7. 性能对比数据在相同硬件环境下测试16核/32GB内存方案耗时CPU峰值内存峰值传统分页82分钟35%12GB游标堆外内存28分钟68%4GB分布式处理(4节点)9分钟85%2GB/节点8. 高级优化方向对于5000万以上的超大数据量列式存储改用Parquet等列式格式可减少50%IO零拷贝技术使用sendfile系统调用绕过用户空间GPU加速通过JCuda实现压缩算法的硬件加速最后分享一个诊断工具链内存分析Eclipse MATIO监控jstack lsof热点定位Async Profiler 千万级数据导出优化：游标查询与内存管理实战
1. 项目概述千万级数据导出的核心挑战去年负责某金融系统的数据迁移项目时我第一次真正体会到千万级数据导出的恐怖之处。当导出任务运行到300万条时JVM突然抛出OOM异常整个服务直接崩溃。这种量级的数据处理早已超出简单循环遍历的范畴而是对内存管理、IO效率、资源调度的全方位考验。千万级数据导出的典型特征包括数据体积按每条记录1KB计算1000万条数据≈10GB内存压力传统分页查询仍会导致堆内存积压时间成本单线程导出可能耗时数小时稳定性风险长时间运行易受网络/硬件波动影响2. 技术方案选型与对比2.1 常规方案的问题分析先看一个典型反例——使用MyBatis直接分页查询int pageSize 5000; for(int i0; ;i) { ListData list mapper.selectByPage(i*pageSize, pageSize); if(list.isEmpty()) break; // 导出操作 }这种方案存在三大致命缺陷深分页性能衰减页码越大查询越慢内存堆积每批数据都存活到Full GC事务风险长事务导致数据库连接占用2.2 优化方案技术栈经过多次压测验证最终采用的架构方案数据获取层游标查询 二级缓存 内存管理软引用队列 堆外内存 任务调度Spring Batch分区处理 输出处理NIO文件通道 ZIP流压缩3. 核心实现细节剖析3.1 游标查询的魔鬼细节使用JDBC游标时要注意这几个关键参数stmt.setFetchSize(5000); // 必须小于JDBC驱动缓冲区 conn.setAutoCommit(false); // 禁用自动提交 stmt.setFetchDirection(ResultSet.FETCH_FORWARD); // 单向遍历重要提示MySQL默认会无视fetchSize参数需要在连接串添加useCursorFetchtrue3.2 内存控制的三大防线对象池化复用DTO对象减少GC压力private static final ThreadLocalDataDTO dtoPool ThreadLocal.withInitial(DataDTO::new);堆外缓存对于大字段内容使用DirectBufferByteBuffer buffer ByteBuffer.allocateDirect(1024*1024);智能释放通过PhantomReference监控对象回收ReferenceQueueData queue new ReferenceQueue(); PhantomReferenceData ref new PhantomReference(data, queue);3.3 性能优化实战技巧写入优化采用NIO的FileChannel比普通FileOutputStream快3-5倍设置合适的Buffer大小建议8KB-32KB区间压缩技巧try(ZipOutputStream zos new ZipOutputStream(new FileOutputStream(...))) { zos.setLevel(Deflater.BEST_SPEED); // 速度优先 // 每20万条生成一个ZIP条目 }4. 分布式环境下的特殊处理当单机无法满足要求时需要考虑4.1 数据分片策略// 按照ID哈希分片 int shard recordId.hashCode() % shardCount;4.2 分布式事务控制采用最终一致性模式先快速导出到临时文件通过消息队列通知校验服务校验完成后执行原子替换5. 监控与异常处理体系5.1 内存监控看板MemoryMXBean memoryBean ManagementFactory.getMemoryMXBean(); MemoryUsage heapUsage memoryBean.getHeapMemoryUsage(); System.out.printf(已使用堆内存: %.2fMB%n, heapUsage.getUsed()/1024.0/1024);5.2 断点续传实现记录三个关键状态最后成功记录ID当前文件写入位置已处理分片标识6. 实战中的血泪教训OOM杀手发现JVM占用内存持续增长时立即用jmap生成堆转储jmap -dump:formatb,fileheap.hprof pid文件锁陷阱Windows系统下文件被占用时采用临时文件重命名策略连接泄漏务必在finally块关闭游标推荐使用try-with-resources时间校准分布式环境下所有节点必须使用NTP时间同步7. 性能对比数据在相同硬件环境下测试16核/32GB内存方案耗时CPU峰值内存峰值传统分页82分钟35%12GB游标堆外内存28分钟68%4GB分布式处理(4节点)9分钟85%2GB/节点8. 高级优化方向对于5000万以上的超大数据量列式存储改用Parquet等列式格式可减少50%IO零拷贝技术使用sendfile系统调用绕过用户空间GPU加速通过JCuda实现压缩算法的硬件加速最后分享一个诊断工具链内存分析Eclipse MATIO监控jstack lsof热点定位Async Profiler