如果你在用shiro作为底层的安全框架，请一定要阅读此文。
背景
一天，小L接到一个任务，需要优化一个系统接口。小L看了一下原有接口逻辑，代码大致如下：
Controller:
@GetMapping("/bullshitApi")
public Result<String> bullshitApi() {
long start = System.currentTimeMillis();
String condition = IdUtil.simpleUUID();
log.info("username={} 查询条件={}", ShiroUtil.whoAmI(), condition);
String result = testService.getData(condition);
long time = System.currentTimeMillis() - start;
return Result.success(result + "time=" + time + "ms");
}
Service
public String getData(String condition) {
String username1 = longComputation1(condition);
String username2 = longComputation2(condition);
return "username1=" + username1 + ",username2=" + username2 + ",condition=" + condition;
}
private String longComputation1(String condition) {
String username = ShiroUtil.whoAmI();
log.info("longComputation1 username={} 查询条件={}", username, condition);
// 方法很复杂,数据关联查询较多
try {
TimeUnit.MILLISECONDS.sleep(450);
} catch (InterruptedException e) {
e.printStackTrace();
}
return username;
}
private String longComputation2(String condition) {
String username = ShiroUtil.whoAmI();
log.info("longComputation2 username={} 查询条件={}", username, condition);
// 方法很复杂,数据关联查询较多
try {
TimeUnit.MILLISECONDS.sleep(450);
} catch (InterruptedException e) {
e.printStackTrace();
}
return username;
}
初始测试结果 900ms
{
"traceID": "328840403957121024",
"timestamp": 1605166498528,
"language": "zh",
"data": "username1=leven.chen,username2=leven.chen,condition=cdafd8d4556c4fc0b6484648c4eac6e6>>Time=900ms",
"code": "S0000",
"msg": null,
"success": true
}
第一次改造：异步
经过分析,小L发现，这个方法中主要有两个耗时的子方法 longComputation1() 和longComputation2()，里面的逻辑非常复杂，什么OCP原则，里氏替换等等全都没有，有的只是一大串的代码。
这让小L很是头疼。但是庆幸的是，这两个方法间并没有数据关联关系。那如果使用异步API并行的去处理，那岂不是可以将性能提升很多？！
同步API 与 异步API
同步API其实只是对传统方法调用的另一种称呼，方法间会串行执行，调用方必须等待被调用方执行结束后才会执行下一个方法，这就是阻塞式调用这个名词的由来。与此相反，异步API会直接先返回，或者至少会在被调用方执行结束前，将剩余任务将给另一个线程去处理。简单来说就是方法间会并行的执行，而且调用方和被调用方并不在一个线程内，这就是非阻塞式调用的由来。
于是，小L就开始改造为异步并行处理，代码如下：
public String getDataV2(String condition) {
List<String> list = Lists.newArrayList();
Thread t1 = new Thread(() -> {
String result = longComputation1(condition);
list.add(result);
});
Thread t2 = new Thread(() -> {
String result = longComputation2(condition);
list.add(result);
});
try {
t1.start();
t2.start();
t1.join();
t2.join();
return "username1=" + list.get(0) + ",username2=" + list.get(1) + ",condition=" + condition;
} catch (InterruptedException e) {
log.error("error", e);
}
return null;
}
这里使用了两个异步线程并发的执行方法，经过小L的测试，从原来的900ms，变为了现在的638ms
测试结果： 638ms
{
"traceID": "328840403957121024",
"timestamp": 1605166498528,
"language": "zh",
"data": "username1=leven.chen,username2=leven.chen,condition=cdafd8d4556c4fc0b6484648c4eac6e6>>Time=638ms",
"code": "S0000",
"msg": null,
"success": true
}
而且功能也没有任何问题，非常有效果。
但是IDEA 的 阿里巴巴Java规范提示了一个警告：“不要手工创建线程，请使用线程池”。作为一个有代码洁癖的工程师，小L肯定要修复这个问题。
1.png
"嗯，虽然有效果，但是不够完美，而且每次新开线程确实太浪费了，应该搞个线程池，做到极致优化" 小L心中默默的思考着~
第二次改造：异步+线程池
小L在项目中配置了一个线程池，并将异步方法提交到了线程池中进行处理。
线程池配置：
@PostConstruct
public void init() {
executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(10);
executor.setMaxPoolSize(50);
executor.setQueueCapacity(10);
executor.setKeepAliveSeconds(5);
executor.setThreadNamePrefix("AYSNC-TEST");
// 线程池对拒绝任务的处理策略
// CallerRunsPolicy：由调用线程（提交任务的线程）处理该任务
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
// 初始化
executor.initialize();
}
getDataV3：线程池+多线程
这里使用了Java CompletableFuture是为了代码简洁，大致等同于上面的Thread处理
public String getDataV3(String condition) {
CompletableFuture<String> c1 = CompletableFuture.supplyAsync(() -> longComputation1(condition), executor);
CompletableFuture<String> c2 = CompletableFuture.supplyAsync(() -> longComputation2(condition), executor);
try {
return "username1=" + c1.get() + ",username2=" + c2.get() + ",condition=" + condition;
} catch (InterruptedException | ExecutionException e) {
log.error("error", e);
}
return null;
}
测试结果：
{
"traceID": "328840933984616448",
"timestamp": 1605166624897,
"language": "zh",
"data": "username1=leven.chen,username2=leven.chen,condition=6ca569dff23a4f6fb73f932838793173>>Time=452ms",
"code": "S0000",
"msg": null,
"success": true
}
“由上一步的的638ms 到了452ms， 又节省了100ms多毫秒，终于达标小于500ms了。” 小L心中默喜~
单元测试，自测，发布上线，回归都没有问题，小L高兴的以为圆满完成，但是此时他不知道，他已经被坑惨了，坑他的不是其他，正是阿里巴巴Java规范关于线程池的提示。
项目上线不久后，有用户反馈时而能查到别人的数据，这个频率越来越高。后面的用户已经完全查不到自己的数据了。
2.png
图中演示用户信息错乱，相同的condition代表一组查询
小L赶快将生产版本回滚，并陷入了沉思... “到底是什么原因呢？”
大坑：Shiro +线程池
小L又默默的一行行看着自己修改的代码，问题表现是“用户信息取错了”，”那么用户信息又是通过dava security（shiro）的ShiroUtil拿到的，那么会不会是这个里面线程间传递有问题呢？“
他打开了ShiroUtil的源码进行追踪查看，突然他(心中)大喊一声 "卧槽，F**k， 这么坑爹"
3.png
原来Shiro是用了InheritableThreadLocal来实现存储&线程间隔离用户信息。当创建新的异步线程时，子线程会判断父线程是否存在InheritableThreadLocal，如果存在，就会将InheritableThreadLocal中的信息复制到子线程间，实现线程间传递数据
java.lang.Thead#init()方法部分源码
private void init(ThreadGroup g, Runnable target, String name,
long stackSize, AccessControlContext acc,
boolean inheritThreadLocals) {
// 省略。。。
//inheritThreadLocals默认为true
if (inheritThreadLocals && parent.inheritableThreadLocals != null)
this.inheritableThreadLocals =
ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
// 省略。。。
}
但是小L使用了线程池，线程池最大的作用就是复用线程，也就是说这个init方法只会在线程创建的时候执行，一旦线程初始化，就不会再次执行该方法。其他异步任务就会直接使用该线程，这也就是解释了为什么getDataV2()方法完全没有问题，getDataV3()一开始也没有问题，但是随着用户操作次数增多，线程池中的线程复用情况越来越多，就会出现用户信息取错的问题。
Alibaba官方解释：JDK的InheritableThreadLocal类可以完成父线程到子线程的值传递。但对于使用线程池等会池化复用线程的执行组件的情况，线程由线程池创建好，并且线程是池化起来反复使用的；这时父子线程关系的ThreadLocal值传递已经没有意义,因为不会再走初始化方法，但是应用需要的实际上是把 任务提交给线程池时的ThreadLocal值传递到 任务执行时。
问题修复
其实问题一旦被定位，就很好修复了。
方案一：不要用线程池
推荐指数：💗💗💗💗💗
小L心中感悟，当我们在对线程池原理及使用掌握不是非常透彻之前，建议不要使用。最简单的方法，反而是最有效的，固然线程池可以帮助我们提高一点点的效率，但是为了这一点点的性能提升，而导致数据错误，真的是得不偿失！！
方案二：Shiro官方提供的Subject.associateWith(task)方法
推荐指数：💗💗💗💗
这个没啥可说的，官方出的方案，如果你心中充满执念，可以使用该方法进行处理。
可以使用Shiro官方的TaskExecutor,也可以自定义，小L采用的是自定义了，源码如下：
自定义一个ThreadPoolTaskExecutor 就叫它 ShiroSubjectAwareTaskExecutor：
public class ShiroSubjectAwareTaskExecutor extends ThreadPoolTaskExecutor {
@Override
public boolean prefersShortLivedTasks() {
return false;
}
@Override
public void execute(Runnable task) {
if (task instanceof SubjectRunnable) {
super.execute(task);
return;
}
// not SubjectRunnable and currentSubject not null
Subject currentSubject = ThreadContext.getSubject();
if (Objects.nonNull(currentSubject)) {
super.execute(currentSubject.associateWith(task));
} else {
super.execute(task);
}
}
}
这里重写了线程池的execute方法，在线程被提交执行前用Subject.associateWith(task)进行包装。
然后再创建线程池时使用我们自定义的ShiroSubjectAwareTaskExecutor
@PostConstruct
public void init() {
executor = new ShiroSubjectAwareTaskExecutor();
executor.setCorePoolSize(10);
executor.setMaxPoolSize(50);
executor.setQueueCapacity(10);
executor.setKeepAliveSeconds(5);
executor.setThreadNamePrefix("AYSNC-TEST");
// 线程池对拒绝任务的处理策略
// CallerRunsPolicy：由调用线程（提交任务的线程）处理该任务
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
// 初始化
executor.initialize();
}
注意，如果您的项目中存在多个线程池配置（包含且不限于java 8中的ForkJoinPool，ParallelStream等），都需要使用Subject.associateWith(task)进行处理。而且这个方法是return 包装类，不是对象引用,千万小心。
不得不说，Subject.associateWith(task) 这个API设计的感觉真心一般。应该用get或者rebuild来装饰一下这个方法名，否正会让调用者以为是引用传递呢！！
它的实现原理也非常简单，就是将我们的runnable进行了包装SubjectRunnable，然后在子线程真正执行之前bind() 用户信息，执行结束后进行unbind，源码如下：
org.apache.shiro.subject.support.SubjectRunnable#run()方法源码
public void run() {
try {
threadState.bind();
doRun(this.runnable);
} finally {
threadState.restore();
}
}
方案三：用Srping Security 替换Shiro
推荐指数：💗💗💗
看了一下Spring Security的源码，它默认是避免这个问题的，而且在API设计上，Spring Security 也支持通过策略模式，使用自己的ThreadContext存储策略，您甚至可以用redis来写实现。单从这一个小点来说，不得不承认，Spring Security在设计上确实优于Shiro。
-
Spring Security:
- 默认是ThreadLocalSecurityContextHoldStrategy
- 如果需要线程间传递，可以手工修改配置改为InheritedThreadLocalSecurityContextHoldStrategy
4.png
估计如果你修改为了InheritedThreadLocalSecurityContextHoldStrategy，也就代表者你知道这里面的风险，如果出现了问题，后果自负！ 相比于Shiro默认就使用来说，spring security 确实够良心！
方案四：大神之路 重写Shiro 的 ThreadContext
推荐指数：∞
从根本解决问题，高端玩法，目前只能给出相关参考资料：
- Alibaba transmittable-thread-local
如果你的业务需要『在使用线程池等会池化复用线程的执行组件情况下传递ThreadLocal』则是TransmittableThreadLocal目标场景。
结束语
我是一个被shiro伤过的Java小学生，欢迎大家吐槽留言。
如果您觉得这篇文章有用，请留下您的小💗💗。
网友评论