Blocky项目内存优化实践：列表分组策略对内存占用的影响分析

背景概述

在DNS过滤工具Blocky的实际使用中，管理员发现一个有趣现象：将相同的域名过滤规则分散到多个独立列表组时，相比将所有规则合并到单个列表组，能够显著降低内存占用。本文将通过技术原理分析这一现象，并给出优化建议。

现象重现

测试环境使用Docker容器运行Blocky v0.23版本，观察到两种配置方案的内存差异：

1. 分组配置方案（内存602MB）

   • 将过滤规则按功能分为5个独立列表组（广告、威胁情报、访问控制、代理绕过等）
   • 每个列表组加载1-2个外部规则文件

2. 合并配置方案（内存735MB）

   • 将所有规则合并到单个"ads"列表组
   • 其他列表组保持为空

测试结果显示分组方案比合并方案节省约18%的内存空间（133MB）。

技术原理分析

这种现象与Go语言底层的内存管理机制密切相关：

1. Map的扩容机制

   • Go语言的map类型采用哈希表实现，当元素数量超过当前桶容量时，会触发扩容（通常双倍扩容）
   • 扩容后即使删除元素，已分配的内存也不会立即释放

2. 内存碎片化影响

   • 单个大型map需要预留更多连续内存空间
   • 多个小型map可以利用内存碎片，提高空间利用率

3. 哈希碰撞概率

   • 大型map的哈希碰撞概率更高，可能导致更深的链表结构
   • 分散的小map保持较低的碰撞率

优化建议

基于上述分析，对于Blocky用户建议：

1. 合理分组策略

   • 按功能/更新频率划分列表组（如广告、恶意域名、访问控制等）
   • 每个列表组包含1-3个规则文件为佳

2. 定期维护

   • 移除不再使用的列表组
   • 清理失效的规则来源

3. 监控调整

   • 使用docker stats观察内存变化
   • 通过Blocky的metrics接口获取详细指标

扩展思考

这种优化思路不仅适用于Blocky项目，对于其他使用Go语言开发的高性能网络服务也有参考价值，特别是在处理大量规则匹配、路由表等场景时，分散存储结构往往能带来更好的内存利用率。

开发者可以考虑在以下方面进一步优化：

• 实现更智能的map收缩机制
• 采用分层数据结构
• 对静态规则使用更紧凑的存储格式