并行流本身不向字符串常量池写入内容，也不会自动触发intern()；其对常量池的压力仅源于显式调用intern()或未管控的重复字符串生成。
并行流本身不直接向字符串常量池（StringTable）写入内容，也不会自动触发 intern()；它对常量池的压力是间接的、可避免的——关键在于你是否在并行流中显式调用 intern()，或是否生成大量重复字符串对象后未加管控。
并行流拼接字符串 ≠ 自动入池
使用 parallelStream().map(...).collect(Collectors.joining()) 或 parallelStream().reduce(...) 拼接字符串时：
- 所有中间字符串（包括每个线程产生的临时拼接结果）都分配在堆内存中，不会进入字符串常量池；
- 最终结果是一个普通堆上
String对象，除非你手动调用.intern()，否则常量池完全不受影响； - 即使拼接内容高度重复（如 10 万个
"ERROR"），并行流也不会去查或存常量池——JVM 不会“自动驻留”运行时拼接出的字符串。
真正带来压力的两种典型场景
常量池压力只在以下情况发生，且与并行流的“并行性”无关，本质是 intern() 调用行为 + 高频重复字符串：
-
在并行流中对每个字符串调用
intern()：
例如list.parallelStream().map(s -> s.intern()).collect(toList())。此时每个线程都会尝试将字符串注册进常量池，引发：
– StringTable 哈希表争用（JDK 1.7+ 的 StringTable 是 synchronized 方法或 CAS 控制）；
– 如果字符串大量重复，多数intern()是查表返回已有引用，开销小；但若内容高度随机（如 UUID 字符串），则每调用一次都可能触发哈希桶扩容或链表遍历，拖慢吞吐； -
拼接后对大批量结果统一调用
intern()：
比如先用并行流生成 50 万条日志消息，再循环调用msg.intern()。这会造成：
– StringTable 快速膨胀（默认大小 JDK 1.8 是 60013 桶，可通过-XX:StringTableSize=120026调整）；
– 若未预估容量，频繁 rehash 会显著增加 GC 压力（尤其在老年代，因 intern 后的字符串引用长期存活）。
如何验证常量池是否承压
不靠猜测，用 JVM 工具实测：
- 启用统计：
-XX:+PrintStringTableStatistics -XX:+PrintGCDetails，运行后看 GC 日志末尾的StringTable行，关注size（当前桶数）、buckets（非空桶数）、entries（实际字符串数量）； - 监控增长：
jstat -gc <pid></pid>查看MC（元空间容量）和CCSC（压缩类空间）变化不大，但StringTableentries 暴涨，说明是 intern 导致； - 堆转储分析：用
jmap -dump:format=b,file=heap.hprof <pid></pid>+ VisualVM / Eclipse MAT，按java.lang.String分组，再看其value字段内容分布——若大量相同字符串对象共存（未被复用），说明intern()未生效或未调用。
优化建议：轻量、可控、按需
除非业务强依赖 == 判等（如状态码、协议关键字），否则应避免在并行流中滥用 intern()：
- 优先用
.equals()比较，它比==多一次 null 和 length 判断，但现代 JVM 早已内联优化，性能差距可忽略； - 若必须驻留，改用静态白名单预加载：
Set<string> KEYS = Set.of("SUCCESS", "FAILED", "PENDING").stream().map(String::intern).collect(Collectors.toSet());</string>，后续只对这有限集合做intern()； - 拼接本身尽量不用并行流：字符串拼接是内存拷贝密集型操作，并行反而因线程调度、StringBuilder 同步/分片合并引入额外开销；
Collectors.joining()单线程已足够高效； - 确需并行处理字符串且要驻留，考虑用
ConcurrentHashMap<string string></string>手动模拟轻量级池（putIfAbsent + 引用缓存），规避 StringTable 全局锁。
