问题：使用 string.intern 可以节省时间吗，可以节省空间吗？
前段时间，迁移容器化之后发现机器的 youngGc 时间缓慢上涨，从几十毫秒涨到了几百毫秒，然后出发 full gc 之后，youngGc 时间又重新回落到几十毫秒
后来确定了是系统产生了很多的不同字符串的 key ，同时 jackSon 的 internCache 调用了 string.intern()方法，导致了字符串常量池 stringTable 膨胀，最终导致 YoungGc 扫描变慢
看了下美团技术团队里写道，fastJson 里使用了 string.intern,可以大大减少时间和空间，不太理解为什么可以节省时间，节省空间我能够理解，但是使用 string.intern ，不是更加的耗时吗？
tech.meituan.com/2014/03/06/in-depth-understanding-string-intern.html

你先了解下 intern 。
你的情况的慢是因为短时间内产生了大量不同的字符串进入了 table 。
美团说的是字符串 xxxx 在进入 table 后，以后相同字符串都不只产生一个对 table 内 xxxx 的引用，也就是说只有一个真正的字符串。内存节省了，gc 也快了。

美团那个文章不是有一节“＃＃＃＃3,fastjson 不当使用 String＃intern”？

我们遇到的就是这样的问题，接口传来了不同 Key 的 json ，反序列化导致了 stringTable 一直缓慢的膨胀

gc 为什么一定会变快呢，入参穿进来的字符串一定是一个新的字符串啊，一定需要被 gc 掉，如果使用 return string.intern()的话，这个入参会被 gc 掉，如果直接返回这个入参字符串的话，就相当于多占用了一份空间，在未来的某个时间可能会被 gc ，但是这两种情况都会有一个相同的垃圾需要被 gc ，也就是入参传进来的那个字符串

可能是我写的顺序有误，其实只是想说下之前遇到这个问题的背景，背景跟问题无关，我的意识并不是说为什么我用了 intern string 变慢了，但是官方说 string.intern 可以减少时间，我的问题只是想问，为什么 intern.string 作为缓存，减少耗时，变快

＃4 入参的对象只是一个字符串常量池的引用，intern 加速 GC 的含义也是这个，就算有一样的 String 对象，引用的也是这个常量池的地址。这样避免真实 String 对象（数组）被频繁创建、回收。从而达到缓存的目的，由于都是引用对象，因此 GC 非常快

还有 intern 耗时的问题，如果常量池已经有了，那么就会直接返回这个常量池对象的地址，不会执行放入常量池的操作

这个看代码注释就有，对于你的场景，太多的新的字符串对象被放入常量池，那么空间和时间效率都比较低

少分配，cache 命中高，对 object mapping 那种场景比较好，对 key 范围大的不好

我记得 HashMap 比较 Key 时会先比较 ref （地址），也是 intern 的优化场景

耗时相比起直接就返回入参的字符串，难道不是一定会更慢吗，但是节省了空间是一定的

这是 JackSon 的 intenCache 的源码，为什么入参的 input 你认为一定是一个字符串常量池的引用呢，如果假设现在的 json 串的 Key 是字符串“name”，我认为执行这个方法的入参的这个字符串 Input 对象，一定是一个新的，在堆区分配空间的字符串对象
public String intern(String input) {
String result = (String)this.get(input);
if (result != null) {
return result;
} else {
if (this.size() >= 180) {
synchronized(this.lock) {
if (this.size() >= 180) {
this.clear();
}
}
}

result = input.intern();
this.put(result, result);
return result;
}
}

Jackson 的 InternCache 默认只存 180 条，确定是这个导致的吗？

不是这个，是 string.intern()方法，导致字符串常量池里的 stringTable 缓存了过多的字符串，增加了 yougGC 的扫描耗时

＃13 发现看不懂这个 Cache 了...都必须要调用 string.intern()

参考这段 里面多了个 不 字我修正下
字符串 xxxx 在进入 table 后，以后相同字符串都只产生一个对 table 内 xxxx 的引用，也就是说只有一个真正的字符串。
虽然不太严谨，但是扫描和回收 10 个对象肯定比 10 引用慢。更何况这些引用可能绝大部分都是在方法内，在栈上，方法退出就释放了 都不涉及 gc

＃11 第三行这个 return result; 不是吗？ JDK 内部也有类似的实现，不过是 native 方法。这个 input 对象，第二次进来就是常量池的内存地址了，因为语言级别上已经也有这个机制

JDK8 上，String.intern 如果数据多了之后，查找非常慢，有非常大的性能问题。

从现象上看，突然有两个疑问点：
1 、YoungGC 变慢是扫描了全部的字符串常量池 ?
2 、YoungGC 无法回收字符串常量池里的 stringTable 缓存的字符串 ？

当 stringtable 里的字符串被复用的时候就节省时间了呗，intern() 不就是做这个的嘛。

对你说的 ygc 变慢是 intern()引起的说法存疑。

这个问题很多人遇到过

FullGc 会回收，但是 yougGc 不会，YoungGc 的确需要扫描字符串常量池