性能文章>空中楼阁之纸上谈兵 线程池执行流程图>

空中楼阁之纸上谈兵 线程池执行流程图原创

3年前
701502

一、jdk中的线程池

线程池java.util.concurrent.ThreadPoolExecutor中execute方法执行流程图如下
image.png
image.png


如图所示,要想扩展线程池,任务队列是否已满部分可以进行重写,即扩展BlockQueue,如tomcat、dubbo中都是自己新建了TaskQueue,其继承自LinkedBlockQueue,并重写了offer方法。
另需要继承java.util.concurrent.ThreadPoolExecutor,并重写execute方法,并扩展afterExecute方法。


备注:
流程图中的线程池假设线程池的状态是运行状态
另线程池状态变化如下图所示
image.png


二、扩展

1、tomcat下的线程池

tomcat中的ThreadPoolExecutor的execute方法如下
image.png

tomcat的TaskQueue中重写部分的执行流程图如下
image.png
image.png


2、dubbo下的线程池

dubbo的EagerThreadPoolExecutor的execute方法如下
image.png

dubbo的TaskQueue中重写部分的执行流程图如下
image.png
image.png


总结:
1、首先要明确,能执行到添加任务到队列中,当前的线程数必然达到了核心线程数;
2、其次,线程池的目的是为了快速执行任务为目标,那么当任务有积压时,这时最好能将线程数提高到最大,这样资源利用率才能最大化;
3、综上所述:先利用已经创建好的线程,执行刚添加的任务;
其次,为了加快执行效率,避免任务积压过多,先将线程数扩展到最大;
最后,再将任务进行积压。


欢迎各位批评指正,共同学习进步^_^😊

点赞收藏
分类:标签:
青叶竹
请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

随机一门技术分享之Netty

随机一门技术分享之Netty

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

2
0