本文转载自微信公众号「潜行前行」,作者cscw 。转载本文请联系潜行前行公众号。
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名注册、网络空间、营销软件、网站建设、桂平网站维护、网站推广。
1 前天大佬通过prometheus发现 tomcat http busy状态的线程这几天呈线性递增。每一天增加3个
1:找到busy线程在哪。通过jvm自带的 jps 命令可以找到服务对应的进程ID:66182$>$top -Hp 66182
$pidstat -u -p 66182 1 5
大部分的线程都正常,cpu利用率不高,而且线程ID变动快,基本排除 死循环、CPU 空转的问题
2:既然不是死循环、CPU空转。那是不是代码阻塞的问题呢。导出 66182 进程jvm的 stack 文件 jstack -l 66182 > block66182.jstack。因为知道是http 线程的问题。http 的开头一般都是 http-nio 。可以使用 grep -A 15 'http-nio' block66182.jstack 输出一些关键信息。找了很久,多数http 都是正常状态。然后还找到了项目代码 updateXYDVerifiedCodeByDate 之类的。定位到具体,发现是一个定时任务
3 查了下 xxl-task 调度日志。凌晨左右调度了十次,失败了三次,和在prometheus发现的 busy http线程增加的规律是一致的
4 查找代码发现是 CompletableFuture 调用get阻塞住了。后来改成 future.get(15, TimeUnit.SECONDS);。则每隔 15 秒报错一次。但是在promethues 监控到 verifiedCodeQueryExecutor 的线程队列是空的。
4.1 promethues 监控到的线程队列数为空
5 没有任务 CompletableFuture 的get方法还在执行,查看下 verifiedCodeQueryExecutor 的定义。发现,阻塞队列的拒绝策略 是 DiscardPolicy 丢弃。也就是任务丢弃了不被执行,而封装成的CompletableFuture 自然就不会有结果返回,因此一直会被阻塞,而改了代码则是超时返回。真相大白。。。。。
1:队列无限,好像不太好,不接受
2:自定义拒绝策略
- new RejectedExecutionHandler(){
- @Override
- public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
- throw new RuntimeException(" over size error ");
- }
- }
3:但考虑到任务必须被处理掉,任务不能被丢弃啊。so 暂时用 CallerRunsPolicy 策略,executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
4:后面再优化
新闻名称:优化排查线程阻塞:CompletableFuture和DiscardPolicy
当前链接:http://www.shufengxianlan.com/qtweb/news10/54260.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联