記錄一次非常麻煩的調試_ZenDei技術網路在線

此次記錄一次非常麻煩的調試問題，不是純知識分享，只是記錄這次調試過程引以為戒。問題簡介這個功能是公司2021年寫的老功能，一直都沒有更新過代碼，這次在導入一個1.03G的大文件進行讀取的過程中出問題了。簡單介紹一下這個功能：公司使用的spring boot框架構建項目，該功能為項目內的一個接 ...

此次記錄一次非常麻煩的調試問題，不是純知識分享，只是記錄這次調試過程引以為戒。

問題簡介

這個功能是公司2021年寫的老功能，一直都沒有更新過代碼，這次在導入一個1.03G的大文件進行讀取的過程中出問題了。
簡單介紹一下這個功能：
公司使用的spring boot框架構建項目，該功能為項目內的一個介面調用功能。該功能首先，通過遠程介面下載文件到區域網sftp伺服器上；下載完畢後將伺服器文件下載到本機指定位置內；最後讀取文件內容，識別其中的數據，將合法數據添加到資料庫中。
出現的問題：

導出日誌時，try...catch欄位不產生任何報錯，但是實際上沒有任何動作。
記憶體溢出問題。
json讀取異常。
待補充。

問題解決過程

1、`try...catch...`欄位不產生任何報錯的問題。

這個問題屬實是最大問題了，也是困擾很久的問題。
起因是這個功能沒有任何報錯，但是動作只進行到【下載文件到sftp伺服器上】，之後的步驟就沒出現了。

首先註意到沒有任何報錯的過程，於是添加了Logger類，對各個步驟添加了logger以便查看輸入。

這個處理方式是：

引入logger相關類，之後在操作類中創建Logger對象，格式如下：

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class assetSyncForXN {
    private static final Logger logger = LoggerFactory.getLogger(assetSyncForXN.class);
}

在項目模塊的application.yml配置中，配置logger的顯示許可權：

logging:
  level:
    com.***.***: ERROR
# 這裡註意一下：level代表等級，代表下麵的包能夠展示日誌log最低的等級。
# 下麵的示例語句，左邊【com.***.***】代表包名，表示這個包下麵的所有的包含類，都有這個的最低展示許可權。
# 右邊【ERROR】表示【最低】展示許可權，從低到高依次為DEBUG<INFO<WARNING<ERROR<CRITICAL，而日誌中展示的log，只展示與該許可權相同或更高許可權的log
# 打個比方：示例中這樣寫的許可權，我們在這個包下麵打出來的日誌中就只能看見ERROR許可權的log和CRITICAL許可權的log。

這樣我們就可以在每一句加入logger提示，這些提示語可以在日誌中顯示，就可以看到代碼運行到哪一步停下了。

順帶寫一下log在java中如何用：

@Autowired
private Environment env;
private static RestTemplate restTemplate = AuthRestTemplate.restTemplate();

//譬如我們寫一個連通方法，我們連通指定的url，獲取他的實例對象，取其中的聯通碼數據
public void assetAllSync() {
    String url = env.getProperty("syncAssetXN.allUrl");
    //可以像String一樣拼接，這個就是打出一個普通的String
    logger.info("=========url:"+url);
    ResponseEntity<HashMap> result = restTemplate.getForEntity(url, HashMap.class);
    logger.info("=============================");
    //可以用花括弧指代一個變數，變數放在後面用逗號隔開，裡面存放Object類型的內容
    logger.debug("result:{}",result);
    logger.info("================聯通碼:{}",result.getStatusCode());
}

這樣我定位了問題的位置，但是卻不清楚問題的原因。我找了一下發現在try...catch..塊上面有問題，於是發現了catch{}部分裡面很匪夷所思的寫了一個這個catch：
```
catch(Exception e){
    throw new BizIllegalArgumentException("讀取文件============"+e.getMessage());
}
```
我這邊發現這個【BizIllegalArgumentException】類是公司內部寫的一個異常，而這個異常，一是不會在返回值內出現任何報錯，二是在日誌內沒有任何反饋信息，這就是導致看不出來問題的原因，這個只有一個迅速結束進程的功能，所以我擴充了一下：
```
catch(Exception e){
    logger.error("內部錯誤1:{}",e);
    throw new BizIllegalArgumentException("讀取文件============"+e.getMessage());
}
```
這樣列印出來了錯誤，指向問題：

