概述
本篇博客是記錄使用spring batch做數據遷移時時遇到的一個關鍵問題：數據遷移量大時如何保證內存。當我們在使用spring batch時，我們必須配置三個東西: reader，processor，和writer。其中，reader用于從數據庫中讀數據，當數據量較小時，reader的邏輯不會對內存帶來太多壓力，但是當我們要去讀的數據量非常大的時候，我們就不得不考慮內存等方面的問題，因為若數據量非常大，內存，執行時間等等都會受到影響。關于spring batch的基礎知識和介紹請參考這篇博客： 批處理框架spring batch介紹及使用。
問題是什么
在上面的內容當中我們已經提到了,我們面臨的問題是數據遷移量大時的內存問題。但是這樣的描述非常籠統，因此博主決定將這一部分單獨拎出來說。
在學習了spring batch的知識之后我們應該很清楚的一點是，每一個spring batch的step都包含如下的部分:
即讀數據，處理數據，寫數據。這三個步驟里面最可能會導致內存變大問題的無疑是讀數據環節。讀數據作為spring batch的數據輸入，是整個spring batch job的開頭邏輯。
若我們的數據量不大，如只有幾十萬條，那我們無疑不會面臨內存問題，即便一次將所有數據加載到內存當中，占的內存也不會非常多，且spring batch數據遷移的速度非常之快，幾十萬條的數據往往是幾十秒的時間就可以遷移完成。但是當數據量變大之后，問題就不一樣了。當我們的數據量達到數百萬或上千萬時，若一次性將所有數據全部讀到內存當中，則會占據遠遠超出正常范圍的非常大的內存。該問題示意圖如下所示:
我們寫的任何程序都會有一個運行內存,假設這個內存的總容量現在只有4g，而我們數據庫里需要操作的數據有8g，那么無疑，一次性的將數據讀出來就會出錯。這便是需要考慮得問題。
Spring提供的reader實現
spring提供了非常豐富的Reader實現，其中比較常用的從數據庫讀數據的有JdbcCursorItemReader,JdbcPagingItemReader等。
JdbcCursorItemReader
使用JdbcCursorItemReader的示例代碼如下：
|
1
2
3
4
5
6
7
8
9
10
|
@Beanpublic JdbcCursorItemReader<CustomerCredit> itemReader() { return new JdbcCursorItemReaderBuilder<CustomerCredit>() .dataSource(this.dataSource) .name("creditReader") .sql("select ID, NAME, CREDIT from CUSTOMER") .rowMapper(new CustomerCreditRowMapper()) .build(); } |
JdbcCursorItemReader的好處在于使用簡單，但是我們從它的sql就能發現，JdbcCursorItemReader會一次把所有的數據全部拿回來，當數據量過大而服務器內存不夠時，就會遇到下面無法分配內存的問題：
報錯信息為:Resource exhaustion event:The JVM was unable to allocate memory from the heap. 意思就是需要分配內存的數據太多，但是無法找到足夠的內存了。
反映在內存里，堆內存會呈現出如下的情況:
隨著每一次數據讀入，堆內存都會增大，原因就在于JdbcCursorItemReader一次性讀回了所有的數據，返回之后就會存在一個對象里面，而這個對象的尺寸過大，因此直接進入了老年代。在數據遷移完成之前，這些數據都不會被回收。如下圖所示:
毫無疑問，當我們的數據量大時不應該使用這種類型的reader來讀取數據。
JdbcPagingItemReader
JdbcPagingItemReader的作用和它的名字一樣，它可以分頁讀取數據，但是使用起來相比于JdbcCursorItemReader更加復雜，示例代碼如下:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
@Beanpublic JdbcPagingItemReader itemReader(DataSource dataSource, PagingQueryProvider queryProvider) { Map<String, Object> parameterValues = new HashMap<>(); parameterValues.put("status", "NEW"); return new JdbcPagingItemReaderBuilder<CustomerCredit>() .name("creditReader") .dataSource(dataSource) .queryProvider(queryProvider) .parameterValues(parameterValues) .rowMapper(customerCreditMapper()) .pageSize(1000) .build();} @Beanpublic SqlPagingQueryProviderFactoryBean queryProvider() { SqlPagingQueryProviderFactoryBean provider = new SqlPagingQueryProviderFactoryBean(); provider.setSelectClause("select id, name, credit"); provider.setFromClause("from customer"); provider.setWhereClause("where status=:status"); provider.setSortKey("id"); return provider;} |
可以看到我們能夠設置page的大小，JdbcPagingItemReader將根據這個頁的大小，每次讀取這么多的數據，因此這些數據返回保存的對象，就只會是小對象，因此他們不會直接在老年代里分配，而是先分配在年輕代，隨著年輕代不斷變大，minor gc也不斷進行，回收掉已經處理完的數據，老年代的內存使用量不會有任何增大，類似下圖：
老年代內存不會有任何變化，年輕帶會隨著服務器數據遷移進行而增大同時被回收。
在使用JdbcPagingItemReader時，有一個必須注意的地方就是排序關鍵字是必須指定的，原因在于排序是分頁實現原理的技術基礎。sortKey和我們指定的其他字句一起構建出SQL語句出來。在sortKey上必須使用unique key constraint約束，因為只有這樣才能得以確保執行之間不會丟失任何數據。這也可以說是JdbcCursorItemReader相對便利的一點優勢。
總結
數據量小時選擇的方案差別不會很大，當數據量大時，為了有好的內存表現則使用分頁的reader是必要的。但同時，因為要實現分頁，也會帶來一些不可避免的限制。
到此這篇關于spring batch使用reader讀數據的內存容量問題詳解的文章就介紹到這了,更多相關spring batch使用reader讀數據內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家！
原文鏈接：https://blog.csdn.net/topdeveloperr/article/details/88843186
