字符串对象为何成为内存优化的目标
在内存敏感的大数据应用中，字符串对象往往占据堆内存的很大比例。JEP 192 的测量数据显示，在大型 Java 应用中，String 对象约占堆活跃数据的 25%，其中约一半是重复的（即 string1.equals(string2) 为真）。这些重复对象本质上是内存的浪费。例如，在日志分析场景中，大量日志消息包含相同的时间戳、日志级别或错误码字符串，每个字符串对象都持有一个独立的字符数组，导致内存被重复占用。
字符串去重的目标是减少这种浪费。它通过让多个 String 对象共享同一个字符数组（char[] value）来实现。由于 String 类的 value 字段是 final 的，且 String 类不会修改数组内容，因此多个 String 对象可以安全地共享同一个数组。去重操作只是将 aString.value 重新赋值为 anotherString.value，但这一赋值由 JVM 在内部完成，对 Java 应用透明。
需要注意的是，字符串去重并不去重 String 对象本身，而是去重其背后的字符数组。这是因为 String 对象的身份（identity）可能被应用用于同步或依赖，改变对象本身会破坏 Java 语义。
去重候选的识别与年龄阈值
去重候选的识别发生在 GC 的年轻代回收（young collection）和混合回收（mixed collection）期间，这是一个性能敏感的操作，因为它会应用于所有被访问的对象。一个对象被视为去重候选，需要满足以下条件：
- 对象是
String的实例。 - 对象正在从年轻代区域被疏散（evacuated）。
- 对象被疏散到年轻代/幸存者区域时，其年龄等于去重年龄阈值；或者被疏散到老年代区域时，其年龄小于去重年龄阈值。
一旦 String 对象被提升到老年代，或者其年龄超过阈值，它就不会再成为候选。这种设计避免了同一对象被重复处理。
去重年龄阈值由 -XX:StringDeduplicationAgeThreshold 参数控制，默认值在 JEP 192 中未明确给出，但通常为 3。该参数基于一个假设：String 对象要么生命周期很短，要么很长。对即将死亡的对象进行去重是浪费 CPU 和内存资源的。因此，阈值确保只有存活了足够久的字符串才被考虑去重。
Interned 字符串（通过 String.intern() 加入字符串表的字符串）比较特殊。它们在插入 StringTable 之前会被显式去重，之后如果达到年龄阈值或被疏散到老年代，仍可能再次成为候选。第二次去重是徒劳的，但无法快速过滤，不过由于 interned 字符串的数量通常远小于普通字符串，这不是问题。
去重队列与哈希表结构
去重队列实际上由多个队列组成，每个 GC 工作线程一个。这种设计允许 GC 工作线程在 stop-the-world 阶段进行无锁且缓存友好的入队操作。当 GC 访问对象时，如果对象被识别为候选，就将其引用插入到对应的队列中。
一个后台去重线程（deduplication thread）持续处理队列。处理过程包括：从队列中取出引用，尝试去重该 String 对象。去重的核心是查找一个哈希表，该表记录了堆上所有唯一的字符数组。
哈希表的结构是去重性能的关键。它需要支持高效的查找和插入操作，并且要处理并发访问。去重线程是唯一的写入者，但 GC 线程可能在 stop-the-world 阶段访问表（例如在年轻代回收时，需要将新字符数组插入表）。因此，哈希表的并发控制需要仔细设计。
在 JEP 192 的实现中，哈希表使用了一种类似于 ConcurrentHashMap 的结构，但具体细节未公开。工程上通常采用分段锁或 CAS 操作来减少竞争。
并发去重与 SATB 的交互
G1 GC 使用 SATB（Snapshot-At-The-Beginning）算法进行并发标记。SATB 确保在标记开始时存活的对象在标记结束时仍被视为存活，即使它们在标记期间被修改。字符串去重与 SATB 的交互主要体现在：去重线程修改 String 对象的 value 字段，这可能会影响标记的准确性。
SATB 算法通过在标记开始时记录堆的快照，并在标记过程中跟踪所有引用变化，来避免漏标。当去重线程将 aString.value 从数组 A 改为数组 B 时，SATB 会记录这个变化，确保 A 和 B 在标记期间都被视为存活。这可能导致一些本应被回收的数组被保留，但这是为了保持标记的一致性。
去重线程与 GC 的并发执行需要协调。去重线程在操作哈希表时，需要避免与 GC 的并发操作冲突。例如，在年轻代回收期间，GC 可能正在移动对象，去重线程不能同时访问这些对象。因此，去重线程在 GC 的某些阶段需要暂停或同步。
JEP 192 提到，去重线程在 GC 期间会与 safepoint 同步，以避免干扰 GC 操作。但在 JDK-8158871 的修复中，去重线程不再加入 safepoint 同步，以避免延迟 safepoint。这意味着去重线程可以在 GC 期间继续运行，但需要更精细的同步机制来保证安全。
参数配置与默认行为
启用字符串去重需要两个参数：-XX:+UseStringDeduplication 和 -XX:StringDeduplicationAgeThreshold。前者启用功能，后者设置年龄阈值。
在 JDK 8u20 及以后版本中，-XX:+UseStringDeduplication 默认是关闭的。用户需要显式启用。年龄阈值的默认值在 JEP 192 中未明确，但通常为 3。
启用后，GC 会在每次年轻代回收时识别候选，并将它们加入队列。去重线程在后台处理队列，更新哈希表。
值得注意的是，字符串去重只适用于 G1 GC，其他垃圾收集器（如 Parallel GC、CMS）不支持。此外，字符串去重与 JEP 254（Compact Strings）相关，后者将字符数组改为字节数组，但去重机制仍然适用。
性能影响与权衡
字符串去重的主要收益是减少堆内存占用。JEP 192 的测量显示，平均可以减少约 10% 的堆活跃数据。但具体应用差异很大，某些应用可能收益更高，某些可能几乎没有。
代价是 CPU 开销。去重线程需要处理队列、查找和更新哈希表，这会消耗 CPU 资源。在 CPU 密集型应用中，这可能导致吞吐量下降。此外，哈希表的维护需要额外内存，但通常远小于节省的内存。
去重线程的并发处理可能影响 GC 停顿时间。虽然去重线程在后台运行，但它在 GC 期间需要与 GC 协调，可能增加停顿时间。JDK-8158871 的修复就是为了减少去重线程对 safepoint 的延迟影响。
与替代方案相比，字符串去重是一种自动化的优化，无需修改代码。另一种方案是使用 String.intern() 手动去重，但 intern 方法可能引入字符串表锁竞争，并且需要程序员识别重复字符串。字符串去重则自动处理，但无法控制哪些字符串被去重。
生产环境中的诊断与调优
在生产环境中，是否启用字符串去重需要评估内存收益和 CPU 开销。可以通过以下步骤判断：
- 使用 JFR（Java Flight Recorder）或 GC 日志监控堆内存使用情况，特别是字符串对象占用的比例。
- 如果字符串对象占用超过 20% 且存在大量重复，可以考虑启用去重。
- 启用后，监控 CPU 使用率和 GC 停顿时间。如果 CPU 开销显著增加或停顿时间恶化，可能需要调整年龄阈值或关闭去重。
可观测信号包括：GC 日志中的去重统计（如去重数量、哈希表大小）、JFR 事件（如 StringDeduplication）。
常见失败模式包括：
- 去重线程导致 safepoint 延迟：在 JDK 8 的早期版本中，去重线程删除哈希表条目时可能长时间占用 safepoint，导致应用停顿。JDK-8158871 修复了这个问题，通过引入溢出列表和缓存，将删除操作延迟，避免阻塞 safepoint。
- 哈希表过大：如果应用有大量唯一字符串，哈希表可能占用大量内存，抵消去重收益。
- CPU 开销过高：在低延迟应用中，去重线程的 CPU 消耗可能影响响应时间。
结论与适用边界
字符串去重是 G1 GC 提供的一项自动内存优化，适合内存敏感且存在大量重复字符串的应用。它通过共享字符数组减少堆占用，但引入了 CPU 开销和潜在的停顿影响。
适用场景：
- 堆内存紧张，且字符串对象占比高。
- 应用有大量重复字符串（如日志、缓存键）。
不适用场景：
- CPU 资源紧张，无法容忍额外开销。
- 应用字符串对象数量少或唯一性强。
- 使用非 G1 GC。
在决定启用前，应通过监控数据评估潜在收益和成本。字符串去重不是银弹，但合理使用可以显著降低内存压力。
对比表格
| 方案 | 内存收益 | CPU开销 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| 字符串去重 | 平均约10%堆减少 | 中（后台线程） | 低（自动） | 大量重复字符串 |
| String.intern() | 取决于手动使用 | 低到中（字符串表锁竞争） | 高（需修改代码） | 已知重复且可控的字符串 |
| 不优化 | 无 | 无 | 无 | 内存充足或字符串占比低 |
Mermaid 流程图
flowchart TD
A[GC年轻代回收] --> B{对象是String?}
B -- 否 --> A
B -- 是 --> C{年龄达到阈值?}
C -- 否 --> A
C -- 是 --> D[将引用加入去重队列]
D --> E[去重线程取出引用]
E --> F{在哈希表中查找字符数组?}
F -- 找到 --> G[String.value指向已有数组]
F -- 未找到 --> H[将字符数组插入哈希表]
G --> I[释放原数组引用]
H --> I
I --> J[原数组可被回收]
该流程图展示了字符串去重的完整流程：GC 识别候选，去重线程处理，哈希表查找或插入，最终释放原数组。关键转折点在于年龄阈值判断和哈希表查找结果。