由dubbo引起的 java OutOfMemoryError unable to create new native thread
先说明结果:
由于linux默认限制1024个线程,运行7个tomcat,一个大概150个线程左右,外加其中有两个dubbo占用了200*2个线程,超过1024限制时会出此错。
解决方法:
1. 修改dubbo配置,降低线程数,50-100个足够。
2. 修改linux配置 /etc/security/limits.conf 把 soft nproc 1024 的1024修改大。
分析工具:jstack,dubbo源码
分析,dubbo为什么要占用这么多线程:
1. dubbo官方文档标称,默认使用fixedThreadPool 并且是 100 个。然而我却发现它的代码里面写死的是 200 。
2. 其次dubbo使用的是 netty,nio啊,为什么要用这么多线程。其实netty 只是用来通信的,nio 工作线程数是cpu线程数+1个,而上面的 200 是属于业务线程。
3. 下面我会用一段不明朗的语言描述这个过程,之后会有一个简单的处理过程图来描述。
语言:
原理是,NettyServer 类创建,创建了cpu线程数+1个工作线程,即new NioServerSocketChannelFactory()的参数workerCount。这是属于 netty 的 nio 处理范围。netty获取到请求之后,需要处理请求。dubbo 默认情况下使用 dubbo 协议,使用 AllChannelHandler 来处理所有请求,而个类的处理 ChannelEventRunnable extend Runnable 处理,且有域 executor,即通过线程池处理,而此线程池是使用的 ThreadPool 类扩展点,它的注解 @SPI(“fixed”) 决定了它是使用的 FixedThreadPool 类型的线程池,这个类里面的实现是直接使用的 Executors.newFixedThreadPool() 的实现。所以会有200个线程。
图:
综上所述,dubbo 会占用较多的线程,原因是什么呢?
netty只用来接收请求,处理很快。后方需要处理业务,可能业务处理会比较慢,所以需要更多的线程来完成业务处理。
所以,根据自己的业务量来调整 dubbo 线程数量,或者修改linux配置,增加线程数。
更多推荐
所有评论(0)