共计 9674 个字符，预计需要花费 25 分钟才能阅读完成。
[
文件](https://www.mdnice.com/#)格局性能查看主题代码主题设置帮忙
这是 why 的第 **63** 篇原创文章
这个办法从名称也晓得，是对响应数据做解码操作的。
标号为①的中央是判断以后版本是否反对上下文信息传递。
标号为②的中央是判断是否是异样返回。
标号为③的中央表明不是异样返回，则判断返回值是否为 null。
标号为④的中央表明是失常返回，依据是否反对上下文信息传递，从而判断是只返回响应后果的还是既有响应后果，也有上下文信息的返回类型。
标号为⑤的中央表明是异样返回，依据是否反对上下文信息传递，从而判断是只返回异样后果的还是既有异样后果，也有上下文信息的返回类型。
好了，写到这里，协定就差不多说完了。其实不难发现这个协定就是一个偏实践的货色，这就是一个大家的约定。
所以我记起之前在一个分享大会上，一位嘉宾说的：
跨语言个性理论是 RPC 层的反对，实质是协定层面的反对。
我当初对这句话的了解更加粗浅了。
跨语言，也就是服务异构的一种。
为什么我用 Java 发送 http 申请的时候能够不必关怀对方应用的是什么开发语言？
因为大家都恪守了 http 协定，协定是能够跨语言的。
Dubbo 这种 rpc 调用的框架也一样。我发动近程调用之后，只有你能依照咱们约定好的协定进行报文的解析，那你就能失常的解决我发过来的申请，我不论你的开发语言是什么。
反序列化操作到底在哪进行？
业务数据返回后，反序列化的操作到底是在哪个线程外面进行的？
是在 IO 线程外面间接解析，还是被派发到客户端线程池外面进行解析？
这个问题咱们先试着在官网的线程模型介绍中去寻找答案。http://dubbo.apache.org/zh-cn/docs/user/demos/thread-model.html
在线程模型的形容外面，是这样写的：
如果事件处理的逻辑能迅速实现，并且不会发动新的 IO 申请，比方只是在内存中记个标识，则间接在 IO 线程上解决更快，因为 缩小了线程池调度。
但如果事件处理逻辑较慢，或者须要发动新的 IO 申请，比方须要查询数据库，则必须派发到线程池，否则IO 线程阻塞，将导致不能接管其它申请。
如果用 IO 线程处理事件，又在事件处理过程中发动新的 IO 申请，比方在连贯事件中发动登录申请，会报“可能引发死锁”异样，但不会真死锁。
因而，须要通过不同的派发策略和不同的线程池配置的组合来应答不同的场景。
本文不关怀线程池配置，咱们只看派发策略：
默认的派发策略是 all。
一看到这几个策略，相熟 Dubbo 的敌人必定就晓得了，依照 Dubbo 的尿性，这必须得是一个 SPI 接口啊。
果不其然，源码外面就是这样的，你说巧不巧：
而后官网还给出了一张形容不太清晰的图片：
图片中的 Dispatch 就是派发策略发挥作用的中央。
所以咱们能从这部分得出一个论断：在默认的状况下，客户端接管到响应后，因为 Dubbo 应用 all 的派发策略，会把响应申请派发到客户端线程池中去。
那咱们能够推导：出响应的解析肯定是在客户端线程池外面进行的吗？
不能够，推不进去的。
只能说响应会进入客户端线程池中去，然而这个响应可能是一个通过解析后的响应，也可能是一个没有通过解析的响应。
所以，这个响应有可能在进入线程池之前就被解析过了。被谁解析？
IO 线程。
如果 IO 线程没有解析，那就在客户端线程外面去解析。
依据下面这段话。咱们能提炼出一个要害语句，或者说是需要：咱们当初要实现响应报文能够在不同的中央进行解析的性能，请问你怎么做？
你用脚指头想也晓得了。首先必定是有一个 if 判断的，判断到底在哪（IO 线程 / 客户端线程池）进行响应解析。而这个 if 判断的判断条件，依照 Dubbo 的尿性，必定是能够配置的。
所以咱们找到这个中央，问题就了然于心了。
咱们去哪里找答案呢？
这个类外面，这个类是一个申请 / 响应解码的十分外围的类：org.apache.dubbo.rpc.protocol.dubbo.DubboCodec
这个类的次要干了两件事，一个是对响应报文进行解码，一个是对申请报文进行解码。
接下来咱们怎么搞？强撸源码吗？不可能的。间接撸必定吃力。
还是要搞个 Demo 跑起来，而后 Debug。
我这里的 Demo 非常简单，服务端接口实现类如下：
消费者在测试类中进行生产：
而后 Debug 起来，留神，上面演示的代码没有特地阐明的中央，都是 2.7.5 版本。
运行起来后先不看别的，看看以后卡在这个中央，被 Debug 的线程是什么线程：
到这里你先沉着一下，你想一下这个问题：
在这个办法外面能够对响应和申请进行解析。那它怎么晓得以后到底是响应还是申请报文呢？
答案就在后面说的 Dubbo 协定外面：
响应上了没有？header 外面第 16 bit 如果是 0 代表响应，如果是 1 代表申请。
你说巧不巧，下面这个办法的入参外面就有一个 header 数组。
让咱们看看他外面装的是什么货色：
长度是 16，和 header 的长度吻合，然而外面装的玩意还是没看进去。
然而这样一看，看前两个字节，你就明确了：
嘿，你说巧了吗，这不是巧了吗，这不是。
魔数也对上了。阐明这是一个 Dubbo 的 header。
而后取出第 3 字节，进行位运算，判断这是什么报文：
后面，咱们解决了怎么晓得以后到底是响应还是申请报文这个问题。
接下来，进入分支外面就重点关注对响应报文的解析了：
首先，下面标记为①的中央是判断以后数据包是不是一个心跳包，通过 Debug 咱们能够晓得这不是一个心跳包：
而后标记为②的中央获取 header 中的第 4 个字节，第 4 个字节代表的是状态位：
从 Debug 的截图外面咱们能够看出，以后的状态为 20，示意失常返回。
标记为③的中央，是对心跳包的解析，咱们这里不关怀。
标记为④的中央，是咱们须要重点关注的中央，也是咱们始终在寻找的代码。
这个中央就很要害了，大家集中注意力了。
首先，上面代码的截图是 2.7.5 版本的：
这里的 if 分支和分支外面的判断条件，就是咱们后面说的：
你用脚指头想也晓得了。首先必定是有一个 if 判断的，判断到底在哪（IO 线程 / 客户端线程池）进行响应解析。而这个分支判断的判断条件，依照 Dubbo 的尿性，必定是能够配置的。
上面这张图片对 2.7.4.1 和 2.7.5 版本这个中央进行一个比照：
你认真看着两个版本之间的代码，发现截然不同，也没有差别啊。
这就把我干懵逼了：咋回事？说好的差别呢？
别忘了，下面的代码外面是有一个变量的：
差别就差别在这个中央。
2.7.5 版本之后，这个参数的默认值从 true 变为了 false。
换句话说就是：2.7.5 版本之前，业务数据返回后，默认在 IO 线程外面进行反序列化的操作。而 2.7.5 版本之后，默认是提早到客户端线程池外面进行反序列化的操作。
（倡议朗诵并背诵）
同时这个参数，不论在哪个版本外面，都是能够配置。尽管基本上也没有人更改过这个配置，配置办法如下：
敌人们，到这里还跟的上不？跟不上你就再捋捋？别硬看，伤身材。
解码操作源码解析
接下来咱们再看看解码操作的代码到底是怎么样的。
首先解码操作，解的什么码？
解的是响应报文的响应体，也就是咱们的返回内容：org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcResult#decode(org.apache.dubbo.remoting.Channel, java.io.InputStream)
标号为①的中央代表序列化类型是 2。
2 是什么？看表：
标号为②的中央代表本次响应类型为 4。
4 是什么？后面说了，看截图：
所以，在标号为③的中央即解决了返回值（handleValue）也解决了上下文信息（handleAttachment）。
handleValue 就不细看了，你就关注这个中央解析进去的就是咱们的响应内容：
响应内容的解码就是下面说的逻辑。
不论是在 IO 线程外面解码还是在客户端线程池外面解码，都要调用这个办法。只不过是谁先谁后的问题。
那么问题又来了，需要又发生变化了。
因为 IO 线程和客户端线程池都要调用这个办法进行解码，咱们总不能解码两次吧，那怎么保障只解码一次呢？
答案就是设置标识位。
因为咱们晓得如果是在 IO 线程外面解码，那么该操作调用解码办法后，必定是先于客户端线程池调用的。
有先后顺序就好办了。咱们就能够设置标识位：
当在 IO 线程解析后，会把标识位设置为 true。而后客户端线程池再走到这个逻辑的时候，发现标识位是 true 了，不进行再次操作，问题就这样被解决了。
接下来，我给大家比照一下 decodeBody 办法在 IO 线程外面解码和在客户端线程池外面解码时别离返回什么。也就是这行代码返回的时候：
这样一比照就很清晰了：
这样也解释了，为什么说是“提早”到客户端线程池外面解码。
好了，到这里你有没有发现一个问题。后面解析的这么多源码，而后咔一下，间接咱们就看到了最终返回的“Hello why”了。
这个是响应音讯体，是 body。
头呢？header 呢？
别急，这不是马上就给你讲一下嘛。
后面讲这个办法的时候说了：header 是作为参数传进来的嘛，那咱们还能够去找一下 header 到底是怎么传进来的：
怎么看呢？
顺着调用链往回找就行，一个调试小技巧，送给大家，不客气：
能够看到 header 是从 buffer 外面取出来的，最多读取 HEADER_LENGTH (16) 个字节。
什么？你还问我为什么最多读 16 个字节？
我狐疑后面讲协定的时候你就在走神。别问，问就是协定规定。大家恪守就好了。
再跟着调用链往前一步，你会发现这里次要是在做解码响应头的局部：
下面这个办法外面就是在搞 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 版本之前还是之后客户端的默认实现都是 cached，这个线程池并没有限度线程数量：
所以会呈现生产端线程数调配多的问题。
但官网的形容是：调配过多。多和过多还不一样。
为什么会过多呢？
因为在 2.7.5 版本之前，是每一个链接都对应一个客户端线程池。相当于做了链接级别的线程隔离，然而实际上这个线程隔离是没有必要的。反而影响了性能。
而在 2.7.5 版本外面，就是不论你多少链接，大家共用一个客户端线程池，引入了 threadless executor 的概念。
简略的来说，优化后果就是从多个线程池改为了共用一个线程池。
线程池模型的变动，我在《Dubbo 2.7.5 在线程模型上的优化》外面比拟具体的聊过了，就不在反复讲了，有趣味的能够去翻一下。
感谢您的浏览，我保持原创，非常欢送并感谢您的关注。
我是 why，一个被代码耽搁的文学创作者，不是大佬，然而喜爱分享，是一个又暖又有料的四川好男人。
