springboot获取Request的方式和线程是否安全讨论
1.获取Request的三种方式一、直接注入的方式（保举）
作为一名稍微欺压症的开发人员，只保举这种方式，因为这种直接注入的可以在controller、service等任何你想要注入的地方注入，轻易明白，这种方式后面将会继续讨论是否是线程安全。
@RestController
@RequestMapping("/request")
@RequiredArgsConstructor//通过构造器注入
public class RequestController {
private final HttpServletRequest request1;
@GetMapping("/test1")
public void test1() {
//注入后就可以直接使用
request1.setAttribute("userName","leakey");
}
}
二、在controller里面利用参数注入（不保举）
这种方式request是作为controller的参数注入进来的，优点就是直观，让人感觉到每个请求都是独立的request(硬夸)，缺点是后面的service或者其他地方必要用request对象的时候，必要带着他到处跑，那么优秀的你，想必也不能忍受吧！
@RestController
@RequestMapping("/request")
public class RequestController {
@GetMapping("/test2")
public void test2(HttpServletRequest request2){
request2.setAttribute("userName","leakey");
}
} 三、通过RequestContextHolder获取
这种方式也可以在任何地方获取Request，优点固然是方便，缺点稍微不那么直观
@RestController
@RequestMapping("/request")
public class RequestController {
@GetMapping("/test3")
public void test3(){
ServletRequestAttributes servletRequestAttributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
HttpServletRequest request3 = servletRequestAttributes.getRequest();
request3.setAttribute("userName","leakey");
}
}
2.谈谈线程安全的问题
一、疑问？是否存在线程安全
一个小同伴看了我写的代码，问我第一种用注入的方式获取的request是否存在线程安全问题，毕竟这个controller是单例，注入进来的request对象是不是也有大概是单例呢？越说越冲动，仿佛要发现一个大bug了，我立马做了一个小实验来简朴验证下。
@RestController
@RequestMapping("/request")
@RequiredArgsConstructor
@Slf4j
public class RequestController {
private final HttpServletRequest request1;
@GetMapping("/test1")
public void test1() throws InterruptedException {
request1.setAttribute("userName","leakey");
log.info("success to set attribute userName,I'll go to sheep for 10 seconds");
Thread.sleep(10000);
}
@GetMapping("/test2")
public void test2() {
log.info("I am another quest,I'll try to get attribute userName");
Object userName = request1.getAttribute("userName");
log.info("userName is " + userName);
}
} 先访问接口test1，在10秒内访问test2接口，日记如下：
2024-09-08T11:08:34.155+08:00INFO 34680 --- c.l.learn.controller.RequestController : success to set attribute userName,I'll go to sheep for 10 seconds
2024-09-08T11:08:43.036+08:00INFO 34680 --- c.l.learn.controller.RequestController : I am another quest,I'll try to get attribute userName
2024-09-08T11:08:43.036+08:00INFO 34680 --- c.l.learn.controller.RequestController : userName is null 很清晰的看到 test2的请求是拿不到test1设置进去的内容的，以是这个时刻你就可以大胆一点，跟同事先打包票出问题了算我的！。
二、大胆假设，小心求证
我们先修改下代码结构，打个断点，如下：
https://i-blog.csdnimg.cn/direct/1dedd5faa3084bd8b1be70394d6bab58.png
我们发现注入的是一个WebApplicationContextUtils里面的内部类RequestObjectFactory，注意到这里有一个getObject方法，返回是一个ServletRequest对象，方法是怎样被调用的呢？我们继续分析。
@SuppressWarnings("serial")
private static class RequestObjectFactory implements ObjectFactory<ServletRequest>, Serializable {
@Override
public ServletRequest getObject() {
return currentRequestAttributes().getRequest();
}
@Override
public String toString() {
return "Current HttpServletRequest";
}
} 我们可以在断点的地方看出来注入的内容一个署理对象，为AutowireUtils下面的ObjectFactoryDelegatingInvocationHandler，当我们必要获取对象的时候，就会执行反射method.invoke()方法，也就是说实际上就是调用了getObject方法里面的currentRequestAttributes().getRequest()方法了
private static class ObjectFactoryDelegatingInvocationHandler implements InvocationHandler, Serializable {
private final ObjectFactory<?> objectFactory;
ObjectFactoryDelegatingInvocationHandler(ObjectFactory<?> objectFactory) {
this.objectFactory = objectFactory;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
return switch (method.getName()) {
case "equals" -> (proxy == args); // Only consider equal when proxies are identical.
case "hashCode" -> System.identityHashCode(proxy); // Use hashCode of proxy.
case "toString" -> this.objectFactory.toString();
default -> {
try {
yield method.invoke(this.objectFactory.getObject(), args);
}
catch (InvocationTargetException ex) {
throw ex.getTargetException();
}
}
};
}
} 通过上面的分析，当我们必要执行request里面的方法的时候（好比执行getAttribute或者setAttribute），就会先执行currentRequestAttributes().getRequest()来获取对象，那我们继续看看currentRequestAttributes方法到底拿到什么？
private static ServletRequestAttributes currentRequestAttributes() {
RequestAttributes requestAttr = RequestContextHolder.currentRequestAttributes();
if (!(requestAttr instanceof ServletRequestAttributes servletRequestAttributes)) {
throw new IllegalStateException("Current request is not a servlet request");
}
return servletRequestAttributes;
} 我们注意到currentRequestAttributes方法里面返回的是RequestContextHolder对象里面的requestAttributesHolder ，而且requestAttributesHolder 这个对象是用ThreadLocal包装起来的，也就是他是线程安全的
/**
* Holder class to expose the web request in the form of a thread-bound
* {@link RequestAttributes} object. The request will be inherited
* by any child threads spawned by the current thread if the
* {@code inheritable} flag is set to {@code true}.
*/
public abstract class RequestContextHolder {
private static final boolean jsfPresent =
ClassUtils.isPresent("jakarta.faces.context.FacesContext", RequestContextHolder.class.getClassLoader());
//线程安全
private static final ThreadLocal<RequestAttributes> requestAttributesHolder =
new NamedThreadLocal<>("Request attributes");
private static final ThreadLocal<RequestAttributes> inheritableRequestAttributesHolder =
new NamedInheritableThreadLocal<>("Request context"); RequestContextHolder类里面有两个告急的对象，一个是requestAttributesHolder，别的一个inheritableRequestAttributesHolder，开发老手一看就知道，一个是线程安全对象，只对当前线程可见，别的一个是针对子线程也可见。
我们一起来阅读下RequestContextHolder上面的注释，“一个持有者类，用于以线程绑定RequestAttributes对象的情势暴露Web请求。如果可继承标志被设置为true，那么由当前线程产生的任何子线程都将继承这个请求”
看到源码，我们也就知道解释清晰第三种方法，通过RequestContextHolder获取request
总结下：这是一个线程安全获取request的方式，各人轻松利用吧！
欢迎各人遇到不懂的地方，也可以咨询，一起办理问题！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]