下載至sftp伺服器完畢後，將sftp伺服器文件下載到本機指定位置內這個過程中，原本傳遞來的【sftp地址】參數應該是一個文件夾而不是直接定位到文件，結果發現傳遞過來的參數是一個文件，應該是調用的介面修改過。（這個不是重點，不詳細說了）

這導致下載時，其中有一個ChannelSftp.cd(directory)方法的參數是一個文件，這自然會報錯，所以我修改了，程式也進行到了下一步。

備註：

這裡一定要註意一點，並不是說，這種自己編寫的異常一定打不出來日誌，而是因為部分框架構建的時候有問題（譬如我們公司的框架構建的時候就有問題。。。），以至於打不出log，正常情況還是可以的。不過為了以防萬一，大家還是用我上面說的那個方法打log比較好。

2、記憶體溢出問題。

這個不是最噁心的問題，但是確實是一個警示，告訴我們程式中不僅要註意時間複雜度，更要註意空間。

這個問題的報錯簡單粗暴：

直接告訴你超記憶體了，這個解決也很簡單粗暴，在application.yml裡面添加一個配置

msdf:
  java:
    options: -Xmx8g
# -Xmx後面的8g就是指給該運行模塊分配8g的記憶體

分配一下記憶體就可以了，預設的記憶體分配時很小的（俺不清楚這個預設是多少，有興趣可以查查），一般只要到達98%的記憶體分配時就會報這個問題。所以建議給application.yml添加該配置。

當然，我們關註的是原因，總不能遇到這種情況就無腦加記憶體。

先放上代碼：（已知，saveDir是一個文件夾，裡面存放了一個1G的txt文件）

File saveDir = new File(env.getProperty("syncAssetXN.savePath"));
if(!saveDir.exists()){//保存文件路徑是否存在，不存在重新創建
    saveDir.mkdirs();
}
SftpClientUtil.downloadByDirectory(callerSftpAddress,env.getProperty("syncAssetXN.savePath"),client);
logger.info("===================關閉連接===========");
client.disconnect();
logger.info("==============listFiles.length:{}",saveDir.listFiles().length);
if(saveDir.listFiles().length>0){// 獲取到資產信息文件
    logger.info("=============獲取到資產信息文件===============");
    for(File f: saveDir.listFiles()){
        String assetJson = "";
        try{
            logger.info("====1====:"+f.getName());
            InputStream is = new FileInputStream(f);
            logger.info("====2====");
            int iAvail = is.available();
            logger.info("======3======");
            byte[] bytes = new byte[iAvail];
            logger.info("======4======");
            is.read(bytes);
            logger.info("======5======");
            assetJson = '[' + new String(bytes) +']';
            logger.info("======close======");
            is.close();
        }catch(Exception e){
            logger.error("內部錯誤1:{}",e);
            throw new BizIllegalArgumentException("讀取文件============"+e.getMessage());
            //                                    e.printStackTrace();

        }
        buildAssetList(assetJson);
        logger.info("close build!");
        f.delete();
    }

}else{
    logger.error("上傳文件為空");
    throw new BizIllegalArgumentException("上傳文件為空");
}

其實用一個很粗略的計算就能算出來了，變數無論如何都是存在記憶體中處理的，

首先：saveDir，1g

其次：for迴圈中有一個f的文件，也是1g

在者：is這個流變數，放入的是f的流，1g

還有：為bytes分配了1g的大小空間

還包括對各種數據的處理什麼的，assetJson的大小也是1g，算來已經5g多了，更別說別的了，預設的數據量是怎麼都存不了的，就會報這個問題了。

遇到這種情況，

