记录一次非常麻烦的调试

问题简介

这个功能是公司2021年写的老功能，一直都没有更新过代码，这次在导入一个1.03G的大文件进行读取的过程中出问题了。
简单介绍一下这个功能：
公司使用的spring boot框架构建项目，该功能为项目内的一个接口调用功能。该功能首先，通过远程接口下载文件到局域网sftp服务器上；下载完毕后将服务器文件下载到本机指定位置内；最后读取文件内容，识别其中的数据，将合法数据添加到数据库中。
出现的问题：

try...catch

内存溢出问题。
json读取异常。
待补充。

问题解决过程

1、`try...catch...`字段不产生任何报错的问题。

起因是这个功能没有任何报错，但是动作只进行到【下载文件到sftp服务器上】，之后的步骤就没出现了。

这个处理方式是：

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提示，这些提示语可以在日志中显示，就可以看到代码运行到哪一步停下了。

@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(;
}
```
这样打印出来了错误，指向问题：

这导致下载时，其中有一个ChannelSftp.cd(directory方法的参数是一个文件，这自然会报错，所以我修改了，程序也进行到了下一步。

这里一定要注意一点，并不是说，这种自己编写的异常一定打不出来日志，而是因为部分框架构建的时候有问题（譬如我们公司的框架构建的时候就有问题。），以至于打不出log，正常情况还是可以的。不过为了以防万一，大家还是用我上面说的那个方法打log比较好。

2、内存溢出问题。

这个问题的报错简单粗暴：

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("上传文件为空";
}

其实用一个很粗略的计算就能算出来了，变量无论如何都是存在内存中处理的，

其次：for循环中有一个f的文件，也是1g

还有：为bytes分配了1g的大小空间

遇到这种情况，

其次变量一定要控制大小，譬如这个bytes的大小，显然不用一下子分配1g，这个bytes也是要添加到assetJson变量里面的，所以就是一个多余的变量，可以做一个循环，将bytes大小每次少分配一点，也尽快清掉bytes，让这个变量反复添加到assetJson中。

3、json读取异常。

当上一个内存溢出问题解决后，之后就可以进行到【最后读取文件内容，识别其中的数据，将合法数据添加到数据库中】这个过程了，但是在这时报了一个错误：

com.alibaba.fastjson.JSONException: syntax error, expect [, actual {, pos 0, fieldName null

这个问题解释过来就是：json字段在某个位置本来应该是’[‘，实际上是’{‘

JSONArray jsonArray = JSONArray.parseArray(assetJson;

当调用这个代码时，parseArray会逐字解析变成jsonArray变量，当解析到本该是中括号符号时，出现的却是花括号，这就出问题了。

我们可以仔细思考一下json语句的格式，正常的json字段需要读取为一个一个一个对象的话，中间都是通过花括号和逗号分隔开的，而把各个【json对象】合在一起的方式，就是类似于【Map】一样的中括号拉在一块的。所以这个中括号，要不就是在一整个json语句的外部，把整体框住；要不就是在每个json对象内框住一个map。

解决该问题后，程序开始读取每条数据，此时没有任何问题，但是添加到数据库的过程出问题了：
```
invalid byte sequence for encoding "UTF8": 0x00  Call getNextException to see other errors in the batch.;
```
解释一下，大概就是说类型不合法，与sql编码UTF8不一样！这是批量插入时出现的信息。

苦思冥想许久，我发现为什么复制过去了的数值，前面和后面不一样捏，我们看一下区别：

上面是数据库的

NUL各位应该懂得都懂，就是UTF8无法解析的字符，大概要不是一些乱码，要不就是一些特殊符号，这是妥妥的数据问题咯，那为什么会出现复制过来就变成空格了的情况捏，我直接查了一下知乎，有位大佬讲了一下原因。

这种错误如何解决就得看大家了，要不就是从根源上解决，直接找数据提供方的麻烦；要不就是自己在代码上面修改一下对这个字段的数据，可以通过进行一次UTF8的转换将数据的问题信息消掉（我这边就是这么弄的）；也可以直接判断这种问题信息就不要录入了，当然，这个实现起来得看各位的需求。
```
byte[] bytes = data.getBytes("UTF-8";
String softwareName = new String(bytes, "UTF-8";
```
这样就可以把原来的data转化为utf-8格式的softwareName变量（转两次，保险）

4、备注

json判断的时候一定要仔细，譬如我上面说的那些问题，json稍微出现一点问题，这个数据就会影响全局，批量添加这个数据的时候就报错，导致后面的数据添加不了，程序就中断了。所以当大家有这个需求的时候，对json的判断要多上心，前面准备的越足，即使程序运行慢点，但是这比之后多次调试好吧。

碎碎念（非正文）

这个代码是别人写的，我不敢怎么去修改太多逻辑，我只能在判断上面下点功夫，所以我建议如果是改别人的老代码的这种任务就不要去接。

这个任务在开始的时候，需求方发了我数据，当然，数据我是打不开的，电脑带不动；然后发了我报错日志，想想三百多M的日志，打倒是打得开就是特别费劲，一点开，好嘛，从当日0点到当时的日志全给我发过来了，更好笑的是，日志里面没有任何相关内容就结束了，所以那个日志我找了半小时没有任何意义。

而当我找到问题所在时，我发现需求和我现在发现的问题对不上。需求说的是：东西下载到本地了，但是数据库没数据。我这边发现，根本没有进行到下载到本地的操作就结束了。于是我远程查看现场，发现只是下载到sftp而已。我发现了这个问题就下班了。

后来嘛，让需求问数据提供方，是不是数据给的有问题，不问，一直卡着，我只能在我这边和现场处理这个，现场也不配合，一会不知道干啥去了，我有次急了，发现远程的时候桌面没动静；一会又电脑坏了不能弄。反正挺折磨的，来来回回因为现场和需求方耽搁了五天还没处理完这个bug。

真的，如果有人看到这里，而且有程序员工作的话，我的建议：

如果你的领导无缘无故骂你，一定是有人背后推动，请记住，要不有能耐找到幕后黑手，要不就直接回怼，你明明做了，无缘无故骂你，一概都是有毛病的人。
如果你的需求和现场不配合，群里怼，找领导反应，事情闹大，恶心他们，请记住，都是干活的，都是平等的，没必要好口气，他们不配合就不要惯着。
如果你的需求是你以前就很烦的需求，请尽量不要接他的活。

最后我还是要吐槽，这个提需求的**，需求讲不明白，自己也搞不懂需求本身，打小报告还，跟小学生似的，催又催的急，交接东西又不积极，真恶心到我了，急急急急急急。

编程笔记 » 记录一次非常麻烦的调试

记录一次非常麻烦的调试

问题简介

问题解决过程

1、`try...catch...`字段不产生任何报错的问题。

2、内存溢出问题。

3、json读取异常。

4、备注

碎碎念（非正文）

相关文章

Hi，您需要填写昵称和邮箱！

问题简介

问题解决过程

1、try...catch...字段不产生任何报错的问题。

2、内存溢出问题。

3、json读取异常。

4、备注

碎碎念（非正文）

相关文章

Hi，您需要填写昵称和邮箱！

1、`try...catch...`字段不产生任何报错的问题。