Map分片本身不能突破单机内存极限，必须结合分布式部署、按需加载和跨节点存储分离；关键包括分片键路由、独立DB实例、禁用全局缓存、单节点仅驻留活跃分片、内存映射文件替代堆存储、外挂协调服务实现弹性伸缩。
直接用 Map 分片（Sharding）本身并不能突破单台服务器的内存物理极限——因为分片只是逻辑拆分，若所有分片仍加载在同一个 JVM 进程里，总内存占用仍在本地 RAM 范围内。真正突破单机内存限制，必须配合**分布式部署 + 数据按需加载 + 跨节点存储分离**。以下是可落地的关键设计要点：
分片不是目的，而是数据路由的起点
MapDB 或类似嵌入式引擎的“分片”，本质是把一个大 Map 拆成多个子 Map，并分配到不同物理节点（而非仅不同线程或对象）。关键操作包括：
- 定义分片键（如 user_id % 16），确保热点数据均匀分布
- 每个分片绑定独立 DB 实例（例如 FileHeapBufStore），避免共享堆内存竞争
- 禁用全局缓存，关闭自动加载全量索引，只按请求加载对应分片元数据
单节点不存全量，只驻留活跃分片
一台服务器不应承载全部分片，而应只加载当前业务所需的部分分片（例如按地域或时间窗口预热）。实战中建议：
- 启动时只挂载 2–4 个分片（通过 DBMaker.fileDB().fileName("shard-001.dat").make()）
- 运行时通过 StoreTx 控制事务边界，确保跨分片写操作走两阶段提交
- 闲置分片文件保持关闭状态，不创建 MappedByteBuffer，不触发 mmap 映射
用内存映射文件替代堆内 Map 存储
当单一分片数据仍超内存时，必须脱离 JVM 堆管理。MapDB 支持底层使用 FileHeapBufStore，但更高效的是手动结合 MappedByteBuffer：
- 将每个分片数据序列化为固定结构二进制块（如 id+value 长度前缀+内容）
- 用
FileChannel.map(READ_ONLY, offset, size)按需映射片段（注意：单次 ≤2GB） - 查询时定位分片号 → 计算文件偏移 → 映射对应段 → 直接 ByteBuffer.get() 解析，全程不进堆
- 使用完立即调用
sun.misc.Cleaner（或反射释放）防止 VMA 泄漏
配合外部协调服务实现弹性伸缩
纯 MapDB 不自带集群发现，需轻量级外挂协调机制来动态扩缩容：
- 用 Redis 或 ZooKeeper 维护分片路由表（如 shard-003 → 192.168.1.12:8080）
- 新增节点后，由协调器触发部分分片迁移（迁移过程停写该分片，同步拷贝文件+校验 CRC）
- 客户端 SDK 封装路由逻辑：先查协调服务，再直连目标节点，绕过中心代理降低延迟
