具体配置是啥？
我找到具体配置其实是一个很快的过程。
因为这个类的 value 参数简直太友好了：
五处调用的地方，其中四处都是注释。
有效的调用就这一个地方，直接先打上断点再说：
org.springframework.scheduling.annotation.AnnotationAsyncExecutionInterceptor#getExecutorQualifier
发起调用之后，果然跑到了断点这个地方：
顺着断点往下调试，就会来到这个地方：
org.springframework.aop.interceptor.AsyncExecutionAspectSupport#determineAsyncExecutor
这个代码结构非常的清晰。
编号为 ① 的地方，是获取对应方法上的 @Async 注解的 value 值。这个值其实就是 bean 名称，如果不为空则从 Spring 容器中获取对应的 bean。
如果 value 是没有值的，也就是我们 Demo 的这种情况，会走到编号为 ② 的地方。
这个地方就是我要找的默认的线程池。
最后，不论是默认的线程池还是 Spring 容器中我们自定义的线程池。
都会以方法为维度，在 map 中维护方法和线程池的映射关系。
也就是编号为 ③ 的这一步，代码中的 executors 就是一个 map：
这个玩意是一个函数式编程，所以如果你不知道这个玩意是干什么的，调试起来可能有点懵逼：
我建议你去恶补一下， 10 分钟就能入门。
最终你会调试到这个地方来：
org.springframework.aop.interceptor.AsyncExecutionAspectSupport#getDefaultExecutor
这个代码就有点意思了，就是从 BeanFactory 里面获取一个默认的线程池相关的 Bean 出来。流程很简单，日志也打印的很清楚，就不赘述了。
但是我想说的有意思的点是，我不知道你看到这份代码，有没有看出一丝丝双亲委派内味。
都是利用异常，在异常里面处理逻辑。
就上面这“垃圾”代码，直接就触犯了阿里开发规范中的两大条：
在源码里面这就是好代码。
在业务流程里面，这就是违反了规范。
所以，说一句题外话。
就是阿里开发规范我个人感觉，其实是针对我们写业务代码的同事一个最佳实践。
但是当把这个尺度拉到中间件、基础组件、框架源码的范围时，就会出现一点水土不服的症状，这个东西见仁见智，我是觉得阿里开发规范的 idea 插件，对于我这样写增删查改的程序员来说，是真的香。
不说远了，我们还是回来看看获取到的这个线程池：
这不就找到我想要的东西了吗，这个线程池的相关参数都可以看到了。
也证实了我之前猜想：
我觉得核心线程数配置是 8 ，队列长度应该是 Integer.MAX_VALUE。
但是，现在我是直接从 BeanFactory 获取到了这个线程池的 Bean，那么这个 Bean 是什么时候注入的呢？
朋友们，这还不简单吗？
我都已经拿到这个 Bean 的 beanName 了，就是 applicationTaskExecutor，但凡你把 Spring 获取 bean 的流程的八股文背的熟练一点，你都知道在这个地方打上断点，加上调试条件，慢慢去 Debug 就知道了：
org.springframework.beans.factory.support.AbstractBeanFactory#getBean(java.lang.String)
假设你就是不知道在上面这个地方打断点去调试呢？
再说一个简单粗暴的方法，你都拿到 beanName 了，在代码里面一搜不就出来了嘛。
简单粗暴效果好：
org.springframework.boot.autoconfigure.task.TaskExecutionAutoConfiguration
都找到这个类了，随便打个断点，就可以开始调试了。
再说一个骚一点的操作。
假设我现在连 beaName 都不知道，但是我知道它肯定是一个被 Spring 管理的线程池。
那么我就获取项目里面所有被 Spring 管理的线程池，总有一个得是我要找的吧？
你看下面截图，当前这个 bean 不就是我要找的 applicationTaskExecutor 吗？
这都是一些野路子，骚操作，知道就好，有时候多个排查思路。
