继承自ByteToMessageDecoder。一种根据长度指定的解码器，它将接收到的ByteBuf动态分割为消息中长度字段指定的值。
LengthFieldBasedFrameDecoder使用长度字段的值解码可以有多种配置参数的方式，常见于私有客户端和服务器协议。根据不同协议的实现，一般协议数据包主要包括两部分内容，header和data，当然还有其他属性，但是不管怎么样在header中总会用一个字段来标识出数据包的长度，可以标识整个数据包的长度也可标识data长度，所以在创建LengthFieldBasedFrameDecoder对象时指定的参数完全根据具体协议的结构来设置。
tip：在默认情况下解码器假定长度字段标识的长度就是该字段后面的字节数。基于这个事实，为了使指定长度能够正确计算LengthFieldBasedFrameDecoder提供了几个参数用于指定各种情况下的计算方式，核心就是使length字段指定的值的长度能够读到完整数据包。
可归纳为如下两种情况：
1，length+data，数据包只有长度字段和content内容
2，header(length)+data，header和content，其中length包含在header中
根据netty.io上的doc介绍如下：
情况1，length标识content长度
长度值为12（0x0C）标识后面内容“hello,world”长度， 因此它可以用简单的参数组合解码。
情况1，length标识content长度，设置跳过字节数
使用ByteBuf.readableBytes()获取content的长度值，所以在解码可以跳过长度字段，指定initalBytesToStrip=2，跳过长度字段。
解码前和解码后：
情况1，length标识整个数据包长度
在这种情况下，如果解码器还是默认从length后面读取该字段设置的值，就会发生半包和粘包的现象，所以要调整读取数据包的长度。由于length标识14字节，而content实际上只有12个字节，所以将lengthAdjustment设置为-2，解码器就会读取后续12个字节数据解码。
解码前和解码后：
情况2，length标识content长度，不设置跳过字节数
在这种情况下，就需要把lengthAdjustment设置为0，因为解码器总是在帧长度计算期间考虑前置数据的长度。如下参数设置：
解码前和解码后：
情况2，length标识content长度，不设置跳过字节数
与上一个不同之处在于length字段的位置不同。在这种情况下，应该设置lengthAdjustment，告知解码器把额外的header长度也算进帧里。设置如下：
其中length=12标识content长度，3标识length字节数，lengthAdjustment为2，则解码器就会计算12+3+2=17长度的数据为一个帧进行解码。
解码前和解码后：
情况2，length标识content长度，设置跳过字节数
再这中情况下，header1对应的参数是lengthFieldOffset，header2对应的参数是lengthAdjustment，initialBytesToStrip 字段设置完全由编程控制，可以跳过header1和length字段，也可以不跳过。
header1为1一个字节，length为2个字节，header2为1个字节。设置的参数偏移量1，跳过3三个字节，则解码的长度为：12（length值）+2（length占的字节数2）+1（偏移量1）-3（跳过的字节数）+1（lengthAdjustment）=13。
解码前和解码后：
情况2，length标识整个数据包长度，设置跳过字节数
在这种情况下需要把header1和length的长度设置到lengthAdjustment，以供解码器在计算。参数设置如下：
解码器结算的长度：16（length值）+1（偏移量）+2（length占2位）+（-3（调整的值））-3（跳过的字节数）=13。
解码前和解码后：
