阿里妹导读
这里一行代码,指的是: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堆内存,并且元空间几乎没有上涨,毕竟我们的数据信息熵很低,都是重复的。
不过,剩余大小还是大于预期,后来发现,这个做法无法处理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方法。
我的对策,直接重写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 JNICALL``Java_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 JNICALL``Java_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上的网站静态文件,不仅可以降低源站的负载压力,还能够提升网站的访问性能,同时还能在高并发场景下为您节约成本。快点击阅读原文查看详情。