23、内存池与持久内存：NVDIMM支持、持久化语义、事务性更新
持久内存这个话题，说实话，我接触得不算早。大概五年前，我第一次在数据中心项目里看到NVDIMM，当时心里还嘀咕：这不就是一块不会丢数据的DRAM吗？后来踩了几个坑才明白——它远没那么简单。
传统的DRAM，断电即失。硬盘呢，慢得像蜗牛。持久内存正好卡在中间——它既有内存的字节寻址能力，又有硬盘的非易失性。你想想看，这对内存池设计意味着什么？
意味着你的内存池，不能再只管分配和释放了。你还得管数据死活。
NVDIMM的硬件特性
NVDIMM全称是非易失性双列直插内存模块。市面上主流的有三种：
| 类型 | 原理 | 特点 |
|---|---|---|
| NVDIMM-N | DRAM + 闪存 + 超级电容 | 断电时自动备份到闪存，恢复时再加载回来 |
| NVDIMM-F | 纯闪存，走DDR总线 | 便宜，但写入延迟高，不能当普通内存用 |
| Intel Optane PMem | 3D XPoint技术 | 字节可寻址，延迟接近DRAM，容量大 |
我个人习惯用Optane PMem做实验。它有个特点：写入比读取慢，而且写入次数有限。所以设计内存池时，得考虑磨损均衡。
核心要点：持久内存不是「不会丢的DRAM」。它的写入延迟、带宽、寿命都和DRAM不同。你的内存池必须感知这些差异。
持久化语义：刷写与顺序保证
这里有个坑，我当年栽过。你往持久内存里写了一个值，断电了，再开机发现数据是旧的。为什么？
因为CPU有缓存。数据可能还在L1 cache里，根本没落到NVDIMM上。就算落到了内存控制器，也可能在写缓冲区里排队。
所以，持久化语义的核心就两个：
- 刷写（Flush）：把缓存行写回持久内存
- 屏障（Fence）：保证刷写顺序
x86上有三条指令：
// 刷写一个缓存行
void pmem_flush(void *addr, size_t len) {
for (size_t i = 0; i < len; i += 64) {
_mm_clwb((void *)((uintptr_t)addr + i));
}
_mm_sfence(); // 保证所有刷写完成
}
// 更激进的做法：直接非临时写，绕过缓存
void pmem_write_nontemporal(void *addr, uint64_t val) {
_mm_stream_si64((long long *)addr, val);
_mm_sfence();
}嗯，这里要注意：_mm_clwb 是刷写但不失效缓存行。如果你用 _mm_clflush，会把缓存行也干掉，下次读就慢了。我建议用 clwb，除非你知道自己在做什么。
小技巧：写持久内存时，尽量用64字节对齐的写入。一次刷一个缓存行，效率最高。我曾经见过有人逐字节刷写，性能直接崩到硬盘级别。
事务性更新：要么全写，要么不写
持久内存最麻烦的问题是什么？是部分写入。
假设你要更新一个链表节点。你先写了next指针，断电了。再开机，prev指针还是旧的。链表结构就坏了。
解决办法就是事务性更新。说白了，就是「先记日志，再写数据」。
我常用的模式是 Redo Log：
struct pmem_log_entry {
uint64_t addr;
uint64_t old_value;
uint64_t new_value;
uint32_t valid; // 标记是否有效
};
#define LOG_SIZE 1024
struct pmem_transaction {
struct pmem_log_entry log[LOG_SIZE];
uint32_t count;
uint32_t committed;
};
// 开始事务
void tx_begin(struct pmem_transaction *tx) {
tx->count = 0;
tx->committed = 0;
pmem_flush(tx, sizeof(*tx));
}
// 记录写入
void tx_write(struct pmem_transaction *tx, void *addr, uint64_t new_val) {
uint32_t idx = tx->count;
tx->log[idx].addr = (uint64_t)addr;
tx->log[idx].old_value = *(volatile uint64_t *)addr;
tx->log[idx].new_value = new_val;
tx->log[idx].valid = 1;
tx->count++;
pmem_flush(&tx->log[idx], sizeof(tx->log[0]));
}
// 提交事务
void tx_commit(struct pmem_transaction *tx) {
// 先写数据
for (uint32_t i = 0; i < tx->count; i++) {
*(volatile uint64_t *)tx->log[i].addr = tx->log[i].new_value;
pmem_flush((void *)tx->log[i].addr, 8);
}
// 再标记提交
tx->committed = 1;
pmem_flush(&tx->committed, sizeof(tx->committed));
_mm_sfence();
}
// 恢复：检查日志，如果committed为1但数据没写完，重做
void tx_recover(struct pmem_transaction *tx) {
if (!tx->committed) return;
for (uint32_t i = 0; i < tx->count; i++) {
if (tx->log[i].valid) {
*(volatile uint64_t *)tx->log[i].addr = tx->log[i].new_value;
}
}
pmem_flush(tx, sizeof(*tx));
}这个模式的关键是：先写日志，再写数据。日志写完后，如果断电了，恢复时检查日志，把没写完的数据补上。
警告：千万别把日志和数据放在同一个缓存行里。否则刷日志的时候，可能把数据也带出去，顺序就乱了。我吃过这个亏，调试了整整两天。
内存池如何集成持久化
好了，现在我们把持久化语义和事务性更新，塞进内存池里。
设计思路是这样的：
- 内存池的元数据（空闲链表、分配位图）必须持久化
- 每次分配/释放，都要走事务
- 分配出去的内存，由使用者自己决定是否持久化
我画了一张图，展示持久内存池的核心流程：
你看，每次分配或释放，都要经过事务层。事务层先写日志，再更新元数据，最后刷写。如果中途断电，恢复时根据日志重做或回滚。
实际项目中的经验
我在一个键值存储项目里用过这套设计。当时遇到一个头疼的问题：性能。
每次分配都刷写，太慢了。后来我做了个优化：批量提交。把多个分配/释放操作攒起来，一次事务提交。吞吐量直接翻了3倍。
还有一个坑：内存泄漏检测。持久内存的泄漏不会因为重启就消失。你分配了没释放，机器重启了，那块内存还是占着的。所以必须加引用计数或者GC。
建议：在持久内存池里加一个「启动时校验」的步骤。扫描所有已分配块，检查是否有孤儿块。如果有，记日志但不自动回收——让开发者手动处理。自动回收太危险，万一回收了还在用的数据呢？
总结一下
持久内存池的设计，说白了就是三件事：
- 感知硬件：知道NVDIMM的延迟、带宽、寿命特性
- 保证持久化：用CLWB+SFENCE确保数据落盘
- 事务性更新：用Redo Log或Undo Log保证原子性
我个人觉得，持久内存是未来。随着NVDIMM价格下降，会有越来越多的系统用它。现在把内存池的持久化支持做好，以后迁移起来就轻松多了。
嗯，今天就聊到这儿。记住：持久内存不是普通内存，别拿DRAM那套直接往上套。