批处理框架SpringBatch，数据迁移量过大如何保证内存

　　概述
　　本篇博客是记录使用springbatch做数据迁移时时遇到的一个关键问题：数据迁移量大时如何保证内存。当我们在使用springbatch时，我们必须配置三个东西：reader，processor，和writer。
　　其中，reader用于从数据库中读数据，当数据量较小时，reader的逻辑不会对内存带来太多压力，但是当我们要去读的数据量非常大的时候，我们就不得不考虑内存等方面的问题，因为若数据量非常大，内存，执行时间等等都会受到影响。问题是什么
　　在上面的内容当中我们已经提到了，我们面临的问题是数据迁移量大时的内存问题。但是这样的描述非常笼统，因此博主决定将这一部分单独拎出来说。
　　在学习了springbatch的知识之后我们应该很清楚的一点是，每一个springbatch的step都包含如下的部分：
　　即读数据，处理数据，写数据。这三个步骤里面最可能会导致内存变大问题的无疑是读数据环节。读数据作为springbatch的数据输入，是整个springbatchjob的开头逻辑。
　　若我们的数据量不大，如只有几十万条，那我们无疑不会面临内存问题，即便一次将所有数据加载到内存当中，占的内存也不会非常多，且springbatch数据迁移的速度非常之快，几十万条的数据往往是几十秒的时间就可以迁移完成。但是当数据量变大之后，问题就不一样了。
　　当我们的数据量达到数百万或上千万时，若一次性将所有数据全部读到内存当中，则会占据远远超出正常范围的非常大的内存。该问题示意图如下所示：
　　我们写的任何程序都会有一个运行内存，假设这个内存的总容量现在只有4g，而我们数据库里需要操作的数据有8g，那么无疑，一次性的将数据读出来就会出错。这便是需要考虑得问题。Spring提供的reader实现
　　spring提供了非常丰富的Reader实现，其中比较常用的从数据库读数据的有JdbcCursorItemReader，JdbcPagingItemReader等。JdbcCursorItemReader
　　使用JdbcCursorItemReader的示例代码如下：BeanpublicJdbcCursorItemReaderCustomerCredititemReader（）｛returnnewJdbcCursorItemReaderBuilderCustomerCredit（）。dataSource（this。dataSource）。name（creditReader）。sql（selectID，NAME，CREDITfromCUSTOMER）。rowMapper（newCustomerCreditRowMapper（））。build（）；｝
　　JdbcCursorItemReader的好处在于使用简单，但是我们从它的sql就能发现，JdbcCursorItemReader会一次把所有的数据全部拿回来，当数据量过大而服务器内存不够时，就会遇到下面无法分配内存的问题：
　　报错信息为：Resourceexhaustionevent：TheJVMwasunabletoallocatememoryfromtheheap。意思就是需要分配内存的数据太多，但是无法找到足够的内存了。
　　反映在内存里，堆内存会呈现出如下的情况：
　　随着每一次数据读入，堆内存都会增大，原因就在于JdbcCursorItemReader一次性读回了所有的数据，返回之后就会存在一个对象里面，而这个对象的尺寸过大，因此直接进入了老年代。在数据迁移完成之前，这些数据都不会被回收。如下图所示：
　　毫无疑问，当我们的数据量大时不应该使用这种类型的reader来读取数据。JdbcPagingItemReader
　　JdbcPagingItemReader的作用和它的名字一样，它可以分页读取数据，但是使用起来相比于JdbcCursorItemReader更加复杂，示例代码如下：BeanpublicJdbcPagingItemReaderitemReader（DataSourcedataSource，PagingQueryProviderqueryProvider）｛MapString，ObjectparameterValuesnewHashMap（）；parameterValues。put（status，NEW）；returnnewJdbcPagingItemReaderBuilderCustomerCredit（）。name（creditReader）。dataSource（dataSource）。queryProvider（queryProvider）。parameterValues（parameterValues）。rowMapper（customerCreditMapper（））。pageSize（1000）。build（）；｝BeanpublicSqlPagingQueryProviderFactoryBeanqueryProvider（）｛SqlPagingQueryProviderFactoryBeanprovidernewSqlPagingQueryProviderFactoryBean（）；provider。setSelectClause（selectid，name，credit）；provider。setFromClause（fromcustomer）；provider。setWhereClause（wherestatus：status）；provider。setSortKey（id）；returnprovider；｝
　　可以看到我们能够设置page的大小，JdbcPagingItemReader将根据这个页的大小，每次读取这么多的数据，因此这些数据返回保存的对象，就只会是小对象，因此他们不会直接在老年代里分配，而是先分配在年轻代，随着年轻代不断变大，minorgc也不断进行，回收掉已经处理完的数据，老年代的内存使用量不会有任何增大，类似下图：
　　老年代内存不会有任何变化，年轻带会随着服务器数据迁移进行而增大同时被回收。
　　在使用JdbcPagingItemReader时，有一个必须注意的地方就是排序关键字是必须指定的，原因在于排序是分页实现原理的技术基础。sortKey和我们指定的其他字句一起构建出SQL语句出来。在sortKey上必须使用uniquekeyconstraint约束，因为只有这样才能得以确保执行之间不会丢失任何数据。这也可以说是JdbcCursorItemReader相对便利的一点优势。总结
　　数据量小时选择的方案差别不会很大，当数据量大时，为了有好的内存表现则使用分页的reader是必要的。但同时，因为要实现分页，也会带来一些不可避免的限制。