ChronicleMap删除条目后无法达到配置的最大Entries阈值问题排查

故障原因 #

• 逻辑删除未触发空间回收：Chronicle Map为了保障写入性能，删除操作默认采用逻辑删除，仅标记条目为无效状态，不会立即释放和整理对应的堆外内存空间。你代码中没有手动触发碎片整理，无效条目占用的存储槽无法被新写入复用，导致预分配空间被逐渐占满，可容纳的最大条目数持续下降。
• allowSegmentTiering参数关闭放大问题：你将该参数设为false，关闭了分段分层扩容能力，单个segment的初始预分配空间用完后，哪怕存在未整理的逻辑删除空间，也无法临时申请额外分层存储新条目，直接抛出写入失败异常。
• 预览版本存在已知缺陷：你使用的3.22ea5是早期预览版本，空间复用逻辑本身有未修复的问题，会进一步加剧空间无法回收的现象。
• 哈希分布不均：你按全局遍历顺序批量删除5%的条目，不同segment删除的条目数量不均，部分segment剩余可用空间远低于平均水平，新写入的键哈希到这些segment时会提前触发容量不足错误，导致整体Map的实际可容纳条目数远低于配置的entries值。

配置与使用错误点 #

• 缺少内存整理逻辑：每次批量删除条目后，需要调用main.cleanup()方法手动触发碎片回收，才能让逻辑删除的空间被新写入复用。
• 不必要的关闭allowSegmentTiering：如果没有严格的固定内存占用需求，不要关闭该参数，它可以在单segment空间不足时临时申请分层空间，避免偶发哈希分布不均导致的提前写入失败。
• 选用不稳定的预览版本：建议切换到3.24及以上的稳定正式版本，规避已知的空间复用bug。
• 全局删除逻辑未考虑segment粒度均衡：当前的全局批量删除逻辑无法保证每个segment都有足够可用空间，建议改为按segment粒度检查剩余容量，针对性删除对应segment的条目，避免单segment提前写满。

场景适配说明 #

Chronicle Map的核心设计目标是高吞吐量的堆外/持久化键值存储，原生没有内置LRU淘汰、自动碎片整理能力，不是LRU缓存场景的最优选型。如果要强行用于LRU缓存场景，需要额外实现上述的碎片整理、segment粒度容量管理逻辑，运维成本会较高。

内容的提问来源于stack exchange，提问作者Aravind