通过引入字符串常量池的概念，使用String.intern()方法来解决内存占用问题。具体实现包括自定义反序列化器以及重写HashMap的put方法。
首先明确项目中使用的fastjson序列化工具不会处理特定value的常量池。然后自定义反序列化器来调用intern方法，并找到适当的切点进行干预。最后通过重写HashMap的put方法来处理Map类型的成员value。
问题的本质在于低信息熵没有被很好地压缩。未来会从数据结构的设计上重新思考并解决这个问题。本次优化对实战和源码阅读都有收获。
这里一行代码，指的是：String.intern()的调用，为了调用这一行代码，也写了几十行额外的代码。
我们有一个项目，采用了全内存缓存机制。一方面是为了追求卓越的RT，另一方面是数据量确实很小，标准的4C8G容器处理起来绰绰有余。可是突然有一天，预发环境，疯狂报警FullGC，定位了一下原因，原来是这个缓存变得太大了。
我们通常会把数据量级在百条左右的配置项加载到内存里，近期一个新需求，导致配置数据量膨胀到了十万级，一口气加载到了内存里，自然造成了内存占用的上涨。但是，经过分析，这些数据的信息熵并不是很高。大面积的json其实是在存储有限种排列组合的字符串，但是这些字符串被反序列化框架以 new String 的方式重复加载到了堆空间内。突然想到了常量池这个概念，打算把它用起来，这样在不改变本次设计的情况下，可以无业务入侵地解决这个问题。首先明确，我们使用的fastjson序列化工具，是不会对“value”做常量池处理的。这也很好理解，因为正常情况下，value代表着无限可能，把每一个扑面而来的字符串都放到常量池内，显然会对系统带来更糟糕的影响。不过，我们很清楚自己的业务场景，特定value是有限的，不需要被Young GC的，因此，我们需要把这些特定的“value”，常量化，即显式调用 String.intern() 方法。说干就干，我们找到可以用来写 String.intern() 的“切点”。fastjson会使用恰当的 ObjectDeserializer 来反序列化一个字段，同时 @JSONField(deserializeUsing = xxx.class) 注解也给了我们自定义反序列化器的空间。因此，我们打算自定义一个反序列化器，来调用 intern 方法。public class StringPoolDeserializer implements ObjectDeserializer {
@SuppressWarnings("unchecked") @Override public T deserialze(DefaultJSONParser parser, Type type, Object o) {
if (!type.equals(String.class)) { throw new JSONException("StringPoolDeserializer can only deserialize String"); }
return (T) ((String) parser.parse(o)).intern(); }
@Override public int getFastMatchToken() { return 0; }}
经此优化，已经干掉了800M堆内存，并且元空间几乎没有上涨，毕竟我们的数据信息熵很低，都是重复的。
不过，剩余大小还是大于预期，后来发现，这个做法无法处理Map类型的成员里面的value。进一步，再看一下Map是如何被处理的。fastjson内部实现了 MapDeserializer 用来反序列化类型为Map的字段。不过这个反序列化器实现比较复杂，核心机制所在方法都被final修饰，不适合使用继承重写替换的方式解决问题。后来，发现代码里存在一条唯一的value。map的通路，我们可以通过干预map的类型，*重写对应的put方法，从而找到合适的 String.intern() 调用点。*p.s. 除put方法外，Map的 putAll, “compute家族”，甚至有参构造方法等，也有向Map添加元素的能力，他们并不复用put方法，而是复用一个被final关键字修饰的方法 ( putVal )。严格来说，由于无法重写 putVal方法，这些方法也应该被相应地重写，但考虑到 MapDeserializer 只调用了put方法，其余方法实现更复杂，故此只重写了put方法。
我的对策，直接重写put方法，简单粗暴。并且把这个StringPoolMap替换原来的JavaBean成员的HashMap类型声明：public class StringPoolMap extends HashMap<String, String> {
@Override public String put(String key, String value) { if (key != null) { key = key.intern(); } if (value != null) { value = value.intern(); } return super.put(key, value); }}
至此，能通过trick优化的地方已经全被优化掉了，内存占用从800M干到了619M，相较最初的1.6G+，成功干掉了1G的空间。
这个问题的本质，其实不是一个 String.intern() 的问题，而是低信息熵没有被很好地压缩。二期迭代，会从数据结构的设计上，重新思考并解决这个问题。本次优化，就当是把“八股”简单地在生产环境中实战一下，顺便读了读fastjson的源码，收获良多。
收获了入职以来最多的一次ATA上和大家的互动，受宠若惊，正好最近在读jdk（openjdk）源码，顺便展开一下吧。String.intern()实际上是一个native方法，表示的是：‒尝试把this放进一个池子里，如果里面内容相等的东西已经存在了，则返回那个已经存在的地址。
‒如果里面的东西不存在，则放进去，并返回新的地址。#include "jvm.h"#include "java_lang_String.h"
JNIEXPORT jobject JNICALLJava_java_lang_String_intern(JNIEnv *env, jobject this){ return JVM_InternString(env, this);}
里面实际上调用了一个 JVM_InternString，把this这个Object传了进去。#include "jvm.h"#include "java_lang_String.h"
JNIEXPORT jobject JNICALLJava_java_lang_String_intern(JNIEnv *env, jobject this){ return JVM_InternString(env, this);}
oop StringTable::intern(Handle string_or_null_h, const jchar* name, int len, TRAPS) { unsigned int hash = java_lang_String::hash_code(name, len);
oop found_string = lookup_shared(name, len, hash); if (found_string != nullptr) { return found_string; } if (_alt_hash) { hash = hash_string(name, len, true); } found_string = do_lookup(name, len, hash); if (found_string != nullptr) { return found_string; }
return do_intern(string_or_null_h, name, len, hash, THREAD);}
