从提交记录可以看出主要有两处改动，且两处改动的代码是一模一样的，都位于 decodeBody 这个方法，只是一个在 if 分支，一个在 else 分支：
这个代码是干啥的？
你想一个 RPC 调用，肯定是涉及到报文的 encode(编码) 和 decode(解码) 的，所以这里主要就是对请求和响应报文进行 decode 。
一个心跳，一来一回，一个请求，一个响应，所以有两处改动。
所以我带着大家看请求包这一处的处理就行了：
可以看到代码改造之后，对心跳包进行了一个特殊的判断。
在心跳事件特殊处理里面涉及到两个方法，都是本次提交新增的方法。
第一个方法是这样的：
org.apache.dubbo.remoting.transport.CodecSupport#getPayload
就是把 InputStream 流转换成字节数组，然后把这个字节数组作为入参传递到第二个方法中。
第二个方法是这样的：
org.apache.dubbo.remoting.transport.CodecSupport#isHeartBeat
从方法名称也知道这是判断请求是不是心跳包。
怎么去判断它是心跳包呢？
首先得看一下发起心跳的地方：
org.apache.dubbo.remoting.exchange.support.header.HeartbeatTimerTask#doTask
从发起心跳的地方我们可以知道，它发出去的东西就是 null。
所以在接受包的地方，判断其内容是不是 null，如果是，就说明是心跳包。
通过这简单的两个方法，就完成了心跳跳过序列化这个操作，提升了性能。
而上面两个方法都是在这个类中，所以核心的改动还是在这个类，但是改动点其实也不算多：
org.apache.dubbo.remoting.transport.CodecSupport
在这个类里面有两个小细节，可以带大家再看看。
首先是这里：
这个 map 里面缓存的就是不同的序列化的方式对应的 null，代码干的也就是作者这里说的这件事儿：
还有一次优化性的提交，而这一次提交的内容是这样的。
首先定义了一个 ThreadLocal，并使其初始化的时候是 1024 字节：
那么这个 ThreadLocal 是用在哪儿的呢？
在读取 InputStream 的时候，需要开辟一个字节数组，为了避免频繁的创建和销毁这个字节数据，所以搞了一个 ThreadLocal：
有的同学看到这里就要问了：为什么这个 ThreadLocal 没有调用 remove 方法呢，不会内存泄漏嘛？
不会的，朋友们，在 Dubbo 里面执行这个玩意的是 NIO 线程，这个线程是可以复用的，且里面只是放了一个 1024 的字节数组，不会有脏数据，所以不需要移除，直接复用。
正是因为可以复用，所以才提升了性能。
这就是细节，魔鬼都在细节里面。
这一处细节，就是前面提到的另外一个 pr:
看到这里，我们也就知道了宇宙行到底是怎么让心跳跳过序列化操作了，其实也没啥复杂的代码，几十行代码就搞定了。
但是，朋友们，又要但是了。
写到这里的时候，我突然感觉到不太对劲。
因为我之前写过这篇文章，Dubbo 协议那点破事。
在这篇文章里面有这样的一个图：
这是当时在官网上截下来的。
在协议里面，事件标识字段之前只有 0 和 1。
但是现在不一样了，从代码看，是把 1 的范围给扩大了，它不一定代表的是心跳，因为这里面有个 if-else
所以，我就去看了一下现在官网上关于协议的描述。
https://dubbo.apache.org/zh/docs/v3.0/concepts/rpc-protocol/#dubbo2
果然，发生了变化：
并不是说 1 就是心跳包，而是改口为：1 可能是心跳包。
严谨，这就是严谨。
所以开源项目并不是代码改完就改完了，还要考虑到一些周边信息的维护。
心跳的多种设计方案
在研究 Dubbo 心跳的时候，我还找到了这样一个 pr。
标题是这样的：
翻译过来就是使用 IdleStateHandler 代替使用 Timer 发送心跳的建议。
我定睛一看，好机会，这不是 95 后老徐嘛，老熟人了。
看一下老徐是怎么说的，他建议具体是这样的：
几位 Dubbo 大佬，在这个 pr 里面交换了很多想法，我仔细的阅读之后都受益匪浅。
大家也可以点进去看看，我这里给大家汇报一下自己的收获。
首先是几位老哥在心跳实时性上的一顿 battle。
总之，大家知道 Dubbo 的心跳检测是有一定延时的，因为是基于时间轮做的，相当于是定时任务，触发的时效性是不能保证实时触发的。
这玩意就类似于你有一个 60 秒执行一次的定时任务，在第 0 秒的时候任务启动了，在第 1 秒的时候有一个数据准备好了，但是需要等待下一次任务触发的时候才会被处理。因此，你处理数据的最大延迟就应该是 60 秒。
这个大家应该能明白过来。
额外说一句，上面讨论的结果是“目前是 1/4 的 heartbeat 延时”，但是我去看了一下最新的 master 分支的源码，怎么感觉是 1/3 的延时呢：
从源码里可以看到，计算时间的时候 HEARTBEAT_CHECK_TICK 参数是 3。所以我理解是 1/3 的延时。
但是不重要，这不重要，反正你知道是有延时的就行了。
而 kexianjun 老哥认为如果基于 netty 的 IdleStateHandler 去做，每次检测超时都重新计算下一次检测的时间，因此相对来说就能比较及时的检查到超时了。
这是在实时性上的一个优化。
而老徐觉得，除了实时性这个考虑外，其实 IdleStateHandler 更是一个针对心跳的优雅的设计。但是呢，由于是基于 Netty 的，所以当通讯框架使用的不是 Netty 的时候，就回天无力了，所以可以保留 Timer 的设计来应对这种情况。
很快，carryxyh 老哥就给出了很有建设性的意见：
