Spring BcryptPasswordEncorder log rounds参数说明

今天在做用户上传Excel表格导入数据到Mongodb数据库的时候遇到一个超时的问题，比较有意思，在这里记录一下！需求是这样的，用户通过页面选择本地的Excel表格，通过接口将Excel表格上传到后台，由后端解析Excel表格中的数据，解析成功后保存到数据库中。对于Excel表格的处理我表示轻车熟路，本来这个功能已经做好了，而且之前还测试过上传有上万条记录的Excel表格的导入，完全没有压力。但是今天在导入新用户的时候突然提示500超时了！以下是我的解决过程：
1. 首先想到的时候Spring MVC的接口默认超时时间设置得太短了，Spring的文档说如果不设置默认超时时间，那么会根据服务器的超时时间进行设置，Tomcat一般是10s。然后我就修改了Spring的配置，增加了如下两处超时时间配置：

server:  connection-timeout: 60000spring:  mvc:    async:      request-timeout: 60000

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

1. 接着考虑是不是前端访问接口的时候有设置默认的超时时间，仔细F12看调用过程，否定了这个想法。
2. 然后只能单步调试了，但是类似这样的问题设置断点进行调试往往会影响程序运行，不易复现问题，所以我选择分步打印时间戳的办法。很顺利，发现了出现问题的代码块，如下：

//用户账号信息批量初始化设置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之类的协议进行异步处理。嗯，功能完善后再迭代吧！