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

文章首发在公众号(龙台的技术笔记),之后同步到博客园和个人网站:xiaomage.info Hippo4J v1.3.1 正式发布,本次发布增加了 Netty 上传动态线程池监控数据.适配 Hystrix 线程池监控及动态变更等诸多特性,完全兼容历史版本,使用者可安心升级. 什么是 Hippo4J Hippo4J 通过对 JDK 线程池增强,以及扩展三方框架底层线程池等功能,为业务系统提高线上运行保障能力. 全局管控 - 管理应用线程池实例: ️ 动态变更 - 应用运行时动态变更线程池参数,包括…

原因 最近在完善公司的基础发布平台的时候,使用到了一线程去做一些异步的事情,在开发环境和测试环境验证没有任何问题,但是在程序在生产运行一段时间后,发现没有得到自己想要的结果,为此开始了漫长的排查bug的之路,因为用到了一些线程,但是实际又没有对这些线程足够的监控,所以在排查问题的时候也是历经艰难险阻: 原始代码 protected ScheduledExecutorService executorService = Executors.newScheduledThreadPool(2); /**…

目录 一.线程池监控参数 二.线程池监控类 三.注意事项 在上一篇博文中,我们介绍了线程池的基本原理和使用方法.了解了基本概念之后,我们可以使用 Executors 类创建线程池来执行大量的任务,使用线程池的并发特性提高系统的吞吐量.但是,线程池使用不当也会使服务器资源枯竭,导致异常情况的发生,比如固定线程池的阻塞队列任务数量过多.缓存线程池创建的线程过多导致内存溢出.系统假死等问题.因此,我们需要一种简单的监控方案来监控线程池的使用情况,比如完成任务数量.未完成任务数量.线程大小等信息. 一.…

前言 这篇是推动大家异步编程的思想的线程池的准备篇,要做好监控,让大家使用无后顾之忧,敬畏生产. 为什么需要对线程池进行监控 Java线程池作为最常使用到的并发工具,相信大家都不陌生,但是你真的确定使用对了吗?大名鼎鼎的阿里Java代码规范要求我们不使用 Executors来快速创建线程池,但是抛弃Executors,使用其它方式创建线程池就一定不会出现问题吗?本质上对于我们来说线程池本身的运行过程是一个黑盒,我们没办法了解线程池中的运行状态时,出现问题没有办法及时判断和预警.面对这种黑盒操作必…

前言 什么是线程:程序中负责执行的哪个东东就叫做线程(执行路线,进程内部的执行序列),或者说是进程的子任务. Java中实现多线程有几种方法 继承Thread类: 实现Runnable接口: 实现Callable接口通过FutureTask包装器来创建Thread线程: 使用ExecutorService.Callable.Future实现有返回结果的多线程(也就是使用了ExecutorService来管理前面的三种方式). 如何停止一个正在运行的线程 使用退出标志,使线程正常退出,也就是当ru…

引言 合理利用线程池能够带来三个好处. ​ 第一:降低资源消耗.通过重复利用已创建的线程降低线程创建和销毁造成的消耗. ​ 第二:提高响应速度.当任务到达时,任务可以不需要等到线程创建就能立即执行. ​ 第三:提高线程的可管理性.线程是稀缺资源,如果无限制的创建,不仅会消耗系统资源,还会降低系统的稳定性,使用线程池可以进行统一的分配,调优和监控.但是要做到合理的利用线程池,必须对其原理了如执掌. 线程池的使用 线程池的创建 ​ 我们可以通过ThreadPoolExecutor来创建一个线程池 n…

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

转自:http://manzhizhen.iteye.com/blog/2391177 在上回<Dubbo源代码实现六>中我们已经了解到,对于Dubbo集群中的Provider角色,有IO线程池(默认无界)和业务处理线程池(默认200)两个线程池,所以当业务的并发比较高,或者某些业务处理变慢,业务线程池就很容易被“打满”,抛出“RejectedExecutionException: Thread pool is EXHAUSTED! ”异常.当然,前提是我们每给Provider的线程池配置等待…

线程池也是Dubbo自动自适应扩展点之一,也可以自定义线程池.Dubbo中已实现的线程池扩展点有: 其中框架提供的线程池都是通过创建真实的业务线程池进行操作的,目前线程池模型中有两个和Java中线程池相对应: 1)fix:表示创建固定大小的线程池.也是Dubbo默认的使用方式,默认创建的执行线程数为200,并且是没有任何等待队列的.所以在极端的情况下可能会存在问题,比如操作大量执行时,可能存在堵塞的情况. 2)cache:创建非固定大小的线程池,当线程不足时,会自动创建新的线程.但是使用的时候需…