点击这里查看原文

从BIFF8开始Office就使用SharedString方式保存字符串，使用共享字符串可以达到压缩文件的目的，但是POI使用的是inlineStr方式写字符串，easyexcel底层是POI所以自然的继承了这一方式，EEC默认也是使用inlineStr方式，可以使用注解@ExcelColumn(share = true)来使用SharedString方式。

上一篇我们对比了easyexcel和EEC两款工具在inlineStr模式下读写Excel文件的性能和内存，本文是对比系列的最后一篇，主要对比两款工具在SharedString模式下的读写性能以及Excel 97~2003格式读取性能。由于easyexcel不支持SharedString模式、EEC不支持xls格式写文件，所以本文只对比两个工具的读性能。

测试实体与上篇基本一致，只是添加了省/市/区3列文本，这3列值大概率重复(毕竟我国的省/市/区数据是确定的，有限的)，所有字符串均添加注解@ExcelColumn(share = true)强制使用SharedString模式。
具体测试细节可以查看上一篇，测试代码在这里eec-poi-compares

测试文件内容如下

1. 测试机器配置

硬件:

• CPU: 3 GHz Intel Core i5 (6核)
• 内存: 16 GB 3000 MHz DDR4
• 硬盘: Samsung SSD 970 PRO 512GB（267G可用）
• 系统: macOS 10.14.4

测试版本:

• easyexcel: 2.1.6
• EEC: 0.4.6
• EEC-E3-SUPPORT 0.4.6

2. xlsx格式读写

2.1. 64MB内存

限制内存64MB测试

先跑一个1w~100w的读写

CPU截图鼠标左边为EEC，右边为Easyexcel

64MBCPU测试截图

内存截图鼠标左边为EEC，右边为Easyexcel

64MB内存测试截图

与inlineStr模式相比两者速度差距有所拉大，EEC的读取速度超过easyexcel2倍

2.2. 32MB内存

限制内存32MB测试

从这里开始以下所有测试均只测试文件读取

CPU截图鼠标左边为EEC，右边为Easyexcel

32MBCPU测试截图

内存截图鼠标左边为EEC，右边为Easyexcel

32MB内存测试截图

在32MB限制下easyexcel内存一直处于满载状态，且GC占用CPU很高，速度仅为EEC的1/10〜1/20。

2.3. 探底EEC最低使用内存

经多次测试我最终运行在10MB处完成1~100w测试，测试过程中我发现数据量并不能直接影响内存。

CPU波动

10M_CPU

内存波动

10M_内存

Easyexcel在10MB下抛OOM错误，

com.alibaba.excel.exception.ExcelAnalysisException: java.lang.OutOfMemoryError: GC overhead limit exceeded

    at com.alibaba.excel.analysis.ExcelAnalyserImpl.analysis(ExcelAnalyserImpl.java:122)
    at com.alibaba.excel.ExcelReader.readAll(ExcelReader.java:160)
    at com.alibaba.excel.read.builder.ExcelReaderBuilder.doReadAll(ExcelReaderBuilder.java:275)
    ...
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
    at java.io.ObjectInputStream$BlockDataInputStream.readUTFBody(ObjectInputStream.java:3406)
    at java.io.ObjectInputStream$BlockDataInputStream.readUTF(ObjectInputStream.java:3226)
    at java.io.ObjectInputStream.readString(ObjectInputStream.java:1905)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1564)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)

3. xls格式读写

测试内容与上面完全一样，测试文件首先由EEC生成xlsx格式，然后再转为xls格式，代码如下

private void eecWritePaging(final String name, final int loop) throws IOException {
    new Workbook().addSheet(new ListSheet<LargeSharedData>() {
        int n = 0;
        @Override
        public List<LargeSharedData> more() {
            return n++ < loop ? createSharedData() : null;
        }
    }).setWorkbookWriter(new XMLWorkbookWriter() {
        @Override
        protected IWorksheetWriter getWorksheetWriter(Sheet sheet) {
            return new XMLWorksheetWriter(sheet) {
                /**
                 * xls每个Worksheet最大包含65536行x256列，所以这里设置分页
                 * 参数为{@code 65536-1}(去除第一行的表头)
                 * 
                 * @return 每页最大行限制
                 */
                @Override
                public int getRowLimit() {
                    return (1 << 16) - 1;
                }
            };
        }
    }).writeTo(defaultTestPath.resolve(name + ".xlsx"));
}

最终的测试文件如下：

进入主题开始测试吧

3.1 64MB内存

先跑一波64MB内存限制下1~100w的读操作

