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，本次分享到此结束，请一键三连，么么么哒!

ITPub博客

disruptor-spring-boot-start生产实践导致pod节点CPU爆表100%的问题解决说明

1.前言

2.升级内容

3.依赖

4.总结

最新文章