前言
 
习惯用 Json、XML 数据存储格式的你们，相信大多都没听过Protocol Buffer
Protocol Buffer 其实 是 Google出品的一种轻量 & 高效的结构化数据存储格式，性能比 Json、XML 真的强！太！多！
 
 
 
由于 Google出品，我相信Protocol Buffer已经具备足够的吸引力
 
 
今天，我将讲解为什么Protocol Buffer的性能如此的好：
 a. 序列化速度 & 反序列化速度快
 b. 数据压缩效果好，即序列化后的数据量体积小
 
 
 
Carson带你学序列化Protocol Buffer系列文章
 快来看看Google出品的Protocol Buffer，别只会用Json和XML了
 Carson带你学序列化：手把手教你如何安装Protocol Buffer
 Carson带你学序列化：全面详解ProtocolBuffer语法
 Carson带你学序列化：Google出品的序列化神器Protocol Buffer使用指南
 Carson带你学序列化：Protocol Buffer序列化原理大揭秘-为什么性能这么好？
 Carson带你学序列化：深入源码分析Protocol Buffer
 Carson带你学序列化：深入分析JSON多种解析方式(Gson、AS自带org.json、Jackson)
 Carson带你学序列化：深入分析XML多种解析方式(DOM、SAX、PULL)
 
 
 
目录
 
 
 
1. 定义
 
一种 结构化数据 的数据存储格式（类似于 XML、Json ）
 
 
 
Google 出品 （开源）
Protocol Buffer 目前有两个版本：proto2 和 proto3
因为proto3 还是beta 版，所以本次讲解是 proto2
 
 
 
2. 作用
 
通过将 结构化的数据 进行 串行化（序列化），从而实现 数据存储 / RPC 数据交换的功能
 
 
 
序列化： 将 数据结构或对象 转换成 二进制串 的过程
反序列化：将在序列化过程中所生成的二进制串 转换成 数据结构或者对象 的过程
 
 
 
3. 特点
 
对比于 常见的 XML、Json 数据存储格式，Protocol Buffer有如下特点：
 
 
 
4. 应用场景
 
传输数据量大 & 网络环境不稳定 的数据存储、RPC 数据交换 的需求场景
 
 
 
如 即时IM （QQ、微信）的需求场景
 
 
 
总结
 
在 传输数据量较大的需求场景下，Protocol Buffer比XML、Json 更小、更快、使用 & 维护更简单！
 
 
5. 使用流程
 
关于 Protocol Buffer 的使用流程，具体请看我写的文章：快来看看Google出品的Protocol Buffer，别只会用Json和XML了
 
 
6. 知识基础
 
6.1 网络通信协议
 
序列化 & 反序列化 属于通讯协议的一部分
通讯协议采用分层模型：TCP/IP模型（四层） & OSI 模型 （七层）
 
 
 
