disruptor-spring-boot-start版本优化升级
文章目录
- 1.前言
- 2.升级内容
- 3.依赖
- 4.总结
1.前言
由于之前写了一篇《disruptor-spring-boot-start生产实践导致pod节点CPU爆表100%的问题解决说明》的文章,里面说本地启动没有啥问题,后面我启动之前写的那个测试的controller发现,本地电脑的CPU直接干100%了,于是乎我就有点纳闷了,这个也太奇葩了,然后我思考了下,知道是啥原因了,原因是:之前那个版本里的初始化的实力有7个disruptor实例,注释了只剩第一之后启动本地电脑CPU占用在50%左右(等待策略是YieldingWaitStrategy的版本),紧接着优化了之后,测试只有一个disruptor实例,在来看本地CPU使用已经正常了。
2.升级内容
更改默认匹配等待策略改为:BlockingWaitStrategy(这个也是disruptor的默认策略,只不过之前这个启动的的版本里的匹配等待策略默认写成了:YieldingWaitStrategy,从而导致CPU100%)。
3.依赖
<dependency><groupId>io.gitee.bigbigfeifei</groupId><artifactId>disruptor-spring-boot-start</artifactId><version>1.1</version>
</dependency>
或者
<dependency><groupId>io.github.bigbigfeifei</groupId><artifactId>disruptor-spring-boot-start</artifactId><version>1.1</version>
</dependency>
4.总结
在使用disruptor-spring-boot-start启动器的时候需要谨慎的选择其等待策略,否则如果等待策略选择的不对就非常有可能出现服务启动之后CPU100%爆表的问题,对于CPU100%的问题最常见的就是代码中写了死循环导致,在一些中间件中会使用死循环来轮训所以这种操作就非常的消耗CPU,本次分享到此结束,请一键三连,么么么哒!