Excel早Yi不仅仅是那个用来Zuo简单报表的办公软件了它往往承载着企业Zui核心的业务数据迁移任务。但是作为一名在代码世界里摸爬滚打多年的开发者，你是否也曾经历过这样的“至暗时刻”：业务方甩给你一个动辄几百万甚至上千万行数据的Excel文件，让你在短时间内导入到系统中？当你满怀信心地点击“开始导入”，结果服务器内存飙升，直接OOM崩溃，那一刻的心情，简直比吃了苍蝇还难受。

别慌，今天我们就来掰开揉碎了聊聊，面对这种千万级数据的Excel导入需求，我们到底该如何优雅地、高效地解决它。这不仅仅是一段代码的优化，geng是一次对系统架构和底层原理的深刻反思。

在动手写代码之前，我们得先搞清楚Excel这个“老伙计”的脾气。hen多新手容易犯的一个错误就是低估了Excel格式的限制。

大家可Nengdou听说过Excel的行数是有上限的。对于古老的2003版格式，一个SheetZui多只Neng容纳65536行；到了2007及以后的版本，虽然上限提升到了1048576行，也就是一百多万行。但是请注意，这里说的是“一个Sheet”。Ru果你的业务数据达到了千万级别，hen显然单个Sheet是根本装不下的。这时候，通常的Zuo法是将数据分散到多个Sheet中，或者干脆转而使用CSV这种geng轻量级的格式。

然而行数限制只是表面上的“拦路虎”，真正的“隐形杀手”是内存占用。传统的Apache POI库在处理Excel时大多采用DOM解析模式。简单来说就是它会把整个Excel文件的所有内容，不管你用不用，一股脑地全部加载到内存中。想象一下一个几百万行的Excel文件，瞬间把你的JVM堆内存塞得满满当当，OOM也就不足为奇了。这就好比你想把整个图书馆的书dou搬回家，房子再大也装不下啊！

既然一次性把所有数据加载到内存行不通，那我们就换一种思路：Neng不Neng读一行，处理一行，读完就扔？这就是所谓的“流式读取”。

在Java领域，阿里开源的EasyExcel框架就是解决这个问题的神器。它基于SAX模式，不需要将文件全部加载到内存，而是像用吸管喝水一样，一点一点地从磁盘读取数据。这就极大地降低了内存的消耗，哪怕处理千万级的数据，内存占用依然Ke以控制在hen低的水平。

来kankan怎么用EasyExcel实现一个基本的读取逻辑。我们需要定义一个监听器，就像一个流水线上的工人，每来一批原材料，就处理一批。

public void readExcel {
    // 这里的read方法不会把文件全读进去，而是开启了一个流式通道
    EasyExcel.read).sheet.headRowNumber.doRead;
}
public class MySheetListener extends AnalysisEventListener {
    // 定义一个批次大小，比如每10万条处理一次
    private static final int DATA_SIZE = 100000;
    private List dataList = new ArrayList<>;
    @Override
    public void invoke {
        dataList.add;
        // 当累积的数据量达到阈值时触发保存操作
        if >= DATA_SIZE) {
            saveData;
            // 清空列表，释放内存，准备接收下一批
            dataList.clear;
        }
    }
    @Override
    public void doAfterAllAnalysed {
        // 别忘了文件读完了可Neng还有剩余的数据没达到阈值
        saveData;
    }
    private void saveData {
        // 这里执行具体的数据库保存逻辑
    }
}

通过这种方式，我们成功规避了OOM的风险。但是这只是万里长征的第一步。数据读进来了怎么存进去才够快？这才是性Neng优化的重头戏。

hen多开发者在拿到数据后习惯性地写一个for循环，然后每一条数据调用一次save方法。Ru果你也是这么写的，那恭喜你，你找到了性Neng低下的主要原因。

试想一下Ru果你有一千万条数据，每一条数据dou要建立一次数据库连接，发送一次SQL请求，然后等待响应。这种频繁的远程IO操作，简直就是性Neng杀手。网络延迟的累积效应会让你的导入程序慢如蜗牛。

解决方案hen简单：批量操作。不要一条一条地送，而是攒够了一车再送。

我们Ke以利用Google Guava工具包中的Lists类，它提供了非常方便的分区功Neng。我们Ke以把待保存的大列表切分成若干个小列表，每个列表包含1000条数据，然后一次性把这1000条数据写入数据库。

List saveList = Lists.newArrayList;
// 假设这里Yi经填充了saveList
// 将大列表切分成每份1000条的小列表
List partitionList = Lists.partition;
for  {
    // 批量保存，一次IO搞定1000条
    batchSave;
}

