我们的APP生产上出了一次比较严重的事故，许多用户投诉登录后能看到别人的信息，收到投诉后我们就开始查找问题，一般这样的问题都是线程安全引起的，所以查找原因的思路也是按线程安全的思路去查。
业务场景是这样的，用户登录后，点击一个页面查看信息，这个信息显示了别人的信息。
登录交易大致流程如下：
//一系列验证
session.setAttribute("id",id); //身份证号放入session
//其他操作查看信息交易的流程如下：
session = request.getSession();
if(session != null && session.getAttribute("LoginStatus") == True) {
String id = session.getAttribute("id");
Information info = queryInfo(id);
return info;
} else {
return "not login";
}通过加日志等方法，我们确认了是查看信息的时候，从session里拿出来的身份证号是其他人的，但是到底是在什么时候变化的，没找到，因为我们一直顺着线程安全的思路，找全局变量这样的地方。
另外还发现有个地方可疑，就是有一个异步的线程，会验证用户身份证，并且重新在session里放一次。
public void updateId(HttpServletRequest request) {
HttpSession session = request.getSession();
String id = validate();
session.setAttribute("id",id);
}这个函数是在登录主交易调起的线程池处理的，看上去其实没有多大毛病，而且也是老的代码，很久了。而且我发现了一个规律，被别人看到信息的用户，登录交易都触发了使用新设备登录，因为我们加了一个逻辑，对换设备登录做了验证，这样的话需要验证短信，登录分两步了，第一步比较快的返回了，但是异步的更新信息流程还在。
于是我怀疑是不是因为Servlet的交易已经返回了，异步的线程虽然拿到了HttpServletRequest，但是这个request已经无效了或者被复用了。
我写了下面的代码进行验证，不停的用curl调用。Http请求很快就返回了，但是我会把HttpServletRequest传给一个线程池，等5s后才会去处理这个Request，结果果然是有问题的
结果果然有问题，大部分情况new_session都是null，但也出现了不是null的情况，这时候发现session不是自己的。
HttpServletRequest是有生命周期的，当一个http请求过来后，应用服务器解析报文，把各种参数放到一个HttpServletRequest对象中，然后传递给Servlet的service函数，service函数根据里面的方法调用对应的doGet/doPost等方法，而一旦service函数调用结束，HttpServletRequest的生命周期就结束了，再这之后你继续使用这个对象，产生的结果是不确定的。
网上遇到这类问题的人不多，我专门找了servlet specification，其中有一章讲HttpServletRequest生命周期的。
从中可以得到如下信息：
(1)三种情况下request有效：service函数内，doFilter函数内，startAsync起的异步线程
(2)在三种情况之外，使用request会产生不确定的结果(indeterminate results)
(3)大部分容器在实现servlet的时候，为了提高性能，会复用request对象，但这不是规范里必须的
其中提到的startAsync是servlet 3.0开始有的，它是为了让一个工作线程可以在做IO或类似阻塞线程的操作的时候能干其它的事情，但是它要求异步线程都结束了，才会将请求返回给客户端，本质上还是同步的，只是并行了。所以要想异步的处理Request，必须使用servlet自己的异步机制，但是这样并不能满足我们的需求，因为我们就是为了不让主线程等待。
用法示例：
如果使用了这个，那么客户端需要等待5s才能拿到结果。
我又看了tomcat的源码，发现它确实对Request做了复用：
虽然问题的原因很简单，但是产生的后果十分严重。需要异步处理数据的时候一定要特别小心，此处如果传Session就没问题了，但是还是要尽量避免。