由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配置，增加线程数。