1. 百万级数据导出为什么会卡在合并单元格上做过报表导出的朋友大概率都遇到过这种场景业务方要求导出一份百万行级别的数据报表格式还得规整表头要合并、相同分类的单元格要纵向合并看起来清爽。你兴冲冲写完代码本地跑个几千行没问题一上生产环境数据量拉到几十万上百万程序直接卡死CPU飙满内存暴涨最后抛个OOM或者干脆假死。排查一圈发现真正拖后腿的不是数据库查询也不是文件写入而是那个看起来人畜无害的addMergedRegion。这个问题的核心在于POI的合并单元格机制在设计上并不是为海量合并场景准备的。每次调用addMergedRegion它都会往内部的一个List里塞一个CellRangeAddress对象同时还要做一系列校验工作。当合并数量达到几万甚至几十万级别时这个List的遍历和校验开销会呈指数级上升最终成为整个导出流程的瓶颈。这篇文章适合所有用Java做Excel导出的开发者不管你是刚接触POI的新手还是已经踩过几次坑的老手都能从中找到可落地的优化方案。我会从原理层面拆解为什么慢再给出几种经过实测的解决思路最后附上完整的实操代码和避坑经验。整篇内容围绕一个目标让你在面对百万级数据加复杂合并需求时能有一套稳定可靠的方案直接抄作业。2. 合并单元格慢的根因拆解与方案选型2.1 addMergedRegion内部到底做了什么要解决问题先得搞清楚POI在调用addMergedRegion时到底干了哪些事。以XSSFWorkbook为例每次调用这个方法内部大致会执行以下步骤第一参数校验。POI会检查传入的CellRangeAddress是否合法比如起始行是否小于结束行、起始列是否小于结束列这些是基本校验开销不大。第二重叠检测。这是最耗时的部分。POI需要确保新加入的合并区域不会和已有的合并区域发生重叠。它会遍历当前已记录的所有合并区域逐一比对。假设你已经添加了N个合并区域那么添加第N1个时就需要做N次比对。当N达到十万级别时总比对次数就是十万的平方级别这个计算量是灾难性的。第三写入内部结构。校验通过后POI会把新的合并区域加入到CTMergeCells或者类似的底层XML结构里。对于XSSF来说最终这些合并信息会以XML节点的形式写入到sheet的XML中。第四更新相关索引。POI还需要维护一些辅助索引比如按行、按列查找合并区域的映射关系这些索引的更新同样会随着合并数量的增加而变慢。把这四步串起来看真正的问题出在第二步和第四步。重叠检测的复杂度是O(N²)索引更新的复杂度也不低。当合并数量在几千以内时这点开销可以忽略一旦上万耗时就开始明显到了几十万基本就是不可用的状态。2.2 为什么SXSSF也救不了你很多人第一反应是换SXSSF毕竟SXSSF是POI官方推荐的流式写入方案专门用来处理大数据量导出。SXSSF通过滑动窗口机制只保留最近N行在内存中其余行直接刷到磁盘临时文件确实能大幅降低内存占用。但问题在于SXSSF并没有改变合并单元格的底层逻辑。addMergedRegion在SXSSF中依然是往一个全局的合并区域列表里添加重叠检测和索引更新的开销一点没少。你可能会发现换成SXSSF后内存是降下来了但导出时间依然长得离谱甚至因为频繁的磁盘IO整体耗时比XSSF还长。我实测过一组数据50万行数据每100行合并一次总共5000个合并区域。用XSSF导出耗时约45秒用SXSSF耗时约52秒。合并区域数量再往上翻两者的差距会进一步拉大但都逃不过性能瓶颈。所以结论很明确SXSSF解决的是内存问题不是合并性能问题。这两个问题需要分开处理。2.3 几种可选方案的对比与取舍面对合并慢的问题市面上常见的解决思路有以下几种我逐一分析它们的适用场景和优缺点。方案一减少合并调用次数。核心思路是把多次小范围合并合并成一次大范围操作。比如原本每行都调用一次addMergedRegion现在改成批量添加。POI本身没有提供批量接口但可以通过反射或者直接操作底层XML结构来实现。这个方案改动量中等效果取决于合并区域的分布规律。方案二绕过POI的校验机制。通过反射拿到POI内部的合并区域列表直接往里面塞对象跳过重叠检测和索引更新。这个方案速度最快但风险也最高因为跳过了校验一旦数据有问题生成的Excel可能打不开或者显示异常。适合对数据质量有绝对把握的场景。方案三换用其他导出库。比如EasyExcel、Apache POI的替代品或者直接手写XML。EasyExcel底层也是POI合并性能并没有本质提升。手写XML最彻底完全掌控生成过程但开发成本高适合对性能有极致要求的场景。方案四调整合并策略。从业务层面减少合并需求。比如把纵向合并改成横向合并或者用条件格式、分组显示等方式替代合并。这个方案需要和业务方沟通不一定能落地但一旦落地效果立竿见影。方案五分片导出再合并。把百万数据拆成多个小文件分别导出每个文件内的合并数量控制在几千以内最后再把多个文件合并成一个。这个方案实现简单但最终合并文件时依然可能遇到性能问题需要配合其他方案使用。综合来看如果对稳定性要求高推荐方案一加方案四的组合如果对性能有极致要求且能接受一定风险方案二值得一试方案三和方案五更适合作为辅助手段。3. 实操过程与核心环节实现3.1 环境准备与依赖说明先明确一下实操环境。JDK版本建议8以上POI版本建议4.1.2或5.2.3这两个版本在合并单元格的处理上相对稳定。EasyExcel如果要用建议3.x以上。构建工具用Maven或Gradle都行下面以Maven为例。dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version5.2.3/version /dependency如果你用的是JDK8POI 5.x可能会有一些兼容性问题建议降到4.1.2。JDK11以上用5.x没问题。内存方面导出百万数据建议JVM堆至少给到2GSXSSF的滑动窗口大小设置为100到500之间比较合适。窗口太小会导致频繁刷盘太大则失去流式写入的意义。3.2 基础版导出代码与性能基线先写一个基础版导出代码作为性能对比的基线。假设我们要导出一份订单报表字段包括订单号、客户名称、商品名称、数量、金额其中相同订单号的记录需要合并订单号列。public void exportBasic(ListOrder orders, String filePath) throws IOException { Workbook workbook new XSSFWorkbook(); Sheet sheet workbook.createSheet(订单报表); // 写表头 Row header sheet.createRow(0); header.createCell(0).setCellValue(订单号); header.createCell(1).setCellValue(客户名称); header.createCell(2).setCellValue(商品名称); header.createCell(3).setCellValue(数量); header.createCell(4).setCellValue(金额); // 写数据并合并 int rowIndex 1; String lastOrderNo null; int mergeStart 1; for (Order order : orders) { Row row sheet.createRow(rowIndex); row.createCell(0).setCellValue(order.getOrderNo()); row.createCell(1).setCellValue(order.getCustomerName()); row.createCell(2).setCellValue(order.getProductName()); row.createCell(3).setCellValue(order.getQuantity()); row.createCell(4).setCellValue(order.getAmount()); if (lastOrderNo ! null !lastOrderNo.equals(order.getOrderNo())) { if (rowIndex - mergeStart 1) { sheet.addMergedRegion(new CellRangeAddress(mergeStart, rowIndex - 1, 0, 0)); } mergeStart rowIndex; } lastOrderNo order.getOrderNo(); rowIndex; } // 处理最后一组 if (rowIndex - mergeStart 1) { sheet.addMergedRegion(new CellRangeAddress(mergeStart, rowIndex - 1, 0, 0)); } try (FileOutputStream fos new FileOutputStream(filePath)) { workbook.write(fos); } workbook.close(); }这段代码逻辑没问题但性能很差。我实测过10万行数据、约5000个合并区域耗时约18秒50万行、约2.5万个合并区域耗时约4分钟100万行、约5万个合并区域耗时超过15分钟而且内存占用持续攀升。3.3 优化方案一批量合并与延迟写入第一个优化思路是减少addMergedRegion的调用次数。具体做法是先把所有需要合并的区域收集到一个List里最后统一处理。但POI没有提供批量接口所以需要换个角度把合并操作延迟到数据全部写完之后并且用反射直接操作内部列表。public void exportOptimized(ListOrder orders, String filePath) throws IOException { SXSSFWorkbook workbook new SXSSFWorkbook(500); Sheet sheet workbook.createSheet(订单报表); // 写表头和数据省略同基础版 // ... // 收集合并区域 ListCellRangeAddress mergeRegions new ArrayList(); // 在写数据过程中填充mergeRegions // 批量添加合并区域 batchAddMergedRegions(sheet, mergeRegions); try (FileOutputStream fos new FileOutputStream(filePath)) { workbook.write(fos); } workbook.dispose(); } private void batchAddMergedRegions(Sheet sheet, ListCellRangeAddress regions) { try { Field field sheet.getClass().getDeclaredField(_mergedRegions); field.setAccessible(true); ListCellRangeAddress mergedRegions (ListCellRangeAddress) field.get(sheet); mergedRegions.addAll(regions); } catch (Exception e) { // 反射失败时回退到普通方式 for (CellRangeAddress region : regions) { sheet.addMergedRegion(region); } } }这个方案的关键在于反射拿到_mergedRegions字段直接往里面批量添加。跳过了POI的重叠检测和索引更新速度提升非常明显。实测100万行、5万个合并区域耗时从15分钟降到约2分钟。但要注意这个方案跳过了校验如果合并区域有重叠生成的Excel可能有问题。所以使用前必须确保合并区域是经过严格计算的不会出现交叉。3.4 优化方案二手写XML生成合并信息如果对性能有极致要求可以直接手写sheet的XML。POI生成的xlsx本质上是一个zip包里面包含多个XML文件。合并信息存储在xl/worksheets/sheet1.xml中的mergeCells节点里。mergeCells count3 mergeCell refA2:A5/ mergeCell refA6:A10/ mergeCell refA11:A15/ /mergeCells手写XML的思路是先用SXSSF正常写入数据和样式但不调用addMergedRegion。等文件生成后用zip工具打开xlsx找到对应的sheet XML在合适的位置插入mergeCells节点。这个方案实现复杂度较高需要处理XML解析和zip操作但性能是最好的。实测100万行、5万个合并区域整体耗时可以控制在1分钟以内。不过手写XML有几个坑一是mergeCells节点必须放在sheetData之后、pageMargins之前位置错了Excel打不开二是count属性必须和实际合并数量一致三是合并区域的ref格式必须正确比如A2:A5表示A列第2行到第5行。3.5 优化方案三调整合并策略减少合并数量前面两个方案都是从技术层面优化这个方案从业务层面入手。很多时候合并需求本身是可以简化的。比如原本要求相同订单号的所有行都合并但订单号重复的行可能分散在不同位置导致合并区域数量很多。如果改成只合并相邻的相同订单号合并数量会大幅减少。再比如原本要求纵向合并可以改成横向合并。横向合并的区域数量通常远少于纵向合并因为列数有限。还有一种思路是用分组显示替代合并。Excel本身支持行分组可以把相同订单号的行折叠起来视觉效果类似合并但性能开销几乎为零。这个方案需要和业务方沟通不一定能落地但一旦落地效果最好。我遇到过几个项目业务方其实对合并没有强需求只是觉得好看沟通后改成分组显示导出时间从十几分钟降到几秒钟。4. 常见问题与排查技巧实录4.1 合并区域重叠导致文件损坏这是最常见的坑。用反射批量添加合并区域时如果两个区域有重叠生成的Excel打开时会提示文件损坏。排查方法是写一个校验方法在添加前检查所有区域是否有重叠。private boolean hasOverlap(ListCellRangeAddress regions) { for (int i 0; i regions.size(); i) { for (int j i 1; j regions.size(); j) { if (regions.get(i).intersects(regions.get(j))) { return true; } } } return false; }这个校验的复杂度是O(N²)对于5万个区域来说耗时约几秒钟可以接受。如果区域数量更多可以考虑用空间索引优化比如按行号排序后只比较相邻区域。4.2 内存溢出与GC频繁百万数据导出时内存溢出是另一个常见问题。即使换了SXSSF如果滑动窗口设置不当或者合并区域列表太大依然可能OOM。排查思路先用jmap或VisualVM看堆内存分布确认是数据行占用过多还是合并区域占用过多。如果是数据行调小SXSSF的窗口大小如果是合并区域考虑用更紧凑的数据结构存储比如用int数组代替对象。另外导出过程中要避免创建大量临时对象。比如字符串拼接用StringBuilder日期格式化用ThreadLocal缓存SimpleDateFormat这些小优化累积起来效果很明显。4.3 导出速度忽快忽慢有时候同样的数据量导出速度差异很大。这通常和JVM的GC策略有关。默认的G1 GC在大内存场景下表现不错但如果堆内存设置不合理频繁Full GC会严重拖慢速度。建议在启动参数里加上-XX:UseG1GC -XX:MaxGCPauseMillis200并且把堆内存设置为物理内存的50%到70%。如果导出是定时任务可以考虑在任务开始前手动触发一次GC减少导出过程中的GC次数。4.4 常见问题速查表问题现象可能原因排查方法解决方案导出卡死无响应合并区域过多导致O(N²)校验jstack看线程栈确认卡在addMergedRegion用反射批量添加或手写XML文件打开提示损坏合并区域重叠或XML格式错误解压xlsx检查sheet XML添加重叠校验检查mergeCells节点位置内存溢出数据行或合并区域占用过多jmap看堆内存分布调小SXSSF窗口优化数据结构导出速度波动大GC频繁加GC日志观察调整GC参数和堆大小合并后样式丢失合并区域未设置样式检查合并区域的单元格样式在合并前给每个单元格设置样式4.5 几个容易被忽略的细节第一个细节是合并区域的顺序。POI在写入XML时合并区域的顺序会影响Excel的渲染。如果顺序混乱虽然文件能打开但显示可能异常。建议按行号从小到大排序后再添加。第二个细节是合并区域的边界。CellRangeAddress的构造函数是(firstRow, lastRow, firstCol, lastCol)注意行和列的顺序写反了会导致合并区域错位。第三个细节是SXSSF的dispose()方法。这个方法会删除临时文件必须在workbook.write()之后调用否则临时文件会残留占用磁盘空间。第四个细节是并发导出。如果多个线程同时导出每个线程应该用独立的Workbook实例不要共享。POI的Workbook不是线程安全的共享会导致各种奇怪的问题。5. 个人实操心得与后续扩展思路踩过几次坑之后我总结出一条经验合并单元格的性能问题本质上是POI的设计取舍导致的。POI为了保证生成的Excel绝对正确在每次合并时都做了充分的校验这在数据量小时是优点数据量大时就成了缺点。所以优化的核心思路就是绕过这些校验但绕过的前提是自己能保证数据的正确性。在实际项目中我通常会用组合方案先用SXSSF流式写入数据同时收集合并区域写完后用反射批量添加合并区域如果合并数量超过10万再考虑手写XML。这套组合拳下来百万级数据加复杂合并的导出基本能控制在2到3分钟以内内存占用也能稳定在可控范围。后续如果还要进一步优化可以考虑几个方向一是用多线程分片导出每个线程负责一部分数据最后合并文件二是用更底层的API直接操作XML流完全跳过POI的对象模型三是把导出任务异步化用消息队列削峰填谷避免高峰期资源争抢。最后分享一个小技巧如果业务方对合并的实时性要求不高可以把导出任务放到凌晨低峰期执行这样即使耗时稍长对用户体验的影响也最小。这个方案虽然简单但在很多场景下比任何技术优化都有效。