Spring BcryptPasswordEncorder Log Rounds参数说明

Spring BcryptPasswordEncorder log rounds参数说明

今天在做用户上传

Excel表格

导入数据到

Mongodb

数据库的时候遇到一个超时的问题，比较有意思，在这里记录一下！需求是这样的，用户通过页面选择本地的Excel表格，通过接口将Excel表格上传到后台，由后端解析Excel表格中的数据，解析成功后保存到数据库中。对于Excel表格的处理我表示轻车熟路，本来这个功能已经做好了，而且之前还测试过上传有上万条记录的Excel表格的导入，完全没有压力。但是今天在导入新用户的时候突然提示

500超时

了！以下是我的解决过程：

1. 首先想到的时候

Spring MVC

的接口默认超时时间设置得太短了，

Spring

的文档说如果不设置默认超时时间，那么会根据服务器的超时时间进行设置，

Tomcat

一般是10s。然后我就修改了

Spring

的配置，增加了如下两处超时时间配置：

server:
connection-timeout: 60000

spring:
mvc:
async:
request-timeout: 60000

再次上传该用户表，WTF，还是超时。

接着考虑是不是前端访问接口的时候有设置默认的超时时间，仔细

F12

看调用过程，否定了这个想法。

然后只能单步调试了，但是类似这样的问题设置断点进行调试往往会影响程序运行，不易复现问题，所以我选择

分步打印时间戳

的办法。很顺利，发现了出现问题的代码块，如下：

//用户账号信息批量初始化设置
users.stream().forEach(tempStudent -> {
//设置默认用户角色
tempUser.setRoles(Arrays.asList(DefaultRole));
//设置用户默认登录名为编号
tempUser.setUsername(tempUser.getCode());
//设置用户默认密码为编号
String md5Hex = DigestUtils.md5Hex(tempUser.getCode());
tempUser.setPassword(md5Hex);
});

再次使用

逐行注释法

，最终定位到出现问题的代码是：

tempUser.setPassword(md5Hex);

而我在该代码块里面做的工作如下：

public static final PasswordEncoder PASSWORD_ENCODER = new BCryptPasswordEncoder(4);
public void setPassword(String password) {
this.password = PASSWORD_ENCODER.encode(password);
}

设置用户密码时使用

Spring

框架的

BCryptPasswordEncoder

对密码进行了加密。发现这个问题时感觉很困惑，按理说

Spring

框架这么成熟，不会有这么明细的性能瓶颈啊！再仔细去看里面的构造函数和加密方法，大概发现了问题所在，关键代码如下：

public BCryptPasswordEncoder() {
this(-1);
}
public String encode(CharSequence rawPassword) {
String salt;
if (strength > 0) {
if (random != null) {
salt = BCrypt.gensalt(strength, random);
}
else {
salt = BCrypt.gensalt(strength);
}
}
else {
salt = BCrypt.gensalt();
}
return BCrypt.hashpw(rawPassword.toString(), salt);
}
public static String gensalt() {
return gensalt(GENSALT_DEFAULT_LOG2_ROUNDS);
}
private static final int GENSALT_DEFAULT_LOG2_ROUNDS = 10;

原来是如果构造

BCryptPasswordEncoder

时不传参数就默认使用长度为10的

LOG ROUND

，我试着传入最小的构造参数

4

之后，一下子就处理完了，

500

错误也没有了。搜索了相关的关键词，

LOG ROUND

这个参数大概的意思是做加密时重复处理的轮数，而且其复杂度是

指数级

递增，也就是传

4

的时候是

2

的

4

次方，默认传输为

10

的时候是

2

的

10

次方！难怪其速度会差距这么大！

最后呢，显然这种在接口里面同步处理大批量数据的方法是不可取的，应该使用

ActiveMQ

之类的协议进行异步处理。嗯，功能完善后再迭代吧！