集合与原始类型差距：Trove vs fastutil 优化解析

Java集合框架因强制装箱基本类型而带来显著的CPU开销与GC压力，Trove和FastUtil通过底层重写、直接用原始类型数组存储数据来彻底规避这一瓶颈；其中FastUtil凭借持续活跃维护、原生64位支持、完美兼容JDK接口以及丰富的实用功能（如双向迭代、快速序列化），已全面超越停滞更新的Trove，实测在高频数值处理场景中可实现内存占用减半、吞吐量提升150%、Young GC频率下降超七成——对于日均处理亿级原始数据的高性能系统而言，切换至FastUtil不是简单优化，而是消除装箱冗余、释放硬件潜能的关键架构升级。

Java 的集合框架天生不支持原始类型，所有基本类型（int、long、double 等）都必须包装成对象（Integer、Long、Double）才能存入 ArrayList 或 HashMap。这带来两个硬伤：频繁装箱拆箱消耗 CPU，大量小对象加重 GC 压力。Trove 和 FastUtil 就是为填平这道鸿沟而生的——它们不是“增强”，而是从底层重写，用数组直存原始值。

为什么装箱是性能黑洞

每次往 HashMap 插入一个键值对，JVM 都要新建两个包装对象。1000 万条数据 ≈ 2000 万个短期存活对象。这些对象很快进入年轻代，触发频繁 Minor GC；部分逃逸的对象还会晋升到老年代，拖慢 Full GC。FastUtil 的 Int2LongOpenHashMap 则完全跳过这一步：内部用两个平行的 int[] 和 long[] 数组存储 key 和 value，内存连续、无引用、零 GC 开销。

FastUtil 比 Trove 更值得选的现实理由

• 持续维护：FastUtil 最新稳定版为 8.5.15+（2026 年仍在高频更新），Trove 自 2020 年起已无实质提交，GitHub 显示为归档状态
• 超大容量支持：FastUtil 提供 64 位集合（如 LongBigArrayBigList），可容纳远超 2³² 元素；Trove 仅支持 32 位索引
• 接口兼容性更强：FastUtil 所有集合均完整实现 java.util 对应接口（如 Map、List），可直接替换旧代码，无需改逻辑；Trove 部分类使用自定义接口，迁移成本略高
• 额外能力实用：内置双向迭代器、快速序列化、内存映射 I/O 工具类，Trove 几乎不提供这类扩展

怎么用才真正发挥原始类型优势

光引入依赖不够，关键在用对类、设对参数：

• 选对专用类：不要用 Object2LongOpenHashMap 存 int→long 映射，它仍会装箱；必须用 Int2LongOpenHashMap
• 预设初始容量：像 new Int2LongOpenHashMap(1_000_000) 可避免多次扩容带来的数组复制和 rehash
• 启用引用相等（针对 Object 类型）：若 key 是不可变字符串且可接受 == 比较，调用 .useReferenceEquality()，跳过 equals() 字符串遍历
• 避免混用泛型擦除陷阱：IntArrayList 的 get(int) 返回 int，不是 Integer；但若误写成 list.get(i).intValue()，编译器会自动装箱再拆箱，白费功夫

实际效果不是理论数字

在量化交易系统中，将行情快照缓存从 ConcurrentHashMap 改为 Long2ObjectOpenHashMap 后：内存占用从 980 MB 降至 410 MB；单线程每秒处理 tick 数从 12 万提升到 31 万；Young GC 频率下降 76%。这不是微调，是架构级减负——尤其当你的服务每天处理上亿条原始数值时，那条“装箱/拆箱”路径，就是最该砍掉的冗余栈帧。

理论要掌握，实操不能落！以上关于《集合与原始类型差距：Trove vs fastutil 优化解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！