线上某dubbo服务A调用dubbo服务B的接口X方法,调用端A日志中出现了很多超时的情况,提供端B该接口X超时时间设置为60s: 查看提供端B的日志,报了很多线程池满的异常: Caused by: java.util.concurrent.RejectedExecutionException: Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-10.1.5.69:20914, Pool Size: 700 (active: 70

记一次线上dubbo服务超时和线程池满问题排查 可能调用的接口没问题,但是该服务中的其他接口占用完了线程池,导致调用超时被拒绝处理.

DynamicTp 简介 DynamicTp 是一个基于配置中心实现的轻量级动态线程池管理工具,主要功能可以总结为 动态调参.通知报警.运行监控.三方包线程池管理等几大类. 经过几个版本迭代,目前最新版本v1.0.6具有以下特性 特性 代码零侵入:所有配置都放在配置中心,对业务代码零侵入 轻量简单:基于 springboot 实现,引入 starter,接入只需简单4步就可完成,顺利3分钟搞定 高可扩展:框架核心功能都提供 SPI 接口供用户自定义个性化实现(配置中心.配置文件解析.通知告警.监

问题描述 线上突然出现Dubbo超时调用,时间刚好为Consumer端设置的超时时间. 有好几个不同的接口都报超时了 第1次调用超时,第2次(或第3次)重试调用非常快(正常水平) Dubbo调用超时的情况集中出现了3次,每次都是过一会自动恢复 排查 排查日志 看到调用超时,首先就拿着traceId去服务提供方查日志. 奇怪的是,在服务提供方的业务日志里面,只有正常的调用日志(耗时正常),没有超时调用的日志. 从正常的调用日志里面看,一切都是正常的,看不出所以然. 给人的感觉就是超时那次请求的调用

前言 micrometer中自带了很多其他框架的指标信息,可以很方便的通过prometheus进行采集和监控,常用的有JVM的信息,Http请求的信息,Tomcat线程的信息等. 对于一些比较活跃的框架,有些还是不支持的,比如Dubbo.如果想监控Dubbo的一些指标,比如线程池的状况,我们需要手动去扩展,输出对应的线程池指标才行. 在这种情况下,肯定是没什么思路的,因为你不知道怎么去扩展,下面给大家介绍去做一件事情之前的思考,方式方法很重要. Dubbo有没有现成的实现? 参考micromet

一.线程池的作用 平时的业务中,如果要使用多线程,那么我们会在业务开始前创建线程,业务结束后,销毁线程.但是对于业务来说,线程的创建和销毁是与业务本身无关的,只关心线程所执行的任务.因此希望把尽可能多的cpu用在执行任务上面,而不是用在与业务无关的线程创建和销毁上面.而线程池则解决了这个问题. 线程池的作用:线程池作用就是限制系统中执行线程的数量.根据系统的环境情况,可以自动或手动设置线程数量,达到运行的最佳效果,从而避免平凡的创建和销毁线程带来的系统开销也有效的规避了因为创建的线程过多而耗尽系

在dubbo调用过程中被调用方有两个线程池:io线程池,业务线程池. 这也是dubbo调优的点. 配置信息: <dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" /> Dispatcher all 所有消息都派发到线程池,包括请求,响应,连接事件,断开事件,心跳等. direct 所有消息都不派发到线程池,全部

jdk自带的原生的拒绝策略抛出的异常信息不够详细,而dubbo对拒绝策略进行了改写,抛出的信息更具有参考价值,值得我们借鉴. jdk自带的原生拒绝策略抛出的信息: // ThreadPoolExecutor的toString方法 /** * Returns a string identifying this pool, as well as its state, * including indications of run state and estimated worker and * tas

现象 在应用的 service_stdout.log里一直输出下面的日志,直接把磁盘打满了: 23:07:34.441 [TAIRCLIENT-1-thread-1] DEBUG io.netty.channel.nio.NioEventLoop - Selector.select() returned prematurely 14 times in a row. 23:07:34.460 [TAIRCLIENT-1-thread-3] DEBUG io.netty.channel.nio.Ni

Dubbo默认的底层网络通讯使用的是Netty,服务提供方NettyServer使用两级线程池,其中 EventLoopGroup(boss) 主要用来接受客户端的链接请求,并把接受的请求分发给 EventLoopGroup(worker) 来处理,boss和worker线程组我们称之为IO线程. 如果服务提供方的逻辑能迅速完成,并且不会发起新的IO请求,那么直接在IO线程上处理会更快,因为这减少了线程池调度. 但如果处理逻辑很慢,或者需要发起新的IO请求,比如需要查询数据库,则IO线程必须派发

文章首发在公众号(龙台的技术笔记),之后同步到个人网站:xiaomage.info Hippo-4J 距离上一个版本 1.2.1 已经过去一个月的时间.在此期间,由 8 位贡献者 提交了 170+ commits,正式发布 1.3.0 版本. 注:这是一个 兼容历史版本 的重大升级. Github:https://github.com/mabaiwan/hippo4j Gitee:https://gitee.com/mabaiwancn/hippo4j HIPPO-4J 1.3.0 Featur

最近一个服务突然出现 OutOfMemoryError,两台服务因为这个原因挂掉了,一直在full gc.还因为这个问题我们小组吃了一个线上故障.很是纳闷,一直运行的好好的,怎么突然就不行了呢... 配置了一个  -XX:+HeapDumpOnOutOfMemoryError(该参数作用是在第一次发生OOM错误时候会打印dump内存信息),便开始通过dump文件开始查找问题.   项目各项环境参数: 项目使用dubbo框架,dubbo线程池配置500 项目内存配置2G,old区1.5G 项目使用

什么是线程池? 为了避免频繁重复的创建和销毁线程,我们可以让这些线程进行复用,在线程池中,总会有活跃的线程在占用,但是线程池中也会存在没有占用的线程,这些线程处于空闲状态,当有任务的时候会从池子里面拿去一个线程来进行使用,当完成工作后,并没有销毁线程,而是将将线程放回到池子中去. 线程池主要解决两个问题: 一是当执行大量异步任务时线程池能够提供很好的性能. 二是线程池提供了一种资源限制和管理的手段,比如可以限制现成的个数,动态新增线程等. ​ -<Java并发编程之美> 上面内容出自<J

这是why的第 45 篇原创文章.说点不一样的线程池执行策略和线程拒绝策略,探讨怎么让线程池先用完最大线程池再把任务放到队列中. 荒腔走板 大家好,我是 why,一个四川程序猿,成都好男人. 先是本号的特色,技术分享之前先简短的荒腔走板聊聊生活.让文章的温度更多一点点. 上面的图是我在一次跑步的过程中拍的.活动之前赛事方搞了个留言活动,收集每公里路牌的一个宣传语. 我的留言有幸被选中了: 每人知道你在坚持什么,但你自己心里应该清楚. 是在说跑马拉松,也是在说其他的事情. 我记得那天的太阳,骄阳似

最近精读Netty源码,读到NioEventLoop部分的时候,发现对Java线程&线程池有些概念还有困惑, 所以深入总结一下 Java线程池一:线程基础 为什么需要使用线程池 Java线程映射的是系统内核线程,是稀缺资源,使用线程池主要有以下几点好处 降低资源消耗:重复利用池中线程降低线程的创建和消耗造成的资源消耗. 提高响应速度:任务到达时直接使用池总中空闲的线程,可以不用等待线程创建. 提高线程的可管理性:线程是稀缺资源,不能无限制创建,使用线程池可以统一进行分配.监控.调优. 线程池框架

本文转载自Java线程池实现原理及其在美团业务中的实践 导语 随着计算机行业的飞速发展,摩尔定律逐渐失效,多核CPU成为主流.使用多线程并行计算逐渐成为开发人员提升服务器性能的基本武器.J.U.C提供的线程池:ThreadPoolExecutor类,帮助开发人员管理线程并方便地执行并行任务.了解并合理使用线程池,是一个开发人员必修的基本功. 本文开篇简述线程池概念和用途,接着结合线程池的源码,帮助读者领略线程池的设计思路,最后回归实践,通过案例讲述使用线程池遇到的问题,并给出了一种动态化线程池解

转自美团技术团队:https://tech.meituan.com/2020/04/02/java-pooling-pratice-in-meituan.html 随着计算机行业的飞速发展,摩尔定律逐渐失效,多核CPU成为主流.使用多线程并行计算逐渐成为开发人员提升服务器性能的基本武器.J.U.C提供的线程池:ThreadPoolExecutor类,帮助开发人员管理线程并方便地执行并行任务.了解并合理使用线程池,是一个开发人员必修的基本功. 本文开篇简述线程池概念和用途,接着结合线程池的源码,帮

原文地址:http://www.codeceo.com/article/java-thread-pool-kernal.html 前言 多线程编程中,为每个任务分配一个线程是不现实的,线程创建的开销和资源消耗都是很高的.线程池应运而生,成为我们管理线程的利器.Java 通过Executor接口,提供了一种标准的方法将任务的提交过程和执行过程解耦开来,并用Runnable表示任务. 下面,我们来分析一下 Java 线程池框架的实现ThreadPoolExecutor. 下面的分析基于JDK1.7

前言 多线程编程中,为每个任务分配一个线程是不现实的,线程创建的开销和资源消耗都是很高的.线程池应运而生,成为我们管理线程的利器.Java 通过Executor接口,提供了一种标准的方法将任务的提交过程和执行过程解耦开来,并用Runnable表示任务. 下面,我们来分析一下 Java 线程池框架的实现ThreadPoolExecutor. 下面的分析基于JDK1.7 生命周期 ThreadPoolExecutor中,使用CAPACITY的高3位来表示运行状态,分别是: RUNNING:接收新任务

线程池 无限制的创建线程 若采用"为每个任务分配一个线程"的方式会存在一些缺陷,尤其是当需要创建大量线程时: 线程生命周期的开销非常高 资源消耗 稳定性 引入线程池 任务是一组逻辑工作单元,线程则是使任务异步执行的机制.当存在大量并发任务时,创建.销毁线程需要很大的开销,运用线程池可以大大减小开销. Executor框架 说明: Executor 执行器接口,该接口定义执行Runnable任务的方式. ExecutorService 该接口定义提供对Executor的服务. Sched