一行代码, 我优化掉了1G内存占用

阿里妹导读

这里一行代码，指的是：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 { @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的源码，收获良多。

多写一点，String.intern的实现

收获了入职以来最多的一次ATA上和大家的互动，受宠若惊，正好最近在读jdk（openjdk）源码，顺便展开一下吧。

String.intern实际上是一个native方法，表示的是：

?尝试把this放进一个池子里，如果里面内容相等的东西已经存在了，则返回那个已经存在的地址。

?如果里面的东西不存在，则放进去，并返回新的地址。

找一下对应的源码：

String.intern对应的C源码

#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传了进去。

JVM_InternString

#include "jvm.h"#include "java_lang_String.h"JNIEXPORT jobject JNICALLJava_java_lang_String_intern(JNIEnv *env, jobject this){ return JVM_InternString(env, this);}

StringTable

oop StringTable::intern(Handle string_or_null_h, const jchar* name, int len, TRAPS) { unsigned int hash = java_lang_String::hash_code(name, len); // 分别在shared table 和local table中查找有无存在的string // 找到则快速返回 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);}