一. 問題概述

　　老師的一個學生入職了杭州中通全球創研中心，最近他給老師分享一個他們公司解決OOM問題的案例，老師覺得十分有趣，特意把這個案例記錄下來，日后我會做成教學案例分享給學生。這個問題發生的背景如下：

　　【在物流領域，針對各個下級網點而言，每月1日～9日是進行財務月結的重要時間節點。在這個關鍵節點上，各個網點需要使用導出功能輸出寄派件、費用客戶信息等多種信息進行匯總結算】。也就是說，在月初的時候，每個網點都要統計一個月的各種流水(寄件，收件等)，最后再以excel表格的形式下載給客戶。

　　那么在這個業務中為什么很容易發生OOM異常呢?這是因為平均1個網點1個月的流水數據大約在30w行左右，根據計算得出大約500行數據就會占用1M內存，而1個站點把30萬行一股腦地讀到內存中，就會占用600M內存。試想一下，如果全國的網點都在月初集中下載報表的話，JVM是很容出現內存溢出的問題的!

　　二. 解決方案

　　那么這樣一個棘手的問題，如果我們只用一個單一的解決方案是不夠的，老師根據學生的描述，建議該學生主要采取以下幾種解決方案。

　　2.1 用硬盤空間置換內存空間

　　如果我們在接到統計數據請求的時候，一次性把30w條數據從數據庫讀取到一個List集合中，這顯然是不合理的，因為這樣一個List集合就會占用600M內存。所以我們可以進行分頁查詢，每次查詢1000條數據，然后往硬盤里寫，多讀取幾次，一點一點的把所有的數據都讀出來，再一點一點的往硬盤中寫。這樣在這個過程中，占用的內存就會少很多，主要變成了對硬盤空間的占用。而我們操作excel的技術，可以選擇阿里巴巴的easyexcel。

　　2.2 使用Mybatis的流式查詢

　　我們可以使用Mybatis的【流式查詢】查詢技術，在查詢成功后返回的是一個迭代器而不是一個集合，應用每次都從迭代器中獲取一條查詢結果，能夠降低內存的使用。試想一下，如果我們不使用流式查詢，而想要一次性從數據庫中讀取30萬條數據，內存是根本不夠用的!這時我們只能選擇分頁查詢，而分頁查詢的性能又取決于表設計以及索引的設計，大量數據分頁查詢的性能是很低的。老師對比了使用流式查詢和分頁查詢的兩種方案，得到的結論是取30萬條數據時，流式查詢的速度大約是分頁查詢的4~5倍左右。

　　2.3 使用redission信號量限流

　　生成一個月的流水報表是一個非常耗時的操作，用戶也不可能馬上就要結果，所以我這個學生的公司對同時生成報表的請求數量做了限制，同時只能處理10個報表的生成。在這期間如果再有生成報表的請求，我們將會讓這些請求排隊，等到前面的報表生成完畢后，再處理后面的請求。報表生成成功后，再通知客戶主動去下載，老師建議這里使用redisson分布式鎖的信號量來限制同時創建報表的線程數量。

　　2.4 MQ解耦+微服務拆分

　　本次業務中，讀數據庫，編寫excel文件，上傳到文件服務器這三個操作都非常耗時，學生的公司使用了MQ解耦，并把這次請求拆分成3個微服務，這樣讀、寫、上傳就不會相互影響了。

　　三. 流式查詢

　　在這篇文章中，老師只給大家分享一下Mybatis流式查詢的實現方法，其他的解決方案以后會在其他的文章中給大家呈現。

　　3.1 概念

　　流式查詢就是查詢成功后返回的是一個迭代器而不是一個集合，應用每次都從迭代器中獲取一條查詢結果，這樣能夠降低內存的使用。

　　3.2 Mybatis實現流式查詢

　　接下來就是實現流失查詢的具體過程。

　　在mapper映射文件中，編寫流式查詢的邏輯。

<!--
1: fetchSize： 官方文檔建議設置成Integer.MIN_VALUE
2: resultSetType="FORWARD_ONLY" 返回一個只向前的游標
3：注意我把表一次性查出，并沒有使用分頁邏輯，依靠流式查詢一行一行得到結果
-->
<select id="selectFetchSize" fetchSize="-2147483648" resultSetType="FORWARD_ONLY" resultType="com.qf.shop.cms.entity.TContent">
select * from t_content
</select>

　　在mapper接口文件中添加selectFetchSize方法。

　　// 參數 ResultHandler 是一個回調接口，也就是從游標中獲得一條數據就會回調接口中的方法

　　void selectFetchSize(ResultHandlerhandler);

　　自己編寫一個類實現ResultHandler接口，在該接口中定義從游標獲得一條數據后的回調邏輯。

　　/**

　　* 通過流式查詢每獲得一條數據的回調類

　　*/

　　public class TContentResultHandler implements ResultHandler{

　　/**

　　* 這里每集滿1000條數據 往硬盤的excel文件中追加一次數據

　　*/

　　private final static int BATCH_SIZE = 1000;

　　/**

　　* 計數器

　　*/

　　private int size=0;

　　/**

　　* 存儲每批數據的臨時容器

　　*/

　　private ListtContents = new ArrayList<>();

　　/**

　　* 每從流式查詢中獲得一行結果，就會調用一次這個方法

　　* @param resultContext

　　*/

　　@Override

　　public void handleResult(ResultContext resultContext){

　　// 這里獲取流式查詢每次返回的單條結果

　　TContent resultObject = resultContext.getResultObject();

　　// 你可以看自己的項目需要分批進行處理或者單個處理，這里以分批處理為例

　　tContents.add(resultObject);

　　size++;

　　if (size == BATCH_SIZE) {

　　// 如果集滿1000條就往文件中寫一次

　　handle();

　　}

　　}

　　/**

　　* 集滿1000條 執行一次的邏輯

　　*/

　　private void handle() {

　　try {

　　// 在這里可以對你獲取到的批量結果數據進行需要的業務處理

　　// 這里的業務是 往文件中寫一次

　　} finally {

　　// 處理完每批數據后后將臨時清空

　　size = 0;

　　tContents.clear();

　　}

　　}

　　/**

　　* 這個方法給外面調用，用來完成最后一批數據處理

　　*/

　　public void end(){

　　handle();// 處理最后一批不到BATCH_SIZE的數據

　　}

　　}

　　在業務邏輯(service)層調用流式查詢方法。

　　@Autowired

　　private TContentMapper contentMapper;

　　public void streamQuery(){

　　// 生成流式查詢的回調對象

　　TContentResultHandler tContentResultHandler = new TContentResultHandler();

　　// 調用流式查詢

　　contentMapper.selectFetchSize(tContentResultHandler);

　　// 執行完最后一批數據的邏輯

　　tContentResultHandler.end();

　　}

　　四. 后話

　　老師前面已經說到，為了解決本次產生的OOM問題，老師給大家列舉了非常多的解決方案，但本篇文章介紹的流式查詢只是其中的方案之一。至于其他的解決方案，老師將在后續的文章中為大家一一揭曉，敬請各位繼續關注本公眾號，如有問題，可以在評論區給我們留言哦。