序列化 / 反序列化 属于 TCP/IP模型 应用层 和 OSI`模型 展示层的主要功能：
 
  
（序列化）把 应用层的对象 转换成 二进制串
（反序列化）把 二进制串 转换成 应用层的对象
 
 
所以， Protocol Buffer属于 TCP/IP模型的应用层 & OSI模型的展示层
 
 
6.2 数据结构、对象与二进制串
 
不同的计算机语言中，数据结构，对象以及二进制串的表示方式并不相同。
 
a. 对于数据结构和对象
 
 
对于面向对象的语言（如Java）：对象 = Object = 类的实例化；在Java中最接近数据结构 即 POJO（Plain Old Java Object），或Javabean（只有 setter/getter 方法的类）
 
 
对于半面向对象的语言（如C++），对象 = class，数据结构 = struct
 
 
b. 二进制串
 
对于C++，因为具有内存操作符，所以 二进制串 容易理解：C++的字符串可以直接被传输层使用，因为其本质上就是以 '\0' 结尾的存储在内存中的二进制串
对于 Java，二进制串 = 字节数组 =byte[]
 
 
 
byte 属于 Java 的八种基本数据类型
二进制串 容易和 String混淆：String 一种特殊对象（Object）。对于跨语言间的通讯，序列化后的数据当然不能是某种语言的特殊数据类型。
 
 
6.3 T - L - V 的数据存储方式
 
 
定义
 即 Tag - Length - Value，标识 - 长度 - 字段值 存储方式
 
 
作用
 以 标识 - 长度 - 字段值 表示单个数据，最终将所有数据拼接成一个 字节流，从而 实现 数据存储 的功能
 
 
 
 
其中 Length可选存储，如 储存Varint编码数据就不需要存储Length
 
 
示意图
 
 
优点
 从上图可知，T - L - V 存储方式的优点是 
  
不需要分隔符 就能 分隔开字段，减少了 分隔符 的使用
各字段 存储得非常紧凑，存储空间利用率非常高
若 字段没有被设置字段值，那么该字段在序列化时的数据中是完全不存在的，即不需要编码
 
 
 
 
相应字段在解码时才会被设置为默认值
 
 
 
7. 序列化原理解析
 
请记住Protocol Buffer的 三个关于数据存储 的重要结论：
 
结论1： Protocol Buffer将 消息里的每个字段 进行编码后，再利用T - L - V 存储方式 进行数据的存储，最终得到的是一个 二进制字节流
 
 
 
序列化 = 对数据进行编码 + 存储
 
 
结论2：Protocol Buffer对于不同数据类型 采用不同的 序列化方式（编码方式 & 数据存储方式），如下图：
 
 
从上表可以看出：
 
对于存储Varint编码数据，就不需要存储字节长度 Length，所以实际上Protocol Buffer的存储方式是 T - V；
若Protocol Buffer采用其他编码方式（如LENGTH_DELIMITED）则采用T - L - V
 
结论3：因为 Protocol Buffer对于数据字段值的 独特编码方式 & T - L - V数据存储方式，使得 Protocol Buffer序列化后数据量体积如此小
 
下面，我将对不同的编码方式 & 数据存储方式进行逐一讲解。
 
 
7.1 Wire Type = 0时的编码 & 数据存储方式
 
 
7.1.1 编码方式： Varint & Zigzag
 
A. Varint编码方式介绍
 
i. 简介
 
定义：一种变长的编码方式
原理：用字节 表示 数字：值越小的数字，使用越少的字节数表示
作用：通过减少 表示数字 的字节数 从而进行数据压缩
 
 
 
如：
 
 
对于 int32 类型的数字，一般需要 4个字节 表示；
 
 
若采用 Varint编码，对于很小的 int32 类型 数字，则可以用 1个字节 来表示
虽然大的数字会需要 5 个 字节 来表示，但大多数情况下，消息都不会有很大的数字，所以采用 Varint方法总是可以用更少的字节数来表示数字
 
 
ii. 原理介绍
 
源码分析
 
private void writeVarint32(int n) {                                                                                    
  int idx = 0;  
  while (true) {  
    if ((n & ~0x7F) == 0) {  
      i32buf[idx++] = (byte)n;  
      break;  
    } else {  
      i32buf[idx++] = (byte)((n & 0x7F) | 0x80);  
      // 步骤1：取出字节串末7位
      // 对于上述取出的7位：在最高位添加1构成一个字节
      // 如果是最后一次取出，则在最高位添加0构成1个字节

      n >>>= 7;  
      // 步骤2：通过将字节串整体往右移7位，继续从字节串的末尾选取7位，直到取完为止。
    }  
  }  
  trans_.write(i32buf, 0, idx); 
      // 步骤3： 将上述形成的每个字节 按序拼接 成一个字节串
      // 即该字节串就是经过Varint编码后的字节
}   

 
从上面可看出：Varint 中每个 字节 的最高位 都有特殊含义：
 
如果是 1，表示后续的 字节 也是该数字的一部分
如果是 0，表示这是最后一个字节，且剩余 7位 都用来表示数字
 
 
 
所以，当使用Varint解码时时，只要读取到最高位为0的字节时，就表示已经是Varint的最后一个字节
 
 
因此：
 
小于 128 的数字 都可以用 1个字节 表示；
大于 128 的数字，比如 300，会用两个字节来表示：10101100 00000010
 
下面，我将用两个个例子来说明Varint编码方式的使用
 
目的：对 数据类型为Int32 的 字段值为296 和字段值为104 进行Varint编码
以下是编码过程
 
 
从上面可以看出：
 
对于 int32 类型的数字，一般需要 4 个字节 来表示；
但采用 Varint 方法，对于很小的 Int32 类型 数字（小于256），则可以用 1个字节 来表示；
 
 
 
以此类推，比如300也只需要2个字节
 
 
虽然大的数字会需要 5 个字节 来表示，但大多数情况下，消息都不会有很大的数字
所以采用 Varint 方法总是可以用更少的字节数来表示数字，从而更好地实现数据压缩
 
下面继续看如何解析经过Varint 编码的字节
 
 
Varint 编码方式的不足
 
背景：在计算机内，负数一般会被表示为很大的整数
 
 
 
因为计算机定义负数的符号位为数字的最高位
 
 
问题：如果采用 Varint编码方式 表示一个负数，那么一定需要 5 个 byte（因为负数的最高位是1，会被当做很大的整数去处理）
解决方案： Protocol Buffer 定义了 sint32 / sint64 类型表示负数，通过先采用 Zigzag 编码（将 有符号数 转换成 无符号数），再采用 Varint编码，从而用于减少编码后的字节数
 
 
 
 
对于int32 / int64 类型的字段值（正数），Protocol Buffer直接采用 Varint编码
对于sint32 / sint64 类型的字段值（负数），Protocol Buffer会先采用 Zigzag 编码，再采用 Varint编码
 
 
总结：为了更好地减少 表示负数时 的字节数，Protocol Buffer在 Varint编码上又增加了Zigzag 编码方式进行编码
下面将详细介绍 Zigzag编码方式
 
B. Zigzag编码方式详解
 
i. 简介
 
定义：一种变长的编码方式
原理：使用 无符号数 来表示 有符号数字；
作用：使得绝对值小的数字都可以采用较少 字节 来表示；
 
 
 
特别是对 表示负数的数据 能更好地进行数据压缩
 
 
b. 原理
 
源码分析
 

public int int_to_zigzag(int n)
// 传入的参数n = 传入字段值的二进制表示（此处以负数为例）
// 负数的二进制 = 符号位为1，剩余的位数为 该数绝对值的原码按位取反；然后整个二进制数+1
{
        return (n <<1) ^ (n >>31);   
        // 对于sint 32 数据类型，使用Zigzag编码过程如下：
        // 1. 将二进制表示数 左移1位（左移 = 整个二进制左移，低位补0）
        // 2. 将二进制表示数 右移31位 
              // 对于右移：
              // 首位是1的二进制（有符号数），是算数右移，即右移后左边补1
              // 首位是0的二进制（无符号数），是逻辑左移，即右移后左边补0
        // 3. 将上述二者进行异或

        // 对于sint 64 数据类型 则为： return  (n << 1> ^ (n >> 63) ；
}


// 附：将Zigzag值解码为整型值
public int zigzag_to_int(int n) 
{
        return(n >>> 1) ^ -(n & 1);
// 右移时，需要用不带符号的移动，否则如果第一位数据位是1的话，就会补1
}
 

 
实例说明：将 -2进行 Zigzag编码：
 
 
Zigzag 编码 是补充 Varint编码在 表示负数 的不足，从而更好的帮助 Protocol Buffer进行数据的压缩
所以，如果提前预知字段值是可能取负数的时候，记得采用sint32 / sint64 数据类型
 
总结
 
Protocol Buffer 通过Varint和Zigzag编码后大大减少了字段值占用字节数。
 
7.1.2 存储方式:T - V
 
消息字段的标识号、数据类型 & 字段值经过 Protocol Buffer采用 Varint & Zigzag 编码后，以 T - V 方式进行数据存储
 
 
 
对于 Varint & Zigzag 编码，省略了T - L - V中的字节长度Length
 
 
 
下面将详细介绍T - V 存储方式中的存储细节：Tag & Value
 
1. Tag
 
定义：经过 Protocol Buffer采用Varint & Zigzag编码后 的消息字段 标识号 & 数据类型 的值
作用：标识 字段
 
 
 
存储了字段的标识号（field_number）和 数据类型（wire_type），即Tag = 字段数据类型（wire_type） + 标识号（field_number）
占用 一个字节 的长度（如果标识号超过了16，则占用多一个字节的位置）
解包时，Protocol Buffer根据 Tag 将 Value 对应于消息中的 字段
 
 
具体使用
 
// Tag 的具体表达式如下
 Tag  = (field_number << 3) | wire_type
// 参数说明：
// field_number：对应于 .proto文件中消息字段的标识号，表示这是消息里的第几个字段
// field_number << 3：表示 field_number = 将 Tag的二进制表示 右移三位 后的值 
// field_num左移3位不会导致数据丢失，因为表示范围还是足够大地去表示消息里的字段数目

//  wire_type：表示 字段 的数据类型
//  wire_type = Tag的二进制表示 的最低三位值
//   wire_type的取值
 enum WireType { 
      WIRETYPE_VARINT = 0, 
      WIRETYPE_FIXED64 = 1, 
      WIRETYPE_LENGTH_DELIMITED = 2, 
      WIRETYPE_START_GROUP = 3, 
      WIRETYPE_END_GROUP = 4, 
      WIRETYPE_FIXED32 = 5
   };

// 从上面可以看出，`wire_type`最多占用 3位 的内存空间（因为 3位 足以表示 0-5 的二进制）

//  以下是 wire_type 对应的 数据类型 表
 
 
实例说明
 
// 消息对象
 message person
 { 
    required int32     id = 1;  
    // wire type = 0，field_number =1 
    required string    name = 2;  
    // wire type = 2，field_number =2 
  }

//  如果一个Tag的二进制 = 0001 0010
标识号 = field_number = field_number  << 3 =右移3位 =  0000 0010 = 2
数据类型 = wire_type = 最低三位表示 = 010 = 2
 
2. Value
 
经过 Protocol Buffer采用Varint & Zigzag编码后 的消息字段的值
 
7.1.3 实例说明
 
下面通过一个实例进行整个编码过程的说明：
 
消息说明
 
message Test
{

required int32 id1 = 1；

required int32 id2 = 2；
}

// 在代码中给id1 附上1个字段值：296
// 在代码中给id2 附上1个字段值：296
Test.setId1（300）；
Test.setId2（296）；

// 编码结果为：二进制字节流 = [8，-84，2，16, -88, 2]
 
整个编码过程如下
 
 
 
7.2 Wire Type = 1& 5时的编码&数据存储方式
 
 
64（32）-bit编码方式较简单：编码后的数据具备固定大小 = 64位（8字节） / 32位（4字节）
 
 
 
两种情况下，都是高位在后，低位在前
 
 
采用T - V方式进行数据存储，同上。
 
7.3 Wire Type = 2时的 编码 & 数据存储方式
 
 
对于编码方式：
 
 
数据存储方式： T - L - V
 
 
此处主要讲解三种数据类型：
 
String类型
嵌套消息类型（Message）
通过packed修饰的 repeat 字段（即packed repeated fields）
 
1. String类型
 
字段值（即V） 采用UTF-8编码
 
 
例子：
 
message Test2
{
    required string str = 2;
}

// 将str设置为：testing
Test2.setStr（“testing”）

// 经过protobuf编码序列化后的数据以二进制的方式输出
// 输出为：18, 7, 116, 101, 115, 116, 105, 110, 103

 
 
2. 嵌套消息类型（Message）
 
存储方式：T - L - V
 
 
 
外部消息的 V即为 嵌套消息的字段
在 T - L -V 里嵌套了一系列的 T - L -V
 
 
编码方式：字段值（即V） 根据字段的数据类型采用不同编码方式
 
 
实例
 定义如下嵌套消息：
 
message Test2
{
    required string str = 1;
    required int32 id1 = 2；

    
}

message Test3 {
  required Test2 c = 1;
}

// 将Test2中的字段str设置为：testing
// 将Test2中的字段id1设置为：296
// 编码后的字节为：10 ，12 ，18，7，116, 101, 115, 116, 105, 110, 103，16，-88，2
 
编码 & 存储方式如下
 
 
3. 通过packed修饰的 repeat 字段
 
repeated 修饰的字段有两种表达方式：
 
message Test
{
    repeated int32 Car = 4 ;
    // 表达方式1：不带packed=true

    repeated int32 Car = 4 [packed=true];
    // 表达方式2：带packed=true
    // proto 2.1 开始可使用

// 区别在于：是否连续存储repeated类型数据
}


// 在代码中给`repeated int32 Car`附上3个字段值：3、270、86942

Test.setCar（3）；
Test.setCar（270）；
Test.setCar（86942）；
 
背景：对于同一个 repeated字段、多个字段值来说，他们的Tag都是相同的，即数据类型 & 标识号都相同
 
 
 
repeated类型可以看成是数组
 
 
问题：若以传统的多个 T - V对存储（不带packed=true），则会导致Tag的冗余，即相同的Tag存储多次；
 
 
解决方案：采用带packed=true 的 repeated 字段存储方式，即将相同的 Tag 只存储一次、添加 repeated 字段下所有字段值的长度Length、连续存储 repeated 字段值，组成一个大的Tag - Length - Value -Value -Value对，即T - L - V - V - V对。
 
 
通过采用带packed=true 的 repeated 字段存储方式，从而更好地压缩序列化后的数据长度。
 
特别注意
 
Protocol Buffer 的 packed修饰只用于repeated字段 或 基本类型的repeated字段
用在其他字段，编译 .proto 文件时会报错
 
 
8. 特别注意
 
注意1：若 required字段没有被设置字段值，那么在IsInitialized()进行初始化检查会报错并提示失败
 
 
 
所以 required字段必须要被设置字段值
 
 
注意2：序列化顺序 是根据 Tag标识号 从小到大 进行编码
 
 
 
和 .proto文件内 字段定义的数据无关
 
 
注意3：T - V的数据存储方式保证了Protobuf的版本兼容：高<->低 或 低<->高都可以适配
 
 
 
若新版本 增加了 required 字段， 旧版本 在数据解码时会认为IsInitialized() 失败，所以慎用 required字段
 
 
 
9. 使用建议
 
根据上面的序列化原理分析，我总结出以下Protocol Buffer的使用建议
 
 
 
通过下面建议能有效降低序列化后数据量的大小
 
 
建议1：多用 optional或 repeated修饰符
 因为若optional 或 repeated 字段没有被设置字段值，那么该字段在序列化时的数据中是完全不存在的，即不需要进行编码
 
 
 
相应的字段在解码时才会被设置为默认值
 
 
 
建议2：字段标识号（Field_Number）尽量只使用 1-15，且不要跳动使用
 因为Tag里的Field_Number是需要占字节空间的。如果Field_Number>16时，Field_Number的编码就会占用2个字节，那么Tag在编码时也就会占用更多的字节；如果将字段标识号定义为连续递增的数值，将获得更好的编码和解码性能
 
 
建议3：若需要使用的字段值出现负数，请使用 sint32 / sint64，不要使用int32 / int64
 因为采用sint32 / sint64数据类型表示负数时，会先采用Zigzag编码再采用Varint编码，从而更加有效压缩数据
 
 
建议4：对于repeated字段，尽量增加packed=true修饰
 因为加了packed=true修饰repeated字段采用连续数据存储方式，即T - L - V - V -V方式
 
 
 
10. 序列化 & 反序列化过程
 
Protocol Buffer除了序列化 & 反序列化后的数据体积小，序列化 & 反序列化的速度也非常快
下面我将讲解序列化 & 反序列化的序列化过程
 
10.1 Protocol Buffer的序列化 & 反序列化过程
 
序列化过程如下：
 
判断每个字段是否有设置值，有值才进行编码
根据 字段标识号&数据类型 将 字段值 通过不同的编码方式进行编码
 
由于：
 a. 编码方式简单（只需要简单的数学运算 = 位移等等）
 b. 采用 Protocol Buffer 自身的框架代码 和 编译器 共同完成
 
所以Protocol Buffer的序列化速度非常快。
 
反序列化过程如下：
 
调用 消息类的 parseFrom(input) 解析从输入流读入的二进制字节数据流
 
 
 
从上面可知，Protocol Buffer解析过程只需要通过简单的解码方式即可完成，无需复杂的词法语法分析，因此 解析速度非常快。
 
 
将解析出来的数据 按照指定的格式读取到 Java、C++、Phyton 对应的结构类型中
 
由于：
 a. 解码方式简单（只需要简单的数学运算 = 位移等等）
 b. 采用 Protocol Buffer 自身的框架代码 和 编译器 共同完成
 
所以Protocol Buffer的反序列化速度非常快。
 
10.2 对比于XML 的序列化 & 反序列化过程
 
XML的反序列化过程如下：
 
从文件中读取出字符串
将字符串转换为 XML 文档对象结构模型
从 XML 文档对象结构模型中读取指定节点的字符串
将该字符串转换成指定类型的变量
 
上述过程非常复杂，其中，将 XML 文件转换为文档对象结构模型的过程通常需要完成词法文法分析等大量消耗 CPU 的复杂计算。
 
因为序列化 & 反序列化过程简单，所以序列化 & 反序列化过程速度非常快，这也是 Protocol Buffer效率高的原因
 
 
11.总结
 
 
Protocol Buffer的序列化 & 反序列化简单 & 速度快的原因是：
 a. 编码 / 解码 方式简单（只需要简单的数学运算 = 位移等等）
 b. 采用 Protocol Buffer 自身的框架代码 和 编译器 共同完成
 
 
Protocol Buffer的数据压缩效果好（即序列化后的数据量体积小）的原因是：
 a. 采用了独特的编码方式，如Varint、Zigzag编码方式等等
 b. 采用T - L - V 的数据存储方式：减少了分隔符的使用 & 数据存储得紧凑
 
 
 
 
Carson带你学序列化Protocol Buffer系列文章
 快来看看Google出品的Protocol Buffer，别只会用Json和XML了
 Carson带你学序列化：手把手教你如何安装Protocol Buffer
 Carson带你学序列化：全面详解ProtocolBuffer语法
 Carson带你学序列化：Google出品的序列化神器Protocol Buffer使用指南
 Carson带你学序列化：Protocol Buffer序列化原理大揭秘-为什么性能这么好？
 Carson带你学序列化：深入源码分析Protocol Buffer
 Carson带你学序列化：深入分析JSON多种解析方式(Gson、AS自带org.json、Jackson)
 Carson带你学序列化：深入分析XML多种解析方式(DOM、SAX、PULL)
 
 
 
欢迎关注Carson_Ho的CSDN博客 与 公众号！
 
博客链接：https://carsonho.blog.csdn.net/
 
 
 
请帮顶 / 评论点赞！因为你的鼓励是我写作的最大动力！

 
文章目录
 
前言
Heap-buffer-overflow
Heap-use-after-free
Stack-buffer-overflow
Global-buffer-overflow

 
前言
 
在做LeetCode题时发现一个有趣的事情。
 对于C语言来说，如果直接访问超出Index的数组，会报错：
 
int main(int argc, char **argv) {
    int array  [100];
    array[101] = -1;
    int res = array[-1];  
    return res;
}
 
报错如下：
 
Runtime Error:
Line 3: Char 10: runtime error: index 101 out of bounds for type 'int [100]' (solution.c)
 
但是如果你使用malloc分配空间给int数组，index的越界访问是不会直接报错的
 
Heap-buffer-overflow
 
但是LeetCode 使用了AddressSanitizer检查是否存在内存非法访问
 
#include <stdlib.h>
int main(int argc, char **argv) {
    int *array = (int*)malloc(100 * sizeof(int));
    array[0] = -1;
    int res = array[-1];  // BOOM
    return res;
}
 
LeetCode 报错如下：
 
=================================================================
==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000000c at pc 0x000000401749 bp 0x7ffc91bd0570 sp 0x7ffc91bd0568
WRITE of size 4 at 0x60300000000c thread T0
    #3 0x7ff2c35d42e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

0x60300000000c is located 4 bytes to the left of 20-byte region [0x603000000010,0x603000000024)
allocated by thread T0 here:
    #0 0x7ff2c4a5e2b0 in malloc (/usr/local/lib64/libasan.so.5+0xe82b0)
    #4 0x7ff2c35d42e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

Shadow bytes around the buggy address:
  0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c067fff8000: fa[fa]00 00 04 fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==30==ABORTING
 
其实这是AddressSanitizer 这个工具的内存损坏检查报的错。
 可以在Linux上运行如下命令，检查程序是否存在内存非法访问：
 
gcc -O -g -fsanitize=address  test.c
./a.out
 
Linux下运行报错如下：
 
allocated by thread T0 here:
    #0 0x7f8eb21bfd28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
    #1 0x563aa79a68bd in main /root/test4.c:3

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/test4.c:5 in main
Shadow bytes around the buggy address:
  0x0c287fff9f70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff9f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff9f90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff9fa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff9fb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c287fff9fc0: fa fa fa fa fa fa fa[fa]00 00 00 00 00 00 00 00
  0x0c287fff9fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c287fff9fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c287fff9ff0: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
  0x0c287fffa000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fffa010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==7489==ABORTING

 
Heap-use-after-free
 
同时，AddressSanitizer也可以检查Heap-use-after-free的错：
 
int main(int argc, char **argv) {
  int *array = new int[100];
  delete [] array;
  return array[argc];  // BOOM
}
 
g++ -O -g -fsanitize=address heap-use-after-free.c
./a.out
 
报错如下：
 
=================================================================
==7849==ERROR: AddressSanitizer: heap-use-after-free on address 0x61400000fe44 at pc 0x56282de47977 bp 0x7fff9cfc65e0 sp 0x7fff9cfc65d8
READ of size 4 at 0x61400000fe44 thread T0
    #0 0x56282de47976 in main /root/heap-use-after-free.c:4
    #1 0x7fabfddb72e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
    #2 0x56282de47819 in _start (/root/a.out+0x819)

0x61400000fe44 is located 4 bytes inside of 400-byte region [0x61400000fe40,0x61400000ffd0)
freed by thread T0 here:
    #0 0x7fabfea96370 in operator delete[](void*) (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc3370)
    #1 0x56282de47941 in main /root/heap-use-after-free.c:3

previously allocated by thread T0 here:
    #0 0x7fabfea95d70 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2d70)
    #1 0x56282de47931 in main /root/heap-use-after-free.c:2

SUMMARY: AddressSanitizer: heap-use-after-free /root/heap-use-after-free.c:4 in main
Shadow bytes around the buggy address:
  0x0c287fff9f70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff9f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff9f90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff9fa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff9fb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c287fff9fc0: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd
  0x0c287fff9fd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c287fff9fe0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c287fff9ff0: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x0c287fffa000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fffa010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==7849==ABORTING
 
Stack-buffer-overflow
 
int main(int argc, char **argv) {
  int stack_array[100];
  stack_array[1] = 0;
  return stack_array[argc + 100];  // BOOM
}
 
gcc -O -g -fsanitize=address  test.c
./a.out
 
报错如下：
 
=================================================================
==8078==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffe55a7b04 at pc 0x555dec997a0e bp 0x7fffe55a7940 sp 0x7fffe55a7938
READ of size 4 at 0x7fffe55a7b04 thread T0
    #0 0x555dec997a0d in main /root/test6.c:4
    #1 0x7f903bdab2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
    #2 0x555dec997819 in _start (/root/a.out+0x819)

Address 0x7fffe55a7b04 is located in stack of thread T0 at offset 436 in frame
    #0 0x555dec99792f in main /root/test6.c:1

  This frame has 1 object(s):
    [32, 432) 'stack_array' <== Memory access at offset 436 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /root/test6.c:4 in main
Shadow bytes around the buggy address:
  0x10007caacf10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007caacf20: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
  0x10007caacf30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007caacf40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007caacf50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007caacf60:[f4]f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
  0x10007caacf70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007caacf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007caacf90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007caacfa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007caacfb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==8078==ABORTING

 
Global-buffer-overflow
 
int global_array[100] = {-1};
int main(int argc, char **argv) {
  return global_array[argc + 100];  // BOOM
}
 
gcc -O -g -fsanitize=address  test.c
./a.out
 
报错如下：
 
SUMMARY: AddressSanitizer: global-buffer-overflow /root/test6.c:3 in main
Shadow bytes around the buggy address:
  0x0ab033158fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab033158ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab033159000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab033159010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab033159020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab033159030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[f9]f9
  0x0ab033159040: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab033159050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab033159060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab033159070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab033159080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==8158==ABORTING

 
文章目录
 
一、Buffer 读API
二、字符串和Buffer的转换
三、分散读取
四、集中写
五、黏包和半包
现象
出现原因
1 黏包
2 半包
   
解决办法
 

 
 
一、Buffer 读API
 
Buffer rewind() 不改变极限，把位置设置为0，表示从头开始读取。
 
    public static void main(String[] args) {
        ByteBuffer buffer = ByteBuffer.allocate(10);
        buffer.put(new byte[]{'a','b','c','d'});
        buffer.flip();
        System.out.println((char) buffer.get());
        System.out.println((char) buffer.get());
        System.out.println((char) buffer.get());
        System.out.println((char) buffer.get());
        buffer.rewind();
        System.out.println((char) buffer.get());
        System.out.println((char) buffer.get());
    }
 
结果是：a、b、c、d、a、b
 调用rewind之后，从头开始再次读取。
 
Buffer reset() 将此缓冲区的位置重置为先前标记的位置。
Buffer mark() 将此缓冲区的标记设置在其位置。
 
    public static void main(String[] args) {
        ByteBuffer buffer = ByteBuffer.allocate(10);
        buffer.put(new byte[]{'a','b','c','d'});
        buffer.flip();
        buffer.get();
        buffer.get();
        ByteBufferUtil.debugAll(buffer);
        //此时position=2。标记此位置
        buffer.mark();
        buffer.get();
        buffer.get();
        //这里读取完毕，此时从标记位置开始读取
        buffer.reset();
        System.out.println((char) buffer.get());
        System.out.println((char) buffer.get());
    }
 
结果是c、d
 
abstract byte get(int index) 获取制定位置的字节，不改变位置。
 
    public static void main(String[] args) {
        ByteBuffer buffer = ByteBuffer.allocate(10);
        buffer.put(new byte[]{'a','b','c','d'});
        buffer.flip();
        System.out.println((char) buffer.get(2)); //c
        ByteBufferUtil.debugAll(buffer);
    }
 
 
二、字符串和Buffer的转换
 
    public static void main(String[] args) {
        ByteBuffer buffer1 = ByteBuffer.allocate(16);
        buffer1.put("hello".getBytes());
        debugAll(buffer1);
    }
 

 此时没有切换到读模式。所以要想读取，还是调用flip()方法；
 
使用StandardCharsets也可以构造buffer。而且极限根据字节大小设置。并且自动切换到读模式。
 
    public static void main(String[] args) {
        ByteBuffer buffer2 = StandardCharsets.UTF_8.encode("hello");
        debugAll(buffer2);
    }
 
 
  ByteBuffer buffer3 = ByteBuffer.wrap("hello".getBytes());
  debugAll(buffer3);
 

 ByteBuffer.wrap的作用和StandardCharsets一样的。也是自动切换读取模式。
 
StandardCharsets.UTF_8.decode转化buffer为字符串。
 
        //转化字符串
        String s=StandardCharsets.UTF_8.decode(buffer2).toString();
        System.out.println(s);
        //针对buffer1.因为没有转化读取模式，所以这里需要调用flip
        buffer1.flip();
        String s2=StandardCharsets.UTF_8.decode(buffer1).toString();
        System.out.println(s2);
 
三、分散读取
 
假设word1.txt中有数据onetwothree。我们需要一次性读取。
 
    public static void main(String[] args) {
        //twr Java7快速关闭
        try (FileChannel channel = new RandomAccessFile("word1.txt", "r").getChannel()) {
            ByteBuffer buffer1 = ByteBuffer.allocate(3);
            ByteBuffer buffer2 = ByteBuffer.allocate(3);
            ByteBuffer buffer3 = ByteBuffer.allocate(5);
            //一次性读取
            channel.read(new ByteBuffer[]{buffer1,buffer2,buffer3});
            buffer1.flip();
            buffer2.flip();
            buffer3.flip();
            debugAll(buffer1);
            debugAll(buffer2);
            debugAll(buffer3);
        } catch (IOException e) {
        }
    }
 
 
四、集中写
 
将one、two、three一次性写入buffer.
 
    public static void main(String[] args) {
        ByteBuffer buffer1 = StandardCharsets.UTF_8.encode("one");
        ByteBuffer buffer2 = StandardCharsets.UTF_8.encode("two");
        ByteBuffer buffer3 = StandardCharsets.UTF_8.encode("three");
        try (FileChannel channel = new RandomAccessFile("word2.txt", "rw").getChannel()) {
            channel.write(new ByteBuffer[]{buffer1,buffer2,buffer3});
        } catch (IOException e) {
        }
    }
 
五、黏包和半包
 
现象
 
网络上有多条数据发送给服务端，数据之间使用 \n 进行分隔
 但由于某种原因这些数据在接收时，被进行了重新组合，例如原始数据有3条为
 
Hello,world\n
I’m Nyima\n
How are you?\n
变成了下面的两个 byteBuffer (粘包，半包)

Hello,world\nI’m Nyima\nHo
w are you?\n
 
出现原因
 
1 黏包
 
发送方在发送数据时，并不是一条一条地发送数据，而是将数据整合在一起，当数据达到一定的数量后再一起发送。这就会导致多条信息被放在一个缓冲区中被一起发送出去
 
2 半包
 
接收方的缓冲区的大小是有限的，当接收方的缓冲区满了以后，就需要将信息截断，等缓冲区空了以后再继续放入数据。这就会发生一段完整的数据最后被截断的现象
 
解决办法
 
通过get(index)方法遍历ByteBuffer，遇到分隔符时进行处理。注意：get(index)不会改变position的值
 记录该段数据长度，以便于申请对应大小的缓冲区
 将缓冲区的数据通过get()方法写入到target中
 调用compact方法切换模式，因为缓冲区中可能还有未读的数据
 
public class BufferNianBao {

    public static void main(String[] args) {
        //模拟黏包的半包的读取
         ByteBuffer buffer = ByteBuffer.allocate(32);
        // 模拟粘包+半包
        buffer.put("Hello,world\nI'm Gosaint\nHo".getBytes());
        // 调用split函数处理
        split(buffer);
        buffer.put("w are you?\n".getBytes());
        split(buffer);
    }

    private static void split(final ByteBuffer buffer) {
        buffer.flip();
        for(int i=0;i<buffer.limit();i++){
            if (buffer.get(i)=='\n') {
                //遇到\n，表示一个完整的语句。写入的buffer
                int length=i+1-buffer.position();
                ByteBuffer target = ByteBuffer.allocate(length);
                //将数据写入target
                for (int j = 0; j < target.limit(); j++) {
                    // 将buffer中的数据写入target中
                    target.put(buffer.get());
                }
                debugAll(target);
            }
        }
        //读取完毕之后读取剩余的部分，不能使用clear。clear会从头开始的
        buffer.compact();
    }
}

s_ring_buffer库是一个采用MIT License协议开源的、小巧的、纯C语言的、ring_buffer实现，读写锁分离设计，核心实现代码平台无关（抽出了平台相关的适配层）, 可以方便的进行移植、使用。
 
仓库地址：https://github.com/smallerxuan/s_ring_buffer.git
 
s_ring_buffer用户接口
 
s_ring_buffer包含如下用户接口：`
 
1、构造器接口 s_ring_buffer_constructor()
 
2、析构器接口 s_ring_buffer_destructor()
 
3、清除接口 s_ring_buffer_clear()
 
4、元素写入接口s_ring_buffer_write_elements()
 
5、元素读取接口 s_ring_buffer_read_elements()
 
6、容量获取接口 s_ring_buffer_cap_get()
 
7、可读元素数量获取接口 s_ring_buffer_could_read_num_get()
 
7、可写元素数量获取接口 s_ring_buffer_could_write_num_get()
 
s_ring_buffer的移植、适配
 
s_ring_buffer源码中的 s_ring_buffer_platform.h、s_ring_buffer_platform.c文件包含了s_ring_buffer的平台相关 数据类型、宏、抽象接口，主要包括：
 
内存操作相关宏：
s_ring_buff_malloc、s_ring_buff_free、s_ring_buff_memcpy
 
2、休眠相关宏 s_ring_buff_sleep
 
3、锁类型定义 s_ring_buffer_lock_t
 
4、锁操作相关接口：
 
   s_ring_buffer_lock()、s_ring_buffer_trylock()、s_ring_buffer_unlock()
 
用户在移植、适配时，只需要对上述内容进行适配、实现，便能方便的在任意平台使用。