上面这个方法里面就是在搞 header 的事情。

其中有一个检查报文长度的方法：checkPayLoad。

那么问题又来了：请问 Dubbo 默认的报文长度限制是多少呢？

带大家去源码里面找答案：

答案是 8M。

另外，既然是有默认值，那必须是可以配置的。所以上图标号为①的地方是从配置中获取，获取不到，就返回默认值。

稍微有点意思的是标号为②的地方，我第一次看的时候愣是看了一分钟没反应过来。主要是前面的这个 payload > 0，我想着这不是废话嘛，长度不都是大于 0 的。兴奋的我以为发现了一个无用代码呢。

后来才理解到，如果当 payload 设置为负数的时候，就代表不限制报文长度。

可以进行如下配置：

一个基本上用不到的 Dubbo 小知识点，免费赠送给大家。

好了，header 和 body 都齐活了。

到这里，再总结一下：2.7.5 版本之前，业务数据返回后，默认在 IO 线程里面进行反序列化的操作。而2.7.5 版本之后，默认是延迟到客户端线程池里面进行反序列化的操作。

所以，对于官网中，红框框起来这个地方的描述是有问题的：

http://dubbo.apache.org/zh-cn/docs/user/demos/consumer-threadpool.html

正确的说法应该是：在老的（2.7.5 版本之前）线程池模型中，当业务数据返回后，默认在 IO 线程上进行反序列化操作，如果配置了 decode.in.io 参数为 false，则延迟到独立的客户端线程池进行反序列化操作。

聊聊线程池模型的变化

接下来再聊聊线程池模型的变化。这里的线程池指的都是客户端线程池。

先抛两个知识点：

• 不论是新老线程池模型，默认的 Dispatch 策略都是 all。所有响应还是会转发到客户端线程池里面，在这个里面进行解码操作（如果 IO 线程没有解码的话）把结果返回到用户线程中去。

• 对于线程池客户端的默认实现是 cached，服务端的默认实现是 fixed。

官网这里的 fixed 缺省，特指服务端：

所以会出现消费端线程数分配多的问题。

但官网的描述是：分配过多。多和过多还不一样。

为什么会过多呢？

因为在 2.7.5 版本之前，是每一个链接都对应一个客户端线程池。相当于做了链接级别的线程隔离，但是实际上这个线程隔离是没有必要的。反而影响了性能。

而在 2.7.5 版本里面，就是不管你多少链接，大家共用一个客户端线程池，引入了 threadless executor 的概念。

简单的来说，优化结果就是从多个线程池改为了共用一个线程池。

线程池模型的变化，我在《Dubbo 2.7.5在线程模型上的优化》里面比较详细的聊过了，就不在重复讲了，有兴趣的可以去翻一下。

感谢您的阅读，我坚持原创，十分欢迎并感谢您的关注。

我是 why，一个被代码耽误的文学创作者，不是大佬，但是喜欢分享，是一个又暖又有料的四川好男人。