直接用 LZ4_compress_default 会丢数据,因其不检查目标缓冲区大小,易越界写导致崩溃;须用 LZ4_compress_fast 或 LZ4_compress_destSize 并配合 LZ4_compressBound 预留空间,失败时降级为未压缩存储。

为什么直接用 LZ4_compress_default 会丢数据?
因为 LZ4 压缩后数据长度不确定,而“透明存储”要求写入和读取的内存布局完全一致——即你申请了 1MB 缓冲区,就得让压缩后的数据也塞进这 1MB 里,且解压时能原样还原。但 LZ4_compress_default 默认不检查目标缓冲区大小,超了就越界写,轻则覆盖相邻变量,重则触发 SIGSEGV。
必须改用带长度校验的接口,并预留足够空间:
-
LZ4_compressBound(size)返回该大小原始数据「最坏情况」下所需的最大压缩缓冲区字节数(注意:不是实际压缩后长度) - 实际压缩必须用
LZ4_compress_fast或LZ4_compress_destSize,并传入真实目标缓冲区大小,否则 LZ4 内部不会做截断保护 - 若压缩失败(返回 0),说明目标缓冲区太小——此时不能强行写,而应 fallback 到未压缩存储或扩大缓冲区
如何在不改结构体定义的前提下实现字段级透明压缩?
核心是把压缩/解压逻辑封装进访问器,而非修改内存布局。比如一个含 std::vector<uint8_t></uint8_t> 的结构体,不要直接暴露 raw data 指针,而是提供:
class CompressedBlob {
std::vector<uint8_t> m_storage; // 存压缩后数据 + 元信息
size_t m_uncompressed_size = 0;
<p>public:
void set_raw(const uint8_t<em> data, size_t size) {
const int max_compressed = LZ4_compressBound(size);
m_storage.resize(max_compressed + sizeof(size_t));
int compressed_size = LZ4_compress_fast(
(const char</em>)data,
(char*)m_storage.data() + sizeof(size_t),
size,
max_compressed,
1 // acceleration: 1=fastest
);
if (compressed_size > 0) {
memcpy(m_storage.data(), &size, sizeof(size_t));
m_storage.resize(compressed_size + sizeof(size_t));
} else {
// fallback: 存原始数据,加标记位(如 size_t 高位设 1)
uint64_t flag_size = size | (1ULL </p>
<pre class="brush:php;toolbar:false;">std::vector<uint8_t> get_raw() const {
size_t stored_size;
memcpy(&stored_size, m_storage.data(), sizeof(size_t));
bool is_compressed = (stored_size & (1ULL out(uncompressed_size);
LZ4_decompress_safe(
(const char*)m_storage.data() + sizeof(size_t),
(char*)out.data(),
m_storage.size() - sizeof(size_t),
uncompressed_size
);
return out;
} else {
stored_size &= ~(1ULL (
m_storage.begin() + sizeof(size_t),
m_storage.begin() + sizeof(size_t) + stored_size
);
}
}</uint8_t>
};
关键点:m_uncompressed_size 必须显式保存(压缩后无法推导),且 fallback 路径要用可区分的标记,避免解压时误判。
mmap 场景下如何避免解压时的额外内存拷贝?
如果数据来自 mmap(例如只读大文件映射),直接解压到堆内存会多一次 copy。可行做法是:用 LZ4_decompress_safe_partial 解压到预分配的、与 mmap 区域等长的匿名映射页中(MAP_ANONYMOUS | MAP_PRIVATE),再用 madvise(..., MADV_DONTNEED) 在使用后快速释放物理页。
但注意两点硬限制:
-
LZ4_decompress_safe_partial要求目标缓冲区 ≥ 原始数据大小,且必须是可写内存——mmap 的只读区域不能直接当输出缓冲区 - 压缩数据本身不能跨页边界被截断(LZ4 block 是自同步的,但流式解压需完整 block),所以 mmap 区域若被分块压缩,每块头部需存 length + checksum,不能只靠 offset 推算
性能陷阱:什么时候 LZ4 反而比 memcpy 慢?
小于 ~256 字节的数据,LZ4 压缩开销(函数调用、分支预测、内存对齐检查)大概率超过其节省的 I/O 或内存带宽收益。实测中,LZ4_compress_fast(data, out, 128, 128, 1) 在小数据上可能比 memcpy 慢 3–5 倍。
建议策略:
- 设置硬阈值(如 512 字节),低于该值直接 memcpy 存储,不压缩
- 对高频访问的小结构体(如 per-packet header),宁可冗余存储也不压缩
- 批量压缩时用
LZ4_compress_HC无意义——它牺牲速度换压缩率,而“透明存储”首要目标是低延迟,不是高压缩比
真正影响体验的往往不是算法本身,而是忘了压缩前先判断数据是否值得压——尤其是 protobuf 序列化后的小消息体,base64 编码再压缩更是负优化。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











