1、使用spirng容器，最好是要控制每个容器要注入的范围（避免不需要的注入）

（1）可以使用以下方式进行配置

@ContextHierarchy({@ContextConfiguration(locations = "classpath:spring-bean-test.xml")})

（2）使用单独的@Configuration进行隔离

各种测试方式

1、外部依赖全mock;

场景：单元测试，主要测试内部的代码；

主要使用injectMocks 和 Mock注解

对于没有返回的情况，直接不需要使用when

2、使用spring容器，部分依赖mock;

场景：spring相关代码的测试

eg: 对mq的启动封装（作为spring组件注入），增加了参数之后，需要进行测试，但是本身有n层的spring组件，这个时候，就把不需要测试的组件直接mock掉；

@Configuration
public class TestConfig {


@Bean
public MqConsumeService mqConsumeService(){
return Mockito.mock(MqConsumeService.class);
}

@Bean
public SpringContextHolderConfig springContextHolderConfig(){
return new SpringContextHolderConfig();
}

@Bean
public MqSubscriber mqSubscriber() {
return new MqSubscriber();
}
}

3、使用spring容器，全部不mock

场景：集成测试；

dubbo的启动流程

1、dubbo provider的启动

Main-》 ServerConfig -》 DubboProtocol#openServer ：然后开始组装handler，最后调用NettyServer的doOpen()

dubbo的执行流程

1、dubbo的执行和netty的执行是怎么关联上的？

关联点在NettyServer, 里面的handler是netty的handler，但是同时传入了dubbo的ChannlHandler。 netty的各种事件处理操作，都会转发给dubbo的ChannlHandler进行处理；（dubbo 的组件和Netty的关系 的图也说明了这种关系）

dubbo的一些设计参考

1、装饰器模式

dubbo handler的组装

灵活组合各种handler ，相比netty的handler而言，dubbo的handler是必须要执行的，netty的handler是可选的，执行顺序 是不固定的；

2、扩展点设计

依赖倒转的原则，保证了各个节点的灵活性；

其实扩展点，就是策略模式的使用，只不过这里的策略的实现可能是业务定制化的，所以做成了配置化 + 反射的方式去加载各种类；（定好接口标准，业务实现）

3、url的统一设计

统一语言

4、适配器模式

（1）对于netty的适配，把dubbo和netty进行了解耦；

在dubbo的netty包，使用了dubbo的ChannelHandler进行适配；（找到适配点，定义映射关系，定义映射接口，适配）

大纲

• 是什么
• 工具定位是啥
• 核心命令以及应对的场景
• 实战场景

注意事项

• 避免一次性trace/watch大量的类
• trace/watch/tt等指令 增加 -n 参数，控制输出的范围

实战场景

1、logger命令

现象：预发布环境某个框架层的日志没有输出, 这个不就是logger的使用场景么

原因: 预发布环境logback里面的应用名配错了

2、thread

（1）对dubbo线程池进行分组进行线程隔离，分组之后，验证是否按照对应的比例进行分配.(也可以使用jstack)

thread -all | grep 'DubboServerHandler'

（2）cpu负载较高的情况下，查看最忙的几个线程

thread -n 3

结合dashboard查看cpu占用

(3) 查看阻塞的线程

thread -b

3、dashboard

从全局查看整体的cpu还有内存情况

4、ognl

（1）使用dubbo框架情况下，查看spring管理的变量值

sc -d com.alibaba.dubbo.config.spring.extension.SpringExtensionFactory

ognl -c ${sc命令得出的值} '#context=@com.alibaba.dubbo.config.spring.extension.SpringExtensionFactory@contexts.iterator.next, #context.getBean("bean名称")'

5、watch命令

使用场景：除了日常的debug查看参数之外，还可以用来验证，某个方法是否有调用到。eg： 查看线程jstack的堆栈，线程的状态一直是blocked，可以用命令看下是否真的一点调用都没有.

watch com.xxx.StrategyExecutor solve '{params[0]}' "params[0].level>1" -n 5 -x 3

6、monitor

使用场景： 在一定周期内统计接口耗时。eg： 在没有线上日志的情况下，排查某个接口为啥会出现周期性波动

monitor com.fxxx.StrategyExecutor solve "params[0].level==1"

7、docker里面使用arthas

如何在Docker中使用Arthas - 技术人的一亩田

这是一个技术人分享和吐槽的一亩地~

一个技术人天马行空的一亩田

OGNL表达式

在watch, trace, monitor, stack等等支持条件表达式的命令都可以用，可以用来进行内容输出的控制（watch）以及 筛选（命中条件的请求，才输出）

1、支持的变量

Arthas

Alibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas - alibaba/arthas: Alibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas

arthas

2、一些语法： https://www.rongcloud.cn/blog/?p=5884

3、例子

（1）查看方法第一个参数的变量level的值大于1的调用

watch com.xxx.StrategyExecutor solve '{params[0]}' "params[0].level>1" -n 5 -x 3

（2）查看第一个参数的变量level的值大于1 并且 变量id的值为 xyz 的调用