geng进一步，Ru果你对性Neng有着极致的追求，那么ORM框架自带的批量操作可Neng还不够给力。因为这些框架底层往往使用了反射，且生成的SQL语句可Neng不够精简。这时候，回归原始的JDBC，使用PreparedStatement进行真正的批处理，往往Neng带来意想不到的性Neng提升。

@Resource
private DataSource dataSource;
@Test
public void insertBatch throws Exception {
    Connection connection = dataSource.getConnection;
    // 关键点：关闭自动提交，开启事务
    connection.setAutoCommit;
    String sql = "insert into test values";
    PreparedStatement statement = connection.prepareStatement;
    for  {
        statement.setString;
        statement.setString;
        statement.setInt;
        statement.setInt;
        statement.setString;
        statement.setString;
        statement.setString;
        statement.setString;
        statement.setString;
        // 加入批处理包
        statement.addBatch;
    }
    long start = System.currentTimeMillis;
    // 一次性执行所有SQL
    statement.executeBatch;
    connection.commit;
    connection.close;
    statement.close;
}

虽然代码kan起来繁琐了一些，需要手动获取连接、预编译SQL，但执行效率的提升是实实在在的。实测表明，原生JDBC批处理的速度往往Neng比ORM快上好几倍。

解决了IO瓶颈，我们再来kankanCPU利用率。Ru果你的业务逻辑比较复杂，比如每条数据dou需要进行一系列的计算、转换或校验，那么单线程处理可Neng会显得力不从心。这时候，多线程并发就派上用场了。

Java中的CompletableFuture是实现异步编程的利器。我们Ke以利用它来开启多个线程并行处理数据，Zui后将结果汇总。不过这里有个坑需要注意：多线程环境下普通的ArrayList是不安全的，我们需要使用线程安全的集合，比如CopyOnWriteArrayList。

List resultList = Lists.newCopyOnWriteArrayList;
// 注意：一定要使用自定义的线程池，别用默认的ForkJoinPool
CompletableFuture.allOf
    .map(data -> 
        CompletableFuture.supplyAsync -> {
            // 这里进行耗时的业务逻辑处理
            return processBusiness;
        }, executor) // 指定线程池
        .whenComplete -> {
            // 处理完成后加入结果集
            resultList.add;
        })
    )
    .toArray
).join; // 等待所有任务完成
// Zui后统一批量保存resultList
batchSave;

但是多线程是一把双刃剑。Ru果线程数开得太多，线程之间频繁切换上下文，反而会导致CPU使用率飙升，系统卡顿。所以合理配置线程池的大小至关重要。通常建议将线程数设置为CPU核心数的2倍左右，或者根据具体的业务类型进行压测调整。

跑得快固然重要，但跑得稳geng重要。在导入海量数据时难免会遇到各种异常情况：网络抖动、数据库连接断开、数据格式错误，甚至是重复数据。

Ru果Excel中包含重复的主键数据，直接插入肯定会报错。Zui优雅的解决方案是在数据库表中给关键字段加上唯一索引。在插入SQL时Ke以使用insert ignore语法。这样，Ru果数据Yi存在数据库会直接忽略，而不会抛出异常中断整个流程。

网络抖动是常有的事。Ru果某一批数据因为网络原因插入失败，直接放弃显然不合适。我们Ke以引入一个“失败自动重试机制”。在捕获到数据库异常时尝试重新连接并插入2到3次。只要有一次成功，就算胜利。Ru果重试多次依然失败，再记录日志。

当数据量hen大时排查错误非常困难。建议在日志中记录批次编号，以及该批次中第一条和Zui后一条数据的关键信息。这样，一旦出错，我们Ke以迅速定位到是哪一段数据出了问题，是程序Bug还是数据本身的问题。

导入完成后千万别以为万事大吉了。一定要Zuo一个Zui后的校验：对比Excel文件中的总行数和数据库中实际插入成功的记录数。Ru果发现少了5万条，那说明中间有数据被丢弃或失败了。这时候，就需要根据日志去排查，或者生成一个只包含失败数据的Excel文件反馈给业务人员，让他们修正后重新导入。

回顾一下要搞定千万级Excel导入，我们并没有什么魔法，而是步步为营：

选对工具： 用EasyExcel替代POI，解决OOM内存溢出问题。

批量处理： 拒绝循环单条插入，使用JDBC批处理或Guava分区，减少IO开销。

并发加速： 合理利用多线程处理复杂业务，但要注意线程池管理。

稳健为王： 唯一索引防重、自动重试抗抖动、详细日志助排查、总量校验保平安。

其实技术本身并不复杂，难的是在面对海量数据时Neng否保持冷静的头脑，一层一层地剖析瓶颈，然后给出针对性的解决方案。希望这篇文章Neng成为你手中的利剑，下次再面对千万级Excel时Neng自信地说一句：“小菜一碟！”