SpringMVC一个Controller处理所有用户请求的并发问题
有状态和无状态的对象基本概念：
有状态对象(Stateful Bean)，就是有实例变量的对象 ，可以保存数据，是非线程安全的。一般是prototype scope。
无状态对象(Stateless Bean)，就是没有实例变量的对象，不能保存数据，是不变类，是线程安全的。一般是singleton scope。
如Struts2中的Action，假如内部有实例变量User，当调用新增用户方法时，user是用来保存数据，那么此action是有状态对象。多个线程同时访问此action时 会造成user变量的不一致。所以action的scope要设计成prototype，或者，User类放到threadLocal里来保持多个线程不会造成User变量的乱串（此种场景没必要放到threadLocal内）。
而Service内部一般只有dao实例变量 如userDao, 因为userDao是无状态的对象（内部无实例变量且不能保存数据），所以service也是无状态的对象。
public class XxxAction{
// 由于多线程环境下，user是引用对象，是非线程安全的
public User user;
......
}
public class XxxService {
// 虽然有billDao属性，但billDao是没有状态信息的，是Stateless Bean.
BillDao billDao;
......
}
对于那些会以多线程运行的单例类
局部变量不会受多线程影响，
成员变量会受到多线程影响。
多个线程调用同一个对象的同一个方法：
如果方法里无局部变量，那么不受任何影响；
如果方法里有局部变量，只有读操作，不受影响；存在写操作，考虑多线程影响值；
例如Web应用中的Servlet，每个方法中对局部变量的操作都是在线程自己独立的内存区域内完成的，所以是线程安全的。
对于成员变量的操作，可以使用ThreadLocal来保证线程安全。
springMVC中，一般Controller、service、DAO层的scope均是singleton；
每个请求都是单独的线程,即使同时访问同一个Controller对象，因为并没有修改Controller对象，相当于针对Controller对象而言，只是读操作，没有写操作，不需要做同步处理。
Service层、Dao层用默认singleton就行，虽然Service类也有dao这样的属性，但dao这些类都是没有状态信息的，也就是 相当于不变(immutable)类，所以不影响。
Struts2中的Action因为会有User、BizEntity这样的实例对象，是有状态信息 的，在多线程环境下是不安全的，所以Struts2默认的实现是Prototype模式。在Spring中，Struts2的Action中scope 要配成prototype作用域。
Spring并发访问的线程安全性问题
由于Spring MVC默认是Singleton的，所以会产生一个潜在的安全隐患。根本核心是instance变量保持状态的问题。这意味着每个request过来，系统都会用原有的instance去处理，这样导致了两个结果：
一是我们不用每次创建Controller，
二是减少了对象创建和垃圾收集的时间；
由于只有一个Controller的instance，当多个线程同时调用它的时候，它里面的instance变量就不是线程安全的了，会发生窜数据的问题。
当然大多数情况下，我们根本不需要考虑线程安全的问题，比如dao,service等，除非在bean中声明了实例变量。因此，我们在使用spring mvc 的contrller时，应避免在controller中定义实例变量。
如：
public class Controller extends Abstract CommandController{
private Company company;
protected ModelAndView handle(HttpServletRequest request,HttpServletResponse response)
throws Exception{
company =................;
}
}在这里有声明一个变量company，这里就存在并发线程安全的问题。
如果控制器是使用单例形式，且controller中有一个私有的变量a,所有请求到同一个controller时，使用的a变量是共用的，即若是某个请求中修改了这个变量a，则，在别的请求中能够读到这个修改的内容。。
有几种解决方法：
1、在控制器中不使用实例变量
2、将控制器的作用域从单例改为原型，即在spring配置文件Controller中声明 scope="prototype"，每次都创建新的controller
3、在Controller中使用ThreadLocal变量
这几种做法有好有坏：
第一种：需要开发人员拥有较高的编程水平与思想意识，在编码过程中力求避免出现这种BUG。
第二种：是容器自动的对每个请求产生一个实例，由JVM进行垃圾回收，因此做到了线程安全。
使用第一种方式的好处是实例对象只有一个，所有的请求都调用该实例对象，速度和性能上要优于第二种，不好的地方，就是需要程序员自己去控制实例变量的状态保持问题。
使用第二种由于每次请求都创建一个实例，所以会消耗较多的内存空间。
所以在使用spring开发web 时要注意，默认Controller、Dao、Service都是单例的。
第三种：
项目使用线程池技术，可以动态配置线程数、可以重用线程。然而，如果你在项目中使用到了ThreadLocal，一定要记得使用前或者使用后remove一下。这是因为上面提到了线程池技术做的是一个线程重用，这意味着代码运行过程中，一条线程使用完毕，并不会被销毁而是等待下一次的使用。
我们看一下Thread类中，持有ThreadLocal.ThreadLocalMap的引用：
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
线程不销毁意味着上条线程set的ThreadLocal.ThreadLocalMap中的数据依然存在，那么在下一条线程重用这个Thread的时候，很可能get到的是上条线程set的数据而不是自己想要的内容。
这个问题非常隐晦，一旦出现这个原因导致的错误，没有相关经验或者没有扎实的基础非常难发现这个问题，因此在写代码的时候就要注意这一点，这将给你后续减少很多的工作量。
上述关于ThreadLocal部分的内容 参考原文：https://blog.csdn.net/aqu415/article/details/79183261
ThreadLocal 使用范例：
//定义ThreadLocal变量
private ThreadLocal<String> logIp = new ThreadLocal<>();
@RequestMapping(value = "/getIdentityInformationByCardId", method = {RequestMethod.GET, RequestMethod.POST}, produces = MediaType.APPLICATION_JSON_UTF8_VALUE)
public ApiResponse getIdentityInformationByCardId(@RequestParam(value = "cardId") String cardId) throws Exception {
//代码
//Object result = ...
//将接口访问信息记录到系统日志表
try {
//每次请求 在赋值前，输出null
System.out.println("******=>" + logIp.get());
// 赋值
logIp.set(WebUtils.getIpAddress(RequestUtil.getRequest()));
sysLogService.saveImplTwo(logIp.get(), LogTypeEnum.SEARCH.toString());
// threadlocal 实例变量使用后，必须清除，因为线程使用完毕后不会销毁而是会重新回到线程池被等待的请求继续使用，如果不清除，则会带着当前请求的信息（实例变量），从而发生串值，影响线程安全。
logIp.remove();
} catch (Exception e) {
logger.error("接口访问信息记录到当前系统日志表时异常：", e);
e.printStackTrace();
}
return ApiResponse.success(result);
}
ThreadLocal和线程同步机制相比有什么优势呢？
ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。
在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。
而ThreadLocal则从另一个角度来解决多线程的并发访问。ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。
概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。
上述文章参考了不少相关博文，也加入了自己的一些理解，在此做个小结，希望能有益各位！