首先是，最好多用更加局部變數，少用更全局的變數，用的變數的存活時間不能過長；
其次變數一定要控制大小，譬如這個bytes的大小，顯然不用一下子分配1g，這個bytes也是要添加到assetJson變數裡面的，所以就是一個多餘的變數，可以做一個迴圈，將bytes大小每次少分配一點，也儘快清掉bytes，讓這個變數反覆添加到assetJson中。

3、json讀取異常。

講一下這個問題的發現歷史。

當上一個記憶體溢出問題解決後，之後就可以進行到【最後讀取文件內容，識別其中的數據，將合法數據添加到資料庫中】這個過程了，但是在這時報了一個錯誤：
複製出來，免得有想找的小伙伴找不著相關的問題解決辦法：
```
com.alibaba.fastjson.JSONException: syntax error, expect [, actual {, pos 0, fieldName null
```
這個問題解釋過來就是：json欄位在某個位置本來應該是’[‘，實際上是’{‘

出現問題的java代碼：
```
JSONArray jsonArray = JSONArray.parseArray(assetJson);
```
當調用這個代碼時，parseArray會逐字解析變成jsonArray變數，當解析到本該是中括弧符號時，出現的卻是花括弧，這就出問題了。

如果你的json欄位很短，我們可以打開json欄位確認一下，但如果你的欄位很長，比如我這個1g（編輯器都沒辦法打開這個文件，打開就會卡死），那怎麼確認？

我們可以仔細思考一下json語句的格式，正常的json欄位需要讀取為一個一個一個對象的話，中間都是通過花括弧和逗號分隔開的，而把各個【json對象】合在一起的方式，就是類似於【Map】一樣的中括弧拉在一塊的。所以這個中括弧，要不就是在一整個json語句的外部，把整體框住；要不就是在每個json對象內框住一個map。

這個時候，要不就是推測，要不就是和提供數據方確認，這個欄位的問題是出現在哪，我這裡直接就是推測，大概就是整個json語句沒被中括弧框住，事實確實是這樣，於是我把json語句的賦值上加了一個中括弧，這個問題就解決了。
解決該問題後，程式開始讀取每條數據，此時沒有任何問題，但是添加到資料庫的過程出問題了：

圖片裡面寫的很雜，我發一下：
```
invalid byte sequence for encoding "UTF8": 0x00  Call getNextException to see other errors in the batch.;
```
解釋一下，大概就是說類型不合法，與sql編碼UTF8不一樣！這是批量插入時出現的信息。

於是想辦法看一下：linux伺服器系統的編碼和PGSQL的編碼一樣，都是UTF8。且sql複製到navicat上直接執行，完全沒有問題。

苦思冥想許久，我發現為什麼複製過去了的數值，前面和後面不一樣捏，我們看一下區別：

上面是資料庫的

這個上面是報錯日誌裡面的

NUL各位應該懂得都懂，就是UTF8無法解析的字元，大概要不是一些亂碼，要不就是一些特殊符號，這是妥妥的數據問題咯，那為什麼會出現複製過來就變成空格了的情況捏，我直接查了一下知乎，有位大佬講了一下原因。

說這麼長就是說：複製的時候會根據編碼方式修改。那麼這個編碼方式通過我們複製粘貼到sql的就是修改過的內容，但是通過程式直接傳遞是沒有進行任何修改的。而又因為我們看的報錯日誌是utf8格式，這說明，這個欄位部分數值是不能通過utf8解析的，問題就是出現在這裡了。

這種錯誤如何解決就得看大家了，要不就是從根源上解決，直接找數據提供方的麻煩；要不就是自己在代碼上面修改一下對這個欄位的數據，可以通過進行一次UTF8的轉換將數據的問題信息消掉（我這邊就是這麼弄的）；也可以直接判斷這種問題信息就不要錄入了，當然，這個實現起來得看各位的需求。

那麼給大家參考一下第二種我做的方式：
```
byte[] bytes = data.getBytes("UTF-8");
String softwareName = new String(bytes, "UTF-8");
```
這樣就可以把原來的data轉化為utf-8格式的softwareName變數（轉兩次，保險）

4、備註

打log的時候，如果只是單步log，程式運行一次就不會再運行的，這種沒啥問題；但是遇到要遍歷大數據的時候裡面打log一定要謹慎，我這個txt文件內有158w條數據，打log的時候給遍歷過程內添加了log，結果就是運行奇慢，在我現在寫這篇文章的時候還在跑，跑了8個小時了！
json判斷的時候一定要仔細，譬如我上面說的那些問題，json稍微出現一點問題，這個數據就會影響全局，批量添加這個數據的時候就報錯，導致後面的數據添加不了，程式就中斷了。所以當大家有這個需求的時候，對json的判斷要多上心，前面準備的越足，即使程式運行慢點，但是這比之後多次調試好吧。

碎碎念（非正文）

當寫這篇文章的時候，本人還在測試這個功能的運行情況，運行正常確實已經到最後一步了，但是由於log和數據量的問題，以及測試伺服器太拉跨導致跑了很久很久還沒跑完，所以我還在等待ing。

這個代碼是別人寫的，我不敢怎麼去修改太多邏輯，我只能在判斷上面下點功夫，所以我建議如果是改別人的老代碼的這種任務就不要去接。

從開始說起吧

這個任務在開始的時候，需求方發了我數據，當然，數據我是打不開的，電腦帶不動；然後發了我報錯日誌，想想三百多M的日誌，打倒是打得開就是特別費勁，一點開，好嘛，從當日0點到當時的日誌全給我發過來了，更好笑的是，日誌裡面沒有任何相關內容就結束了，所以那個日誌我找了半小時沒有任何意義。

這個時候我想到打log，琢磨很久，寫了一部分log給現場的人員發了更新包。很神奇啊，有的log他就是不顯示，只有你把後面的一些問題解決了才會顯示（那不提示log我怎麼知道是哪裡的問題）；有的log玄學，一會顯示一會不顯示；我最後好不容易定位try..catch裡面加了一些log才找著，真的是噁心。

而當我找到問題所在時，我發現需求和我現在發現的問題對不上。需求說的是：東西下載到本地了，但是資料庫沒數據。我這邊發現，根本沒有進行到下載到本地的操作就結束了。於是我遠程查看現場，發現只是下載到sftp而已。我發現了這個問題就下班了。

下班回家，被組長罵了一頓，說我不管人家的需求，我說我管了，組長說你有什麼問題你就說，不能不管（反正就是不聽不聽）。第二天問了我加班的同事，告訴我那個人打小報告了，說我沒處理。唉，我真的沒話說。

後來嘛，讓需求問數據提供方，是不是數據給的有問題，不問，一直卡著，我只能在我這邊和現場處理這個，現場也不配合，一會不知道幹啥去了，我有次急了，發現遠程的時候桌面沒動靜；一會又電腦壞了不能弄。反正挺折磨的，來來回回因為現場和需求方耽擱了五天還沒處理完這個bug。

後面好不容易能下載到數據了，那邊又說，數據量對不上，就出現了我上面說的最後一個問題，也不知道後面還有沒有問題，我這一周都耗這了，我昨天半夜還在看數據有沒有跑完。

真的，如果有人看到這裡，而且有程式員工作的話，我的建議：

如果代碼很久沒有變動，但是突然出了問題，大概率是數據提供方出現問題，及時丟鍋，找數據提供方確認數據格式，內容的變動是否有問題。
如果你的領導無緣無故罵你，一定是有人背後推動，請記住，要不有能耐找到幕後黑手，要不就直接回懟，你明明做了，無緣無故罵你，一概都是有毛病的人。
如果你的需求和現場不配合，群里懟，找領導反應，事情鬧大，噁心他們，請記住，都是幹活的，都是平等的，沒必要好口氣，他們不配合就不要慣著。
如果你的需求是你以前就很煩的需求，請儘量不要接他的活。

最後我還是要吐槽，這個提需求的**，需求講不明白，自己也搞不懂需求本身，打小報告還，跟小學生似的，催又催的急，交接東西又不積極，真噁心到我了，急急急急急急。

記錄一次非常麻煩的調試