本站消息

站长简介/公众号


站长简介:逗比程序员,理工宅男,前每日优鲜python全栈开发工程师,利用周末时间开发出本站,欢迎关注我的微信公众号:程序员总部,程序员的家,探索程序员的人生之路!分享IT最新技术,关注行业最新动向,让你永不落伍。了解同行们的工资,生活工作中的酸甜苦辣,谋求程序员的最终出路!

  价值13000svip视频教程,java大神匠心打造,零基础java开发工程师视频教程全套,基础+进阶+项目实战,包含课件和源码

  出租广告位,需要合作请联系站长


+关注
已关注

分类  

暂无分类

标签  

暂无标签

日期归档  

2020-11(403)

2020-12(497)

2021-01(423)

2021-02(280)

2021-03(351)

阅读Java源码之ThreadPoolExecutor

发布于2020-11-19 21:00     阅读(912)     评论(0)     点赞(13)     收藏(0)


前言

在使用Java的任务管理框架执行任务的过程中,饱和策略在任务等待队列已满并且提交新任务时起作用。 ThreadPollExecutor提供了四种饱和策略:

 

我们在上一节中介绍了它们的源代码。本节将看到它们之间的区别。 

测试类准备

首先定义MyCommand任务并接收字符串消息:

 

创建一个集成测试类。线程池的初始化大小为2、等待队列大小为2、如果提交的任务大于4、则由于不同的饱和度策略,第五个任务将获得不同的执行结果。在下一篇文章中,我们将设置不同的饱和度策略并测试行为上的差异。 

 

 

策略1:放弃通知模式

AbortPolicy是默认的饱和策略。该策略引发未经检查的异常RejectedExecutionException。调用者可以捕获此异常并根据需要编写代码。例如,尝试捕获异常并重新发送任务。该策略仍然很友好,并且至少在销毁任务之前会通知任务发送者。这是默认策略,因此,如果直接运行测试准备类的第一部分,结果将是:

 

测试结果:主线程发送4个任务后,队列已满。此时,提交第五项任务时,线程池引发了RejectedExecutionException,并且主线程能够捕获并处理该异常。 

策略2:以静默方式丢弃

DiscardPolicy,并以静默方式接受任务,但是在异常情况下不执行任何操作,并且调用方不知道任务的状态。

显然,这对任务控制没有帮助,因此我不推荐这种策略。

测试结果:发送了5个线程,仅执行了4个任务,最后提交的任务在调用者不知情的情况下被无情地抛弃了。

策略3:销毁等待时间最长的任务

DiscardOldestPolicy丢弃等待队列中等待时间最长的任务,将其从队列中删除,然后运行当前任务。这不适合等待时间最长的任务。

更改测试策略:

1
exec.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardOldestPolicy());

测试结果:发送了5个线程,但是仅执行了4个任务。最长的等待任务c3被销毁,呼叫者无法得知。

 

策略4:调用者执行

CallerRunsPolicy策略以提供协调机制。它不会放弃任务或引发异常,但会将任务的运行请求返回给任务的调用者,并且发送任务的线程会自行执行。任务已发送。

测试结果:发送了五个线程,但辅助线程仅执行了四个,而第五个任务由调用者执行。

 

结论:调用者执行的饱和策略实现了弹性调整机制。当工作队列已满时,下一个要执行的任务将在发送任务的主线程中执行。

当主线程执行任务时,线程资源被占用,无法发送其他任务。因此,任务提交率降低,线程池花费更多时间来完成排队的任务。

策略5:调用方限制

前四个传输,这是线程池饱和策略。另外,任务发送者可以控制任务的发送速率。即,限制任务的发送以避免任务饱和。例如,通过使用信号量来限制任务的到达速度,此同步工具类可以控制同时访问特定资源的操作数。您可以使用“获取信号量”来获取虚拟许可证。如果没有可用的许可证,则方法调用线程将被阻塞,直到可用的许可证为止。如果线程池使用无限队列来缓冲任务并且不控制任务数量,则很可能导致内存耗尽。然后,您可以在信号量中使用它来设置信号量上限并控制任务提交速度。将上一章中的MyCommand任务与Semaphore结合使用,以实现调用方控制任务发送的示例。

任务执行结果:

 

分析执行结果:使用semaphos将一次可以发送的任务数限制为只有两个。任务完成后,将释放信号灯权限,您可以有效地控制任务的提交速度。 

总结

Apocalypse的受限线程池的四种饱和策略中,只有AbortPolicy和CallerRunPolicy对任务发送者很友好,而其他的则错过了任务。这对于任务发送者是不利的。折衷方案是调用方控制任务的发送速度,并使用semaphoe根据线程池的配置大小来控制任务的发送。这将防止过多的任务提交。

原文链接:https://www.cnblogs.com/java0011/p/13935760.html



所属网站分类: 技术文章 > 博客

作者:java大师

链接:http://www.javaheidong.com/blog/article/1402/e1482b5897f8d8d13ca3/

来源:java黑洞网

任何形式的转载都请注明出处,如有侵权 一经发现 必将追究其法律责任

13 0
收藏该文
已收藏

评论内容:(最多支持255个字符)