如上图，在64MB内存限制下，easyexcel只能完成1w数据的读测试，EEC则可以完成1〜100w的读测试。

easyexcel具体的报错信息

org.apache.poi.util.RecordFormatException: Unable to construct record instance

    at org.apache.poi.hssf.record.RecordFactory$ReflectionConstructorRecordCreator.create(RecordFactory.java:98)
    at org.apache.poi.hssf.record.RecordFactory.createSingleRecord(RecordFactory.java:345)
    at org.apache.poi.hssf.record.RecordFactoryInputStream.readNextRecord(RecordFactoryInputStream.java:289)
    at org.apache.poi.hssf.record.RecordFactoryInputStream.nextRecord(RecordFactoryInputStream.java:255)
    at org.apache.poi.hssf.eventusermodel.HSSFEventFactory.genericProcessEvents(HSSFEventFactory.java:175)
    at org.apache.poi.hssf.eventusermodel.HSSFEventFactory.processEvents(HSSFEventFactory.java:136)
    at org.apache.poi.hssf.eventusermodel.HSSFEventFactory.processWorkbookEvents(HSSFEventFactory.java:82)
    at org.apache.poi.hssf.eventusermodel.HSSFEventFactory.processWorkbookEvents(HSSFEventFactory.java:54)
    at com.alibaba.excel.analysis.v03.XlsSaxAnalyser.execute(XlsSaxAnalyser.java:112)
    at com.alibaba.excel.analysis.ExcelAnalyserImpl.analysis(ExcelAnalyserImpl.java:105)
    at com.alibaba.excel.ExcelReader.readAll(ExcelReader.java:160)
    at com.alibaba.excel.read.builder.ExcelReaderBuilder.doReadAll(ExcelReaderBuilder.java:275)
  ...
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
    at java.util.Arrays.copyOf(Arrays.java:3332)
    at java.lang.String.<init>(String.java:166)
    at org.apache.poi.hssf.record.RecordInputStream.readStringCommon(RecordInputStream.java:405)
    at org.apache.poi.hssf.record.RecordInputStream.readUnicodeLEString(RecordInputStream.java:376)
    at org.apache.poi.hssf.record.common.UnicodeString.<init>(UnicodeString.java:464)
    at org.apache.poi.hssf.record.SSTDeserializer.manufactureStrings(SSTDeserializer.java:57)
    at org.apache.poi.hssf.record.SSTRecord.<init>(SSTRecord.java:252)

从错误信息上发现在解析SSTRecord时抛OOM错误。SST即Shared String Table的简称，大概率是POI将SST中的字符串全部拉到内存导致OOM。SharedStringTable在EEC中的处理一文中有详细介绍SST在POI中的实现，感兴趣的朋友可以移步去了解一下。

3.2 10MB内存

10MB限制下easyexcel全军覆没，错误同上。

内存截图：

3.3 不限制内存

由于easyexcel未完成上面的测试，所以我决定放开限制再分别跑一次

对于xls格式的读取速度EEC远超Easyexcel，附两者测试CPU和内存截图，上面为easyexcel下面为EEC，不限制内存的情况下，前者最大分配7G堆内存，最大使用堆4.7G。EEC最大分配700MB，最大使用350MB。

CPU & RAM

我还发现一个有趣的现象，无论是EEC还是Easy excel，xls格式读取时间远小于xlsx

极限内存测试

在读取xls格式中，我分别对EEC和Easyexcel进行了极限内存测试，也就是跑完测试不抛异常时的最小内存，结果如下。

从上图可以看出随着文件逐渐增大easyexcel所需内存也逐渐增大，读取文件所需的内存甚至远远超过文件本身的大小，而EEC读文件所需内存一直比较平稳且远低于easyexcel，基本可以在10MB下完成大文件读取。

总结

通过前面的测试，我们对两款工具的便利性和性能有了一定的了解，与POI或easyexcel相比，EEC有着更新的设计理念，天然支持Worksheet分页、数据分片、支持高亮、支持流式读取、延迟读取等一些提高生产力的特性，且拥有更简洁、优雅的API也降低了接入成本。无论在速度优化还是内存控制方面EEC都远优于POI，毕竟POI是十几年前的产物，就算easyexcel在此基础上有极大改善但是与EEC相比还有一定差距，可以说EEC是目前所能找到的同类产品使用内存最小的工具，没有之一！！！

虽然EEC不支持xls的写入但瑕不掩瑜，尤其是微软已经停更xls格式多年，不支持xls格式写入也不会有太多功能损失。