ReaderMX.
阿里开发者

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

阿金尚衡约 5 分钟
Image

阿里妹导读

这里一行代码，指的是：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> 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堆内存，并且元空间几乎没有上涨，毕竟我们的数据信息熵很低，都是重复的。

Image

不过，剩余大小还是大于预期，后来发现，这个做法无法处理Map<String, String>类型的成员里面的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方法。
Image
我的对策，直接重写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的源码，收获良多。

多写一点，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);}

网站静态资源访问加速

本方案使用阿里云CDN产品来分发OSS上的网站静态文件，不仅可以降低源站的负载压力，还能够提升网站的访问性能，同时还能在高并发场景下为您节约成本。快点击阅读原文查看详情。

KEEP THE THREAD GOING

更多来源文章