一次生产环境OOM排查

一、背景

前几天下午飞书告警群里报起了java.lang.OutOfMemoryError: unable to create new native thread告警,看见后艾特了对应的项目负责人但是负责人说没时间,无奈自己亲自上阵。

二、事情经过

2.1 问题排查

从报错信息就可以看出是服务申请不到足够的内存去创建新的线程导致的,熟悉JVM的都知道线程用的是虚拟机栈内存,这里是虚拟机栈内存不够跟堆没有关系。

然后立马登录阿里云进入容器使用如下命令dump出线程堆栈

复制代码
jstack -l 1 > dump.log

让运维帮我把文件下载下来后,就把dump.log上传到网站https://fastthread.io/进行分析,分析结果如下:

可以看到服务的线程数竟然高达2000多个!!!而且也给出来警告这么高的线程数可能导致OOM,那么问题原因就很清楚了就是线程数过多导致的,那么是哪些线程过多呢?

第二张图显示数量做多的是名字为com.alibaba.nacos.client.Worker的线程,并且排行前三名都是nacos的线程,我一度怀疑是nacos出bug了🤣🤣🤣

再点进去看看对应的线程堆栈如下图:

可以看出线程阻塞在从队列获取任务那里,说明这些线程都是没活干,空闲挂起的,具体看不出问题原因,只能看代码了。

打开项目,使用idea全局搜索com.alibaba.nacos.client.Worker,发现是ClientWorker类在构造方法里创建了一个定时线程池,线程名称就叫com.alibaba.nacos.client.Worker,其中核心线程数是4。

继续跟踪源码,发现只有在NacosConfigService的构造方法里调用了ClientWorke的构造方法。

但是点击NacosConfigService的构造方法却发现没有调用,这是什么情况呢?

点击其父类com.alibaba.nacos.api.config.ConfigService 查找引用可以看到有个NacosFactory 的工厂类,原来ConfigService的是实例是通过工厂方法创建的,而工厂方法内部是通过反射创建的,如下图。

最终找到了业务类NacosConfigServiceImpl如下图:

java 复制代码
@Slf4j
@Component
public class NacosConfigServiceImpl implements ConfigService {

    /**
     * nacos地址key
     */
    public static final String SERVER_ADDR = "spring.cloud.nacos.config.server-addr";

    /**
     * nacos配置namespace
     */
    public static final String CONFIG_NAMESPACE = "spring.cloud.nacos.config.namespace";

    @Getter
    @Value("${spring.cloud.nacos.config.group}")
    private String groupId;

    @Value("${" + SERVER_ADDR + "}")
    private String nacosServerAddr;

    @Value("${" + CONFIG_NAMESPACE + "}")
    private String nacosConfigNamespace;

    private ConfigService configService;

    private static final long TIMEOUT_MILLIS = 3000L;

    @PostConstruct
    public void init() throws NacosException {
        this.configService = getConfigService();
    }

    @Override
    public void registerListener(String dataId, ConfigListener configListener) {
        AssertUtil.that(StringUtils.isNotBlank(dataId), BasicErrorCode.PARAM_ERROR, "dataId empty");
        AssertUtil.that(configListener != null, BasicErrorCode.PARAM_ERROR, "configListener null");

        try {
            //注册监听器
            // 第一次创建
            ConfigService configService = getConfigService();
            configService.addListener(dataId, getGroupId(), new DefaultListener(dataId, configListener));

            //首次更新配置
            // 第二次创建
            String configInfo = getConfigInfo(dataId);
            configListener.receiveConfigInfo(configInfo);

            log.info(LogUtil.message("registerListener success",
                    dataId, InvokeLineUtil.simplifiedClassName(configListener)));
        } catch (Exception e) {
            log.error(LogUtil.exceptionMessage("registerListener exception", e, dataId, configListener));
            throw new ApiException(BasicErrorCode.CONFIG_ERROR, e.getMessage());
        }
    }

