思路：对高并发的接口，单独配置线程池。需考虑线程池内的线程数量，以及tomcat总线程数量与CPU的关系。
线程池的配置
接口如何配置单独的线程池
异步任务 @Async(“myExecutors”)
对实时性要求高的
分析下：实时就是同步，每一次请求就是一条线程，高并发就意味着同时运行大量线程，大量线程意味着对CPU时间片的抢夺会变多，导致CPU使用率飙升，同时IO运算较多也会导致内存占用飙升。总结一下就是，单机是有瓶颈的，我们要测出单机的并发瓶颈，然后使用多机部署（集群or微服务）
QPS://todo
TPS://todo
怎么集群
//todo
怎么微服务
//todo
对实时性要求不高的
⑴ 设置接口幂等性，返回唯一ID，让调用方通过ID查询此次的运行结果（这里用UUID标识的唯一ID，正式项目用 SnowFlake）
@ApiOperation("测试SUCCESS")
@RequestMapping("/success")
@WebLog(description = "请求了测试接口")
@Async("myExecutors")
public ResultVo testSuccess(@ApiParam("入参") @RequestBody TestVo testVo) {
//业务逻辑处理
String resultCode = service.run();
return new ResultVo(resultCode, testVo.getID());
}
（2）提供回调，调用方传入需要回调的接口地址，待异步执行后，把结果返回
@ApiOperation("测试SUCCESS")
@RequestMapping("/success")
@WebLog(description = "请求了测试接口")
@Async("myExecutors")
public void testSuccess(@ApiParam("入参") @RequestBody TestVo testVo) {
//业务逻辑处理
String resultCode = service.run();
//结果回调
AsyncUtil.callBack(testVo.getUrl(),new ResultVo(ResultEnum.SUCCESS, testVo.getID()));
}
线程池的选择
-
使用ThreadPoolExecutor,不要用Executors,具体原因网上搜，一堆
-
BlockingQueue对应三种，ArrayBlockingQuere:需要自己设置队列的容量，队列满了以后，将会开始创建maxPoolSize允许的线程数；LinkedBlockingQueue:队列的容量默认设置成了Integer.MaxValue;SynchronousQueue:不存储元素的队列，会直接给线程，使用它的话，线程数量很容易达到maxPoolSize;
单个线程池的线程数量设置
不要相信什么CPU数量+1，CPU数量 X 2 这种公式
理应通过排查当前服务器cpu使用率和负载，对要使用线程的任务进行压测，通过不断的调整CPU使用率和线程数，达到一个领自己满意的数值，这才是最适合的线程数量，如果非要给一个初始值，那么就是核的数量吧，然后反复调整，确定最终的值。
top：命令查询cpu使用率
cpuinfo:文件里查看核心数
线程总数量和CPU的关系
linux中，对于进程所拥有的的线程数有限制，一个进程最大线程数为1024
Tomcat和请求的关系
#最大队列数
server.tomcat.accept-count=100
#最大链接数
server.tomcat.max-connections=8192
#最大线程数
server.tomcat.max-threads=100
- tomcat的最大线程数，可以决定同时处理客户端的请求数量。
- 最大连接数一定要大于最大线程数，否则会有很多请求无响应