watch c com.xxx.StrategyExecutor solve '{params[0]}' "params[0].level>1 and params[0].id!='xyz'" -n 15 -x 3

​参考

Arthas

Alibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas - alibaba/arthas: Alibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas

arthas

arthas idea plugin 配置 · 语雀

配置为什么有配置项？第一个原因是spring stat…

Arthas | 定位线上 Dubbo 线程池满异常

前言本文是 Arthas 系列文章的第二篇。 Dubbo 线程池满异常应该是大多数 Dubbo 用户都遇到过的一个问题，本文以 Arthas 3.1.7 版本为例，介绍如何针对该异常进行诊断，主要使用到 dashboard/thread 两个指令。

徐靖峰|个人博客徐靖峰

问题

1、部署失败了

也没有执行日志，最开始不知道怎么排查

后来看了下部署日志，大概知道了部署的机制，把部署命令到机器上一个个执行

发现是Tomcat启动的时候有问题，报错如下：

 Cannot find /usr/local/tomcat/bin/setclasspath.sh

解决： docker在启动的时候增加：--privileged

后续

1、docker的常用语法；

2、线上编码的使用；

3、持续集成的各个环节；

4、自己的应用怎么改造成docker的呢；

5、docker里面安装athras

如何在Docker中使用Arthas - 技术人的一亩田

这是一个技术人分享和吐槽的一亩地~

一个技术人天马行空的一亩田

已完成

1、开放8080端口；

2、持续集成 + 持续部署

3、更改jdk版本 + json的输出；

4、docker最常见的用法；

5、docker里面执行arthas : 修改了tomcat的docker镜像，同时增加arthas的镜像, 镜像仓库

https://hub.docker.com/

总体流程

背景

最近遇到了一些问题了netty相关，又重新看了下netty相关的知识

之前疑问

1、NiO, IO多路复用, Netty, Epoll, Selector, Reactor模型等的关系是什么?

Netty （主从 Reactors 多线程模型的落地）

netty的核心实现：NIO（Non-block I/O） + IO多路复用

操作系统底层提供对IO多路复用提供的支持：Epoll Selector Poll

可看

08 网络通信优化之IO模型：如何解决高并发下IO瓶颈？

08 网络通信优化之IO模型：如何解决高并发下IO瓶颈？

技术文章摘抄

11 答疑课堂：深入了解NIO的优化实现原理

11 答疑课堂：深入了解NIO的优化实现原理

技术文章摘抄

2、IO多路复用和非阻塞的关系，IO多路复用复用的是啥？

复用：线程；

多路：多个IO事件；

IO多路复用：一个线程去处理多个IO事件（尽可能去压榨了CPU，同时又没有线程切换的开销，所以性能好）；解决的是IO事件处理的瓶颈问题

IO多路复用，既可以是非阻塞的，也可以是阻塞的，阻塞是指，在某个IO没有数据达到的时候，是阻塞的，还是非阻塞的；（阻塞的以为着只能阻塞在某个IO上，非阻塞意味着可以进行多个IO的轮询或者监听）

2、netty的主要解决什么问题？什么场景下需要考虑使用netty?

网络连接的问题。需要自建服务器的时候可以使用netty， eg: dubbo, rocketmq等等；

3、netty的核心概念以及核心工作流程是怎样的？

见下面的概念以及执行架构；

Netty的概念

• Channel
• EventLoop
• EventLoopGroup
• Selector
• ChannelHandler

Netty执行架构

摘自：http://www.52im.net/thread-2043-1-1.html

当前疑问

1、Netty的Reactor多线程模型，落地是怎么落地的，是怎么设计的，有啥可以借鉴的；

eventLoop 就是Reactor，BossEventLoop就是主reactor，NioEventLoop就是从reactor;

EventLoop就是IO多路复用，进行多路复用的那个线程；

2、dubbo又是怎么使用Netty的；

一问彻底理解dubbo主流程_dubbo 不能内部类-CSDN博客

文章浏览阅读215次。由于我觉得服务端相对简单一点，所以先分析服务端接受请求流程的代码，再分析客户端调用的代码。本文重点解析的是调用以及调用需要初始化的处理器handler等，对于与注册中心的交互解析相对比较少。一.服务端初始化handler这里主要介绍主要的流程，并且默认dubbo协议1.handler整理流程要理清楚服务端调用流程最重要的就是要理清楚服务端的所有处理请求的handler，我们先来看看它的handler是如何初始化，并且逐级传递的我先上一个handler的初始化的流程，然后再上一个handler调用的_dubbo 不能内部类

成就一亿技术人!

从包可以看到，dubbo集成netty基本上就很少代码，就是server,然后一个编码解码，然后是一个handler进行适配，将netty的事件为dubbo的事件，然后交给dubbo的handler进行处理

上层集成的时候，也使用了扩展点Transporter，然后指定了Transporter的具体实现为netty,才会触发nettyServer的流程。

一些扩展

1、CPU密集型 和 IO密集型的线程设置；