    @Override
    public String getConfigInfo(String dataId) {
        try {
            ConfigService configService = getConfigService();
            return configService.getConfig(dataId, getGroupId(), TIMEOUT_MILLIS);
        } catch (Exception e) {
            log.error(LogUtil.exceptionMessage("getConfigInfo exception", e, dataId));
            throw new ApiException(BasicErrorCode.CONFIG_ERROR, e.getMessage());
        }
    }

    private ConfigService getConfigService() throws NacosException {
        Properties properties = new Properties();
        properties.put(PropertyKeyConst.SERVER_ADDR, nacosServerAddr);
        properties.put(PropertyKeyConst.NAMESPACE, nacosConfigNamespace);
        // 调用工厂方法创建configService
        ConfigService configService = NacosFactory.createConfigService(properties);
        return configService;
    }

}

当时看到上面代码我都惊呆了,既然已经在init()方法里初始化了属性configService,为什么还要在registerListener()方法里两次调用getConfigService()去创建两次configService实例呢?

然后找了下registerListener()方法的调用,发现多达50处!

问题原因大概就清楚了,nacos的configService设计上是作为单例去使用的,但是被滥用导致创建了很多线程池和线程把虚拟机栈内存耗尽,再申请创建新线程时就报了OOM

2.2 相关疑问

此时同事小A提出疑问,registerListener()方法执行完了,configService对象就会被gc回收,对应的线程池不也是被回收了吗?

这个问题看似很有道理其实不然,对象能不能回收是看这个对象到GC Root还有没有可达路径,线程池的gc root其实是线程 ,对应的gc路径是thread->workers->线程池 ,因为那些nacos线程池也没有设置属性allowCoreThreadTimeOut(true) ,所以就算线程空闲了核心线程也不会回收。

如果我们要在方法里创建并使用线程池,用完一定要记得调用shutdown方法,这样线程池才会被回收,当然更推荐线程池作为单例bean注入Spring容器使用。

爱专研的同事A又说你这线程数也对不上啊,50x4x2=400也没到500个啊。

大家有兴趣的可以去看看源码,NacosConfigService的构造方法里的ServerListManager类内部也有一个线程池,而且前面线程数量排行图中第三名的com.alibaba.nacos.client.remote.worker线程也跟这个有关。

2.3 解决方案

知道了原因解决起来就很快了,NacosConfigServiceImpl#registerListener()方法里创建configSerivce的代码改成用单例属性就行了。

三、总结

在用第三方开源组件的时候还是要多看看文档和其源码,使用正确的姿势不要一上来就撸代码,否则很容易产生生产事故。

不过在排查问题的过程中也顺便看了下nacos服务端和客户端配置同步的实现,算还有点收获吧。

相关推荐
_loehuang_10 小时前
【mole】Mole User 开源用户中心:一站式身份认证与权限管理解决方案
spring boot·nacos·开源·用户中心·mole
Roye_ack7 天前
【微服务 Day2】SpringCloud实战开发(微服务拆分步骤 + Nacos注册中心 + OpenFeign + 微服务拆分作业)
java·spring cloud·微服务·nacos·openfeign
BIBI20499 天前
Windows 上配置 Nacos Server 3.x.x 使用 MySQL 5.7
java·windows·spring boot·后端·mysql·nacos·配置
nightseventhunit10 天前
base64字符串String.getByte导致OOM Requested array size exceeds VM limit
java·oom
七夜zippoe14 天前
轻量级大模型在RAG系统中的集成方案
架构·大模型·oom·轻量·语义感
斯普信专业组16 天前
Nacos升级及数据迁移方案
nacos
沉浮yu大海19 天前
基于SpringBoot3+Java17+Nacos的配置中心和本地配置文件加解密
java·spring cloud·nacos·java17
liwenzhen200520 天前
Linux OOM 问题之 DMSERVER 受害者
linux·运维·oom
大大大大物~21 天前
JVM 之 线上诊断神器Arthas实战【内部原理?常用命令?如何使用Arthas排查cpu飙高、类加载问题、死锁、慢接口等线上问题?】
jvm·oom·arthas