通过Unsafe验证字符串常量池结构
引言
许多Java程序员都知道，在JVM中，字面量表示的字符串是一种特殊的对象，这些字符串被存储在堆中的一个叫做字符串常量池的哈希表结构中，由于字符串常量池是JVM虚拟机的一个组成部分，所以该哈希表是基于C++实现的。
在C++实现的hotspot VM中，实际上字符串常量池（即StringTable）的结构就是一个<char*,java_lang_String>的哈希表结构
当我们说String a="ab"时，实际上是在该哈希表中寻找键值为ab的键值对，当不存在时在该池中创建一个String对象，然后将该对象返回给引用a
当我们说String a=new String("ab")时，"ab"字面量仍然是遵循上述的步骤创建和/或返回了该String对象，但是在new String这一步，实际上new关键字在堆中创建了一个该对象的拷贝，并将拷贝对象返回给了引用a，因此此时引用a所指的String对象和字面量"ab"所指的对象是不等（!=）的。
出于这点考虑，Java在设计时规定了String的不可变性，即：
- String对象的Value是private final类型，不允许更改，且不提供访问Value的setter方法
- String对象本身是final的，防止其他类继承String后覆写String的value字段
通过Unsafe修改String的Value字段
String的内容是存放在内部的一个叫做value的byte数组中的，那么我们有没有办法去修改String的value字段呢？答案是可以借助Unsafe类来强行进行内存操作。
虽然从Java本身的语法上，我们没有任何办法操作String的value字段，但是Java核心库提供了一个Unsafe类，该类可以操作JVM中的内存数据，内存操作相关的方法是被声明为native的，即方法本身是基于其他语言（如C++）实现的。我们可以直接找到String对象的内存地址，找到value数组的偏移值，然后就可以对value数组直接进行内存读写了。
由于Unsafe类是核心库调用的，该类仅能被由BootstrapClassLoader加载的Java核心库实例化，在我们的Java程序中直接实例化会抛出SecurityException 异常。为了在Java中获取Unsafe对象，我们需要借助反射获取Unsafe中提供的theUnsafe单例对象:
import java.lang.reflect.Field;
import sun.misc.Unsafe;
private static Unsafe reflectGetUnsafe() {
try {
Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
return (Unsafe) field.get(null);
} catch (Exception e) {
return null;
}
}
在Unsafe类中提供了对象内存操作的相关方法：
/**
* Fetches a reference value from a given Java variable.
* @see #getInt(Object, long)
*/
@ForceInline
public Object getObject(Object o, long offset) {
return theInternalUnsafe.getReference(o, offset);
}
/**
* Stores a reference value into a given Java variable.
* <p>
* Unless the reference {@code x} being stored is either null
* or matches the field type, the results are undefined.
* If the reference {@code o} is non-null, card marks or
* other store barriers for that object (if the VM requires them)
* are updated.
* @see #putInt(Object, long, int)
*/
@ForceInline
public void putObject(Object o, long offset, Object x) {
theInternalUnsafe.putReference(o, offset, x);
}
这里着重考虑putObject(Object o, long offset, Object x)方法，该方法会获取对象o的内存地址起始值，并将地址为起始值+offset的数据（这里约定地址正确，且为引用数据类型）修改为对象x的引用
有了这个方法，我们就可以很轻松地修改一个String的value了
首先，通过反射获取String类中value字段的偏移值：
long offset=unsafe.objectFieldOffset(String.class.getDeclaredField("value"));
对于StringString b= "ab";，我们可以直接通过putObject修改b指向的String实例对象中value字段的内容：
unsafe.putObject(b,offset,new byte[]{'a','b','c'});
此时打印b，有：
System.out.println("b="+b); //b=abc
改变String带来的问题
在上面的基础上，我们设想如果我们修改了String的值有什么问题
修改new出来的String
在String a=new String("ab")时，a指向的对象是在常规堆中的String对象，实际上是字符串常量池中对应"ab"的String对象的拷贝。a指向的对象只对引用a负责，我们可以看如下例子：
Unsafe unsafe=reflectGetUnsafe();
assert unsafe!=null;
long offset=unsafe.objectFieldOffset(String.class.getDeclaredField("value"));
String a=new String("ab");
System.out.println("a="+a); //a=ab
unsafe.putObject(a,offset,new byte[]{'a','b','c'});
System.out.println("a="+a); //a=abc
String b= "ab";
System.out.println("b="+b); //b=ab
这里b的value没有被影响，因为a和b引用指向的实际上是两个不同的String对象，在我们没有通过unsafe修改String之前：
- a引用指向的是一个在常规堆中的String对象，其value为['a','b']
- a引用指向的是一个在常量池中的String对象，其value为['a','b']
修改字面量String
当我们将a修改为字面量赋值时，输出情况发生了变化：
String a="ab";
System.out.println("a="+a); //a=ab
unsafe.putObject(a,offset,new byte[]{'a','b','c'});
System.out.println("a="+a); //a=abc
String b= "ab";
System.out.println("b="+b); //b=abc
这里是因为此时a和b指向的对象是字符串常量池中的同一个String对象，当修改a指向String的内容时，b也随之被影响
String a="ab"从字符串常量池中寻找"ab"键值对应的String对象- 此时常量池中的键值对为<char[]{'a','b'},String(value=byte[]{'a','b'})>
unsafe.putObject(a,offset,new byte[]{'a','b','c'});修改了该对象中value的值为"abc"- 此时常量池中的键值对为<char[]{'a','b'},String(value=byte[]{'a','b','c'})>
String b= "ab";从字符串常量池中寻找"ab"键值对应的String对象- 此时b获取到了对象String(value=byte[]{'a','b','c'})
字符串常量池源码
oop StringTable::basic_add(int index_arg, Handle string, jchar* name,
int len, unsigned int hashValue_arg, TRAPS) {
assert(java_lang_String::equals(string(), name, len),
"string must be properly initialized");
// Cannot hit a safepoint in this function because the "this" pointer can move.
No_Safepoint_Verifier nsv;
// Check if the symbol table has been rehashed, if so, need to recalculate
// the hash value and index before second lookup.
unsigned int hashValue;
int index;
if (use_alternate_hashcode()) {
hashValue = hash_string(name, len);
index = hash_to_index(hashValue);
} else {
hashValue = hashValue_arg;
index = index_arg;
}
// Since look-up was done lock-free, we need to check if another
// thread beat us in the race to insert the symbol.
oop test = lookup(index, name, len, hashValue); // calls lookup(u1*, int)
if (test != NULL) {
// Entry already added
return test;
}
HashtableEntry<oop, mtSymbol>* entry = new_entry(hashValue, string());
add_entry(index, entry);
return string();
}
要注意jchar*是C++基于JNI（Java Native Interface），映射到JVM中char的数据结构，在JNI.h中可以发现JVM中数据类型的定义，其实是一系列不同位长的整数类型（https://github.com/luori366/JNI_doc）
typedef uint8_t jboolean; /* unsigned 8 bits，对应Java中的boolean*/ typedef int8_t jbyte; /* signed 8 bits，对应byte */ typedef uint16_t jchar; /* unsigned 16 bits，对应char */ typedef int16_t jshort; /* signed 16 bits，对应short */ typedef int32_t jint; /* signed 32 bits，对应int */ typedef int64_t jlong; /* signed 64 bits，对应long */ typedef float jfloat; /* 32-bit IEEE 754，对应float */ typedef double jdouble; /* 64-bit IEEE 754，对应double */
观察以上字符串常量池的源码可以发现在StringTable中添加键值对的一些细节
- StringTable接受一个类型为jchar*（可以近似认为为char*）的name参数，并根据该参数计算出hashcode
- 这里的name参数实际上就对应我们在Java中的字面量，即"ab"这部分
- StringTable根据计算出的hashcode在HashTable中找到对应的索引，并在索引处加入一个string对象（string()）
在源码的基础上理解，StringTable并不能保证键和值的对应性，在StringTable根据"ab"这个字面量计算出该键值对对应的索引后，就将其放在了相应的位置，在我们修改了String的value字段后，理论上用此时String.value重新计算一次hashcode会得出不一样的结果，并需要更新键值对的位置，但很明显，大家都知道相比随时监听String的对象的数据更改并更新哈希表，Java采用了一个更取巧的办法——将String对象设置为不可变。
总结
要注意的是，字符串常量池中，键的char数组，和值中String.value的byte数组是分离开的两个数组，也就是说，该哈希表中的对应关系是靠约定维持的，即"ab"->代表着"ab"的String对象
当我们修改了该对象的内容为"abc"时，实际上从语义上破坏了这个映射关系，即"ab"->代表着"abc"的String对象，此时再声明String b= "ab";就会从常量池中获取到错误的String对象
这也是为什么String对象不可变的根本原因，我们说为什么String不可变的原因是value字段是private final这一点仅仅是String不可变的直接原因，但是很多人并没有想过这么做的目的是什么。在上述实践后我们就知道，实际上String不可变是为了维持字符串常量池的这一层“脆弱”的语义关系
#Java##JVM##字符串常量池##Unsafe类##String#
投递理想汽车等公司10个岗位 >