編者按：筆者在處理業務線問題時遇到接口返回的內容和實際內容不一致的現象。根因是業務方通過Java反射機制將String類型敏感數據引用的value數組元素全部設置為'0'，從而實現清空用戶敏感數據的功能。這種清空用戶敏感數據的方法會將字符串常量池相應地址的內容修改，進而導致所有指向該地址的引用的內容和實際值不一致的現象。

背景知識

JVM為了提高性能和減少內存開銷，在實例化字符串常量時進行了優化。JVM在Java堆上開辟了一個字符串常量池空間（StringTable)，JVM通過ldc指令加載字符串常量時會調用 StringTable::intern 函數將字符串加入到字符串常量池中。

• StringTable::intern函數代碼

  oopStringTable::intern(Handlestring_or_null,jchar*name,
  intlen,TRAPS){
  unsignedinthashValue=hash_string(name,len);
  intindex=the_table()->hash_to_index(hashValue);
  oopfound_string=the_table()->lookup(index,name,len,hashValue);
  
  //Found
  if(found_string!=NULL){
  ensure_string_alive(found_string);
  returnfound_string;
  }
  
  debug_only(StableMemoryCheckersmc(name,len*sizeof(name[0])));
  assert(!Universe::heap()->is_in_reserved(name),
  "proposednameofsymbolmustbestable");
  
  Handlestring;
  //trytoreusethestringifpossible
  if(!string_or_null.is_null()){
  string=string_or_null;
  }else{
  string=java_lang_String::create_from_unicode(name,len,CHECK_NULL);
  }
  
  #ifINCLUDE_ALL_GCS
  if(G1StringDedup::is_enabled()){
  //Deduplicatethestringbeforeitisinterned.Notethatweshouldnever
  //deduplicateastringafterithasbeeninterned.Doingsowillcounteract
  //compileroptimizationsdoneone.g.internedstringliterals.
  G1StringDedup::deduplicate(string());
  }
  #endif
  
  //GrabtheStringTable_lockbeforegettingthe_table()becauseitcould
  //changeatsafepoint.
  oopadded_or_found;
  {
  MutexLockerml(StringTable_lock,THREAD);
  //Otherwise,addtosymboltotable
  added_or_found=the_table()->basic_add(index,string,name,len,
  hashValue,CHECK_NULL);
  }
  
  ensure_string_alive(added_or_found);
  
  returnadded_or_found;
  }
  
  

• StringTable::intern 函數處理流程

  

• 字符串的創建方式

  根據StringTable::intern函數處理流程，我們可以簡單描繪如下6種常見的字符串的創建方式以及引用關系。

現象

某業務線使用fastjson實現Java對象序列化功能，低概率出現接口返回的JSON數據的某個屬性值和實際值不一致的現象。正確的屬性值應該為"null"，實際屬性值卻為"0000"。

原因分析

為了排除fastjson自身的嫌疑，我們將其替換jackson后，依然會低概率出現同樣的現象。由于兩個不同三方件同時存在這個問題的可能性不大，為此我們暫時排除fastjson引入該問題的可能性。為了找到該問題的根因，我們在環境中開啟遠程調試功能。待問題復現，調試代碼時我們發現只要是指向"null"的引用，顯示的內容全部變成"0000"，由此我們初步懷疑字符串常量池中的"null"被修改成"0000"。

一般導致常量池被修改有兩種可能性：

1. 第三方動態庫引入的bug導致字符串常量池內容被修改；
2. 在業務代碼中通過Java反射機制主動修改字符串常量池內容；

業務方排查項目中使用到的第三方動態庫，未發現可疑的動態庫，排除第一種可能性。排查業務代碼中使用到Java反射的功能，發現清空密碼功能會使用到Java反射機制，并且將String類型密碼的value數組元素全部設置為'0'。

業務出現的現象可以簡單通過代碼模擬：

1. 在TestString對象類中定義一個nullStr屬性，初始值為"null"；
2. 定義一個帶有password屬性的User類；
3. 在main方法中創建一個密碼為"null"的User對象，使用Java反射機制將密碼字符串的所有字符全部修改為'0'，分別在密碼修改前后打印TestString對象nullStr屬性值；

復現代碼

importjava.lang.reflect.Field;
importjava.util.Arrays;

publicclassTestString{
privateStringnullStr="null";

publicStringgetNullStr(){
returnnullStr;
}

staticclassUser{
privatefinalStringpassword;

User(Stringpassword){
this.password=password;
}

publicStringgetPassword(){
returnpassword;
}
}

privatestaticvoidclearPassword(Useruser)throwsException{
Fieldfield=String.class.getDeclaredField("value");
field.setAccessible(true);
char[]chars=(char[])field.get(user.getPassword());
Arrays.fill(chars,'0');
}

publicstaticvoidmain(String[]args)throwsException{
Useruser=newUser("null");
TestStringtestString=newTestString();
System.out.println("beforeclearpassword>>>>");
System.out.println("User.password:"+user.getPassword());
System.out.println("TestString.nullStr:"+testString.getNullStr());
System.out.println("--------------------------------");
clearPassword(user);
System.out.println("afterclearpassword>>>>");
System.out.println("User.password:"+user.getPassword());
System.out.println("TestString.nullStr:"+testString.getNullStr());
}
}

復現代碼字符串引用關系如下圖所示。

輸出結果如下：

beforeclearpassword>>>>
User.password:null
TestString.nullStr:null
--------------------------------
afterclearpassword>>>>
User.password:0000
TestString.nullStr:0000

通過輸出結果我們可以發現在通過Java反射機制修改某一個字符串內容后，所有指向原字符串的引用的內容全部變成修改后的內容。

總結

在保存業務敏感數據時避免使用String類型保存，建議使用byte[]或char[]數組保存，然后通過Java反射機制清空敏感數據。

后記

如果遇到相關技術問題（包括不限于畢昇 JDK），可以通過 Compiler SIG 求助。Compiler SIG 每雙周周二舉行技術例會，同時有一個技術交流群討論 GCC、LLVM 和 JDK 等相關編譯技術，感興趣的同學可以添加如下微信小助手入群。