java集合框架不支持原始类型，需装箱导致cpu和gc开销；fastutil通过数组直存原始值解决，且持续维护、支持64位、接口兼容、功能丰富，实测显著提升性能与内存效率。
Java 的集合框架天生不支持原始类型，所有基本类型（int、long、double 等）都必须包装成对象（Integer、Long、Double）才能存入 ArrayList 或 HashMap。这带来两个硬伤：频繁装箱拆箱消耗 CPU，大量小对象加重 GC 压力。Trove 和 FastUtil 就是为填平这道鸿沟而生的——它们不是“增强”，而是从底层重写，用数组直存原始值。
为什么装箱是性能黑洞
每次往 HashMap<integer long></integer> 插入一个键值对，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<integer long></integer>存 int→long 映射，它仍会装箱；必须用Int2LongOpenHashMap - 预设初始容量：像
new Int2LongOpenHashMap(1_000_000)可避免多次扩容带来的数组复制和 rehash - 启用引用相等（针对 Object 类型）：若 key 是不可变字符串且可接受
==比较，调用.useReferenceEquality()，跳过equals()字符串遍历 - 避免混用泛型擦除陷阱：
IntArrayList的get(int)返回int，不是Integer；但若误写成list.get(i).intValue()，编译器会自动装箱再拆箱，白费功夫
实际效果不是理论数字
在量化交易系统中，将行情快照缓存从 ConcurrentHashMap<long tick></long> 改为 Long2ObjectOpenHashMap<tick></tick> 后：内存占用从 980 MB 降至 410 MB；单线程每秒处理 tick 数从 12 万提升到 31 万；Young GC 频率下降 76%。这不是微调，是架构级减负——尤其当你的服务每天处理上亿条原始数值时，那条“装箱/拆箱”路径，就是最该砍掉的冗余栈帧。
