技巧 & 经验
性能优化
把repeated message结构尽可能摊平为基础类型的repeated字段
基础类型的repeated字段，包含 repeated int32, int64, float,double，bool等，但不包含string、bytes、message
比如：
message Item {
int32 id = 1;
int32 score = 2;
}
message R {
repeated Item items = 1;
}改为下面的设计，会提升序列化和反序列效率
message R {
repeated int32 item_id = 1;
repeated int32 item_score = 2;
}原理是非string的基础类型的repeated字段，在申请内存时pb会申请连续线性大块内存，效率高；而message 的repeated字段，会按对象逐个去申请空间。
这种设计还有一个好处就是不会触发调用析构函数，如果采取 repeated Item 这种结构，会触发大量的析构函数，浪费 CPU 与 时间。（by chengyuxuan_yutian@163.com）
善用arena管理内存
- arena对基础类型,比如int32, int64, float,double,bool等管理效率优化明显
- arena不会管理string类型的内存申请（更高的版本已经支持，待验证）。
用固定长度repeated uint32 替换字符串
字符串是一种不定长的数据结构，内存管理方式成本较高。对于定长的字符串，通过转换成repeated uint32类型，可以获得更高效的管理。
除此之外，repeated uint32 也支持由arena管理。
善用Any类型
假设3个网络服务的调用关系如下：
A->B->C。
其中存在某些pb结构仅会由B透传给C，而B不需要解析，则可以把这些pb放入定义为any类型的字段中。
善用浅拷贝机制（set_allocated_xxx/release）
CopyFrom是深拷贝，若要实现浅拷贝则可以通过 set_allocated_xxx/release 两个函数进行控制
结合arena使用浅拷贝机制（unsafe_arena_set_allocated）
set_allocated_xxx的风险在于，pb析构的时候会把元素也析构掉，无法重复利用。且在一些特殊场景，在无法控制pb析构而不能使用release函数。这些场景可能是pb的析构工作由框架控制，旧的代码封装层次太深等。
这种情况可以使用unsafe_arena_set_allocated_xxx 避开这个问题。
使用陷阱
不要有交叉依赖
举例一C++系统中，模块A依赖 PB；模块B依赖PB，而模块C依赖A和B。则编译模块C时一定要同时编译A、B、PB。
利用protobuf一些特性来规避陷阱
良好的可扩展性 & 保留未定义字段
良好的可扩展性使得protobuf更好地向后兼容。上游更新了proto，新增字段，下游虽然没有更新proto文件，但是新增的字段依然可以保留，来自上游的字段可以透传给下游。拼接下游请求的结构pb时，尽可能使用CopyFrom，避免把字段逐个set。
使用编号定位存储的字段
为了更好地向后兼容，应该避免修改proto文件中现有字段的名字、类型。需要修改时，通过追加新字段（字段编号增加），弃用旧字段的方式。
故障相关
protobuf被广泛使用，饱经业界考验，如果遇到问题，绝大多数还是自身软件设计的问题。遇到问题，首先不应该怀疑protobuf，应该把视角集中到去发现自身的系统设计缺陷中。
一次内存泄露的故障排查
现象：
公司里一个c++网络服务中， PV较低时没有内存泄露；而PV较高，cpu idle降到30%以下，开始内存泄露，直到OOM。
排查过程：
用了 tcmalloc和gperf，逐步定位是protobuf 申请 repeated字段的空间，没有及时释放。repeated字段约1k～1w的规模。然后逐步缩小范围。
结果：
竟然是释放内存，都放到了一个线程中。当流量大时，单个线程计算能力成为瓶颈，内存释放变慢，表现为内存泄漏。
总结
protobuf释放的代价较大，不要全部的protobuf只放在一个线程操作。场景距离，lru cache的过期元素剔除。