前端时间因为项目中excel（2007）上传下载的所要支持的数据量剧增，所以研究学习了下大数据量excel的处理方式，并应用到product上去,这里简单recap下.主要有三点。
一 excel2003跟excel2007的区别。
03的excel是基于biff8格式的（项目目前不要求支持，所以这里不探讨），而到07，微软已经将其转换为基于开放式的 XML实现了,所以07的大数据量处理思路就变得清晰得多了：通过操作其XML的内容来达到读写excel的目的。
二 user model与event model的区别。
正常的POI代码操作模式即user model，他是将excel文件信息一次性读入内存，形成一些我们熟悉的结构，如Workbook、Sheet、Row、Cell等，而我们的开发则会基于这些内存中对象，只要给个列和行号，就可以读或写到excel中，开发相当便捷。不过其缺点也很明显，由于其是一次性读入内存，消耗的内存则可能会成为瓶颈，我做过个简单的测试，3000行30列的一个excel，大小在30K左右，其读入内存，形成POI的系列对象所消耗的内存已经达到40M左右，如果数据量继续增大则其内存消耗也会持续上涨，再考虑到用户并发操作，product上内存的消耗会是个比较大的问题。所以需要考虑采用其他的方式－－event model。
event model的方式不要求将excel的信息一次性的读入内存，他会按顺序读取excel的内容，从第一个sheet的第一行第一列开始，一直读到最后一个sheet的最后一处有值的地方结束，他不能够回头读，也不能跳着读，所以它要求应用程序一边读取数据，一边能够处理数据。这样的好处是内存消耗不大，也相对稳定，缺点就是其提供的API不够丰富，且具体实现的时候容易使excel的读取代码与业务逻辑的处理代码参杂在一起，难以阅读和维护。所以就是个权衡，如果数据量不大的话，user model是首选，而数据量可能会增大到会产生内存压力的时候，event model则是种解决方案了。
三 excel2007的XML组成结构
excel07就是一些XML文件的压缩包，可以将excel07的后缀改为zip，然后解压，可以信息地看到其XML组织结构。其中excel的主要信息都在文件夹xl下，其结构：
folder xl
comments1.xml(这是第一个sheet的comment信息)
comments2.xml(这是第二个sheet的comment信息，如果还有其他sheet有comment信息的话，还有comments3.xml...)
sharedStrings.xml(这是excel为减少文件大小所做的优化，excel所有的string值信息都存在此XML中，而
各个sheet具体的内容，如每个cell的值，都是会指向这个文件中的某个string值)
styles.xml(这是excel里所有的格式信息)
workbook.xml（这个XML可以得出excel所包含哪些sheet，都叫什么名字）
folder worksheets
sheet1.xml（这是第一个sheet的具体的值信息）
sheet2.xml（这是第二个sheet的具体的值信息）
sheet3.xml（这是第三个sheet的具体的值信息）
一般我们操作excel主要是读写sheet1.xml,sheet2.xml,sheet3.xml,因为我们最关注的信息都在这几个XML中，但读写具体值的时候，会指向sharedStrings.xml. 如，在某个sheet的某个cell值为“abc”，则在其对应的sheet.xml中会是<c t="s"><v>565</v></c>，c即表示cell,t表示type，"s"表示string,即值类型是个string,而565这个值则是指向sharedStrings.xml中索引为565对应的值，即“abc”.
其实这些都是微软定义excel结构的一些规则，了解下这个规则会对某些具体的代码实现（尤其是biggriddemo）会很有帮助，所以这里简单介绍了下。
具体的代码实现，可以参考已有的网上资源：
1.读 大数据量excel代码（event model）
http://gaosheng08.iteye.com/blog/624758
2.写 大数据量excel代码 (biggriddemo)
http://www.docjar.org/html/api/org/apache/poi/xssf/usermodel/examples/BigGridDemo.java.html
3.POI user model&event model相关
一 excel2003跟excel2007的区别。
03的excel是基于biff8格式的（项目目前不要求支持，所以这里不探讨），而到07，微软已经将其转换为基于开放式的 XML实现了,所以07的大数据量处理思路就变得清晰得多了：通过操作其XML的内容来达到读写excel的目的。
二 user model与event model的区别。
正常的POI代码操作模式即user model，他是将excel文件信息一次性读入内存，形成一些我们熟悉的结构，如Workbook、Sheet、Row、Cell等，而我们的开发则会基于这些内存中对象，只要给个列和行号，就可以读或写到excel中，开发相当便捷。不过其缺点也很明显，由于其是一次性读入内存，消耗的内存则可能会成为瓶颈，我做过个简单的测试，3000行30列的一个excel，大小在30K左右，其读入内存，形成POI的系列对象所消耗的内存已经达到40M左右，如果数据量继续增大则其内存消耗也会持续上涨，再考虑到用户并发操作，product上内存的消耗会是个比较大的问题。所以需要考虑采用其他的方式－－event model。
event model的方式不要求将excel的信息一次性的读入内存，他会按顺序读取excel的内容，从第一个sheet的第一行第一列开始，一直读到最后一个sheet的最后一处有值的地方结束，他不能够回头读，也不能跳着读，所以它要求应用程序一边读取数据，一边能够处理数据。这样的好处是内存消耗不大，也相对稳定，缺点就是其提供的API不够丰富，且具体实现的时候容易使excel的读取代码与业务逻辑的处理代码参杂在一起，难以阅读和维护。所以就是个权衡，如果数据量不大的话，user model是首选，而数据量可能会增大到会产生内存压力的时候，event model则是种解决方案了。
三 excel2007的XML组成结构
excel07就是一些XML文件的压缩包，可以将excel07的后缀改为zip，然后解压，可以信息地看到其XML组织结构。其中excel的主要信息都在文件夹xl下，其结构：
folder xl
comments1.xml(这是第一个sheet的comment信息)
comments2.xml(这是第二个sheet的comment信息，如果还有其他sheet有comment信息的话，还有comments3.xml...)
sharedStrings.xml(这是excel为减少文件大小所做的优化，excel所有的string值信息都存在此XML中，而
各个sheet具体的内容，如每个cell的值，都是会指向这个文件中的某个string值)
styles.xml(这是excel里所有的格式信息)
workbook.xml（这个XML可以得出excel所包含哪些sheet，都叫什么名字）
folder worksheets
sheet1.xml（这是第一个sheet的具体的值信息）
sheet2.xml（这是第二个sheet的具体的值信息）
sheet3.xml（这是第三个sheet的具体的值信息）
一般我们操作excel主要是读写sheet1.xml,sheet2.xml,sheet3.xml,因为我们最关注的信息都在这几个XML中，但读写具体值的时候，会指向sharedStrings.xml. 如，在某个sheet的某个cell值为“abc”，则在其对应的sheet.xml中会是<c t="s"><v>565</v></c>，c即表示cell,t表示type，"s"表示string,即值类型是个string,而565这个值则是指向sharedStrings.xml中索引为565对应的值，即“abc”.
其实这些都是微软定义excel结构的一些规则，了解下这个规则会对某些具体的代码实现（尤其是biggriddemo）会很有帮助，所以这里简单介绍了下。
具体的代码实现，可以参考已有的网上资源：
1.读 大数据量excel代码（event model）
http://gaosheng08.iteye.com/blog/624758
2.写 大数据量excel代码 (biggriddemo)
http://www.docjar.org/html/api/org/apache/poi/xssf/usermodel/examples/BigGridDemo.java.html
3.POI user model&event model相关
http://poi.apache.org/spreadsheet/how-to.html
http://poi.apache.org/spreadsheet/how-to.html#sxssf
http://svn.apache.org/repos/asf/poi/trunk/src/examples/src/org/apache/poi/xssf/eventusermodel/examples/FromHowTo.java 写几百M的数据 链接上有官方提供的例子。转自：http://googi.iteye.com/blog/1534274