以前一直不知道怎样的才是cpu密集型，现在知道了，netty， redis等都是，看netty的现场，直接是绑定cpu核心数 + 1；redis也是类似。

2、netty的模式真的相比阻塞的模式能提高性能么？（在IO密集型应用上）因为IO密集型应用最终还是会把工作交给工作线程，工作线程最终还是会阻塞的？

ThreadPoolExecutor提供了以下拒绝策略（也可以自己实现RejectExecutionHandler接口，进行定制）：

• CallerRunsPolicy: 由调用线程直接进行调用，看上面源码是直接调用了run方法；（相当于没开异步）
• AbortPolicy：抛出异常；
• DiscardPolicy：直接丢弃，然后继续执行后面的操作；（如果后面用了CompletableFuture.join还有Future.get等等待操作，有坑）
• DiscardOldestPolicy：丢弃掉最早的线程，然后执行刚申请的这一个；

执行流程

以下是执行 ThreadExecutor.execute 的流程（执行ExecutorService的submit接口和CompletableFuture.supplyAsync都会执行这个接口）

1、在队列数，线程数都不够之后，就会执行reject；

2、也就是在ExecutorService.submit和调用点CompletableFuture.supplyAsync就会去执行这个操作，然后根据拒绝策略直接忽略或者抛出异常等等；

案例

拒绝策略配置为忽略，仅仅做了上报，导致了申请不到线程的情况下，上游线程将会一直处于阻塞的状态，设置了超时情况，也要等到到超时时间才能抛出异常，无法快速失败，在大流量情况下，会严重降低系统的性能；

行睿的博客 - Private Site Access

Private Site Access

现象与应急

下午6点，突然发现监控大盘，核心服务耗时上涨了（400ms -> 800ms）， 群里通知小伙伴看日志，发现有 "xx 数据查询线程池拒绝,激活线程数:50,最大线程数:50,排队数:200" 的日志，怀疑下游耗时上涨把线程池打满了，看下游耗时，在17:00 - 17：30 确实有明显的耗时上涨，部分最大耗时到了3s, 但是下游恢复了，我们却还没有恢复。

因为耗时上涨，同时如果机器一直拒绝的话，会影响首页运营位相关的功能，所以先考虑进行了重启操作，结果，重启之后，耗时居然直接飙到了3s以上，系统功能几乎不可用了，之后，进行扩容，不分限流，也不管用。

后来进行怀疑是有循环依赖问题，导致重启加剧了系统阻塞，所以，先紧急对系统进行了限流，同时进行了动态线程池的调整（线程池大小从50 -> 120，这里之前做了动态配置，直接修改就生效了），才终于恢复了。

疑问点

1、为什么17点30 - 18点00下游耗时恢复了，线程池打满却没有恢复；

2、为什么重启之后，马上又被打满了，而且重启之后，效果还更差，直接导致系统block住了；

原因排查

1、jstack 导出了堆栈，统计对应的线程池，发现该线程池所有线程都执行到169行就wating了，同时看代码里面有join(jdk 8里面是没办法)

2、arthas trace和watch看对应堆栈的执行，没有输出（证明线程是彻底卡死了）– 这里可以解答疑问 1

3、期间因为还有应用overload的告警（dubbo线程池打满了）

从以上两点基本上可以断定是跟这里的join代码有关了

4、join卡死的原因：

• 流量变大 + 下游耗时增加，导致线程池被打满了
• 没有超时时间 ， 拒绝策略问题，导致线程卡死

行睿的博客 - Private Site Access

Private Site Access

只有以上两个问题，下游恢复，重启是能恢复的

5、重启不恢复，反而导致故障加剧的原因，因为有循环依赖，所以出现了以下场景：

• 其他机器的流量上升；
• dubbo线程池被打满；（部分机器）
• 字段线程池被打满；（部分机器）

故障时序

1、发生的时候已经有部分机器字段线程池打满了；（监控可以大概证明，之前耗时已经翻倍了）
2、下游耗时增加，导致更多机器字段线程池打满；（监控可以说明）
3、重启，增加了流量，导致部分机器的dubbo线程池打满（超过50qps）；开始死循环；（监控可以看出来） – 这个可以解答上面的疑问 2
4、dubbo被打满，导致更多的字段线程池被打满，从而性能更差；

启思

1、类似的问题，怎么应急, 以及快速排查

• 流量变大 + 下游耗时增加，导致线程池被打满了 （扩容，主动熔断降级，流量不大的情况下，还是要先考虑重启（先扩容，再重启））；
• jstack dump出线程堆栈，看是否有异常；

2、系统建设上有哪些注意点，避免出现类似的问题

• 超时时间 & 熔断机制（可以降低影响，最少不会卡主）
• 线程池尽量不共用（特别是有依赖的）
• 线程池的拒绝策略（可以降低影响，最少不会卡主）
• 避免循环依赖
• 限流措施

3、更近一步的思考

本质上是资源不足

已完成优化

1、线程池的拒绝策略修改为抛出异常；

2、打破资源的循环依赖；（dubbo线程池隔离）

3、线程池隔离；

4、future获取设置超时时间；