作者回复: 因为组合的方式没有经过充分的证明：证明在所有场景下肯定比内存复制的性能要好（毕竟组合方式的指针维护复杂些，如果解码是把组合的直接能拆出来就可以用，那明显会好，例如ssl hanlder里面就有显示设置为组合方式的例子，但是大多不是如此用，仅有的测试也只是表明好一点而已)，所以自然默认就用原始的那种方式（也就是所有人一上来就会想到的通用的内存复制的方式），而不是直接切换到后来加的组合方式，只是提供了setCumulator方法让我们有切换的选择。 总结下：不是说1+1不等于2，而是说大家都这么觉得，但是没有人去有力的证明，所以保持怀疑的态度，就保守起见了，没有改默认的。

作者回复: 不知道您这里说的上层是指什么？如果是业务层，确实是的，它先把不够数据屯起来，所以不会往外传，传也没用，因为不完整

作者回复: 这是个好问题，正好前面（或许是后面）也有一个人问这个问题，我直接复制下给他的回复吧： 因为组合的方式没有经过充分的证明：证明在所有场景下肯定比内存复制的性能要好（毕竟组合方式的指针维护复杂些，如果解码是把组合的直接能拆出来就可以用，那明显会好，例如ssl hanlder里面就有显示设置为组合方式的例子，但是大多不是如此用，仅有的测试也只是表明好一点点而已)，所以自然默认就还是用原始的那种方式（也就是所有人一上来就会想到的通用的内存复制的方式），而不是直接切换到后来加的组合方式，另外提供了setCumulator方法让我们有切换的选择。 总结下：不是说1+1不等于2，而是说大家都这么觉得，但是没有人去有力的证明，所以保持怀疑的态度，就保守起见了，没有改默认的。

作者回复: 你这个问题是你自己假想的？因为最终交给底层的（jdk的）的数据类型还是byte，所以你肯定要转的，所以你的16进制最终还是要与byte互转，所以再加一层编解码就行，或者直接在已有的编解码里面转也可以。另外，DelimiterBasedFrameDecoder说是分隔符，但是还是byte：io.netty.handler.codec.DelimiterBasedFrameDecoder#delimiters

作者回复: 可以先看第四章，但是直接看，就算是demo，缺乏很多背景知识也难懂，所以才把相关知识放前面了，你可以结合着看看，现在都更新完了。谢谢

作者回复: 因为他的源码那个注释很详细，里面也有图(虽然不太好看)，所以对着源码说了，哈

作者回复: 推荐一本 java tcp ip socket网络编程，默认很多没有讲的前提性的基础知识可以看看这本。

作者回复: 自己代码指定的，也就是你定义了你的传输信息结构，或者说叫pdu后，你就确定了你用那种解码了，然后你就找哪些支持了，显示设置下，找不到就只能自己写了。就是你告诉他怎么解他才知道，它自己不自动判断

作者回复: 这是两种学习方法，但是netty的使用真的很简单，所以才把这个顺序掉过来了😂，你可以尝试换个方法看，从后往前看，然后再反过来看下。

作者回复: 后面确实有一节提及内存相关了，主要说的是堆外内存、内存池等相关的。