多个线程不能并发更新同一哈希上下文，因其内部状态无锁保护，会导致哈希错误或崩溃；正确做法是并行读取文件块、单线程累积哈希，或改用支持并行的HighwayHash。
不能靠多线程并发更新同一个哈希上下文——会崩溃或结果错乱；并行只该用在 I/O 层，哈希计算本身必须串行完成。
为什么多个线程不能同时调用 EVP_DigestUpdate 或 MD5_Update
因为这些函数操作的是共享的内部状态（比如 MD5_CTX 里的 4 个 unsigned long 累加器 + 64 字节缓冲区），没有任何原子保护或锁机制。两个线程同时写同一块内存，轻则哈希值错误，重则触发 segmentation fault。
- 错误现象：
EVP_DigestUpdate返回 0、MD5_Final输出全 0、程序随机 crash - 别信“我加了 mutex 就安全”——加锁后性能还不如单线程，且容易漏锁或死锁
- OpenSSL 的 EVP 接口不是为并发设计的；
SHA256_Init/SHA256_Update这类底层 C 函数更危险，连参数合法性都不检查
正确做法：每个线程独立打开文件 + 定位读取 + 收集 chunk
文件系统支持随机读，但 C++ 流对象（如 std::ifstream）不是线程安全的。多个线程共用一个流对象调 seekg() + read()，位置指针会互相覆盖，实际读到的数据不可控。
- 每个线程用
std::ifstream独立打开文件（或用open()+pread()更底层） - 传入明确的
offset和length，用seekg(offset)定位后读固定长度 - 别依赖
tellg()校验位置——多线程下它可能返回-1或未定义值 - 读完后把
buf和真实字节数（gcount()）交给主线程统一处理
推荐组合：并行读 + 单线程哈希 + MAP_POPULATE 加速 mmap
想真正提速，关键不是让 CPU 更忙，而是减少 I/O 等待。实测中，并行读比单线程读快 2–4 倍（尤其在 NVMe 或 RAID 上），而哈希计算本身通常不构成瓶颈。
立即学习“C++免费学习笔记（深入）”；
- 用
mmap替代read()？可以，但必须带MAP_PRIVATE | MAP_POPULATE—— 否则首次访问映射页时触发缺页中断，线程卡住，失去并行意义 - buffer 大小建议设为
65536（64KB）到1048576（1MB）；太小增加系统调用开销，太大无收益 - 禁用流缓冲：
ifs.rdbuf()->pubsetbuf(nullptr, 0)，你已手动管理 buffer，双重缓冲反而拖慢 - 最后所有 chunk 收齐，再用单线程调一次
EVP_DigestUpdate（或hasher.update()）完成累积计算
想直接上并行哈希？换 HighwayHash 的 DataParallelHash
如果你不需要兼容 OpenSSL、不强制要求 SHA256/MD5，HighwayHash 是少数真正支持安全并行哈希的库。它的 DataParallelHash 模板内部做了数据分片、状态隔离和归并，不用你操心线程安全。
- 头文件：
#include "highwayhash/data_parallel.h" - 用法示例：
DataParallelHash<highwayhashcat>> hasher;</highwayhashcat>，然后多线程调hasher.Append(buffer, size) - 最终调
hasher.Finalize(result)得到完整哈希值，不是 N 个片段哈希拼起来的那种 - 注意：它不兼容标准哈希算法，输出值跟 SHA256 不等价，仅适用于内部校验场景
最容易被忽略的一点：哈希值是否正确，永远取决于最后一块读了多少字节——gcount() 是唯一可信依据，eof() 和 file_size() 都可能失准，尤其是 NFS 或文件被截断时。
