mikicomo

这里展开说一下，其实自己项目使用自己封装过后的线程池是个好习惯，不过如果只是为了控制线程池个数的话，那倒也大可不必，原生的配置也蛮好。
一般我们遇到自己封装线程池的场景，主要是为了传递一些系统中的参数，比如你既然是个异步任务，如果是由外部的一个请求触发的，再这样的场景下，我们做全链路日志会比较麻烦，因为原生线程池是不会传递 jvm 参数的，所以需要我们封装一下，这样就可以方便的在日志系统中通过一个 logid 搜索全链路日志了。

另一个好处是，自己封装的线程池，我们也可以方便做一些 feature 进去，比如动态扩容，缩容线程池，如果一开始都用了系统的，没有统一收口的话，就会比较麻烦

另外，sendMsgBatch 方法中循环调用了 this.sendTemplateMsg ，注意同个类下，两个 async 方法相互调用时，@async 会失效，如果作者没有在 sendMsgBatch 另起 TaskExcutor 的话，可能和它的本意不符了（ sendMsgBatch 本身虽然是异步，但是内部的循环执行降级为了同步，线程也占用了很久），现在作者的这种写法，是把压力都丢给了 TaskExcutor ，让他慢慢去执行，@async 开出的线程池立马就释放了

道理是这个道理，但是这么写，其实也不是很建议就是了

简单看了下,作者应该是希望用 TaskExcutor 中统一管理的线程池去执行系统中的任务，那么从这点看 sendTemplateMsg 上加 @Async 的确有点画蛇添足了，TaskExcutor.submit 直接提交任务即可。

那么关于这个 @Async 注解为什么这里还加了呢，我个人猜测是，是不是第一版的时候并没有 TaskExcutor ？后来才单独抽出来改造了一版？建议可以看看 git 提交记录，这里我也没 down 代码下来看，不负责任猜测一下😂

jojo
fate 系列
命运石之门
冰菓

0

建议学习向上管理。

广告可以关，#68 楼已经说了，就我旁边的同事和我个人，以及一些教师朋友反馈下来，wps 足矣，用着都感觉不错