怎么利用 String.intern() 减少在处理海量 Excel 单元格内容时的重复字符串内存开销

用 `String.intern()` 来降低海量 Excel 单元格中重复字符串的内存开销，这个思路很对，效果也确实显著。但这里有个关键前提：你得用对地方，用对方法。简单来说，它就是把你手里的字符串放进 JVM 的“字符串常量池”里（具体位置在堆外还是元空间，得看你的 JDK 版本），确保同一个内容的字符串在内存里只存一份。关键在于，哪里该用，哪里不该用。 ### 哪些单元格内容值得“常住”常量池？ Excel 里，有些字段天生就是“高频词”，重复率极高，比如： * **枚举值**：像“已发货”、“待审核”、“男”、“女”、“北京”、“上海”这类固定选项，翻来覆去就是那么几个。 * **表头名称**：“订单号”、“客户姓名”、“创建时间”这些，每行数据都带着。 * **标准化编码**：业务里用到的那些编码，比如“A001”、“B002”、“PROD-2024”，一套体系内的重复率很高。 * **协议或类型字面量**：像“HTTP”、“POST”、“UTF-8”、“xlsx”这类技术术语。 而像用户昵称、那种长文本的备注、随机生成的 ID，或者像 `"2024-05-22 14:30:45.123"` 这种带毫秒级时间戳的字符串，内容千差万别，重复率极低。**千万别**对它们用 `intern()`，不仅省不了多少内存，反而可能把常量池撑爆，给 GC 带来巨大压力，得不偿失。 ### 在 Apache POI 解析时，如何优雅地“按需 intern”？ 千万不要在读取每个单元格后，都立刻来一句 `cell.getStringCellValue().intern()`。这太粗暴了。更推荐的做法是分两步走： 1. **先扫一遍，看看谁最“活跃”**：用 `ConcurrentHashMap` 统计一下每个字符串出现的次数。设定一个阈值，比如“出现次数 >= 10 次”的，才进入候选名单。 2. **再扫一遍，只对“活跃分子”下手**：在第二遍解析时，只对命中候选名单的字符串调用 `string.intern()`。其他低频率的，该干嘛干嘛，保持原样引用就行。 3. **如果业务允许，更聪明的做法是“白名单”**：直接从数据库里把合法的“状态值”列表拉出来，形成一个白名单。解析时，只对命中白名单的字符串进行 intern。这相当于从源头就控制了范围。 ### 不同 JDK 版本下的“常量池”差异，得心里有数 从 JDK 7 开始，字符串常量池就搬到了堆内存里。这是个好消息，意味着 intern 后的字符串也受 GC 管理，不会再担心永久代（PermGen）溢出了。但，这并不意味着你可以高枕无忧： * **堆压力依然存在**：如果你频繁 intern 大量不同的字符串，它们会在老年代堆积，成为长期存活的“常住人口”，增加堆内存的压力。 * **并发“intern”有隐形成本**：`intern()` 方法本身是线程安全的，但内部的同步机制在高并发场景下会成为瓶颈。这时候，可以考虑自己动手实现一个轻量级的去重缓存，比如用 `ConcurrentHashMap::computeIfAbsent` 加一个自定义的字符串池，性能往往更可控。 * **验证效果，数据说话**：用 `jstat -gc ` 观察堆内字符串对象数量的变化，或者用 JFR、VisualVM 等工具进行可视化监控，看看你到底省了多少内存。 ### 更稳妥的“Plan B”：自己动手，丰衣足食 如果觉得 JVM 的全局常量池“水太深”，怕把控不住，那完全可以自己造一个更可控的“小池子”。用 `WeakHashMap` 来模拟 intern 的行为，是个不错的选择： ```ja va private static final Map STRING_POOL = Collections.synchronizedMap(new WeakHashMap<>()); public static String pool(String s) { if (s == null) return null; return STRING_POOL.computeIfAbsent(s, k -> k); } ``` 这种方式完全在你的掌控之中，不干扰 JVM 的常量池，而且 `WeakHashMap` 会自动清理掉那些已经没有强引用的字符串，对于业务层的精细化管理来说，既灵活又安全。