記錄一次非常麻煩的除錯-有解無憂

此次記錄一次非常麻煩的除錯問題，不是純知識分享，只是記錄這次除錯程序引以為戒，

問題簡介

這個功能是公司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，

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

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

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

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

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/551707.html

標籤：其他

上一篇：LeetCode 59. 螺旋矩陣 II

下一篇：返回列表

記錄一次非常麻煩的除錯