JVM源碼分析之不保證順序的Class.getMethods

概述

本文要說的內容是今天公司有個線上係統踩了一個坑，並且貌似還造成了一定的影響，後來係統相關的人定位到了是java.lang.Class.getMethods返回的順序可能不同機器不一樣，有問題的機器和沒問題的機器這個返回的方法列表是不一樣的，後麵他們就來找到我求證是否jdk裏有這潛規則

本來這個問題簡單一句話就可以說明白，所以在晚上推送的消息裏也將這個事實告訴了大家，大家知道就好，以後不要再掉到坑裏去了，但是這個要細說起來其實也值得一說，於是在消息就附加了征求大家意見的內容，看大家是否有興趣或者是否踩到過此坑，沒想到有這麼多人響應，表示對這個話題很感興趣，並且總結了大家問得最多的兩個問題是

• 為什麼有代碼需要依賴這個順序

• jvm裏為什麼不保證順序

那這篇文章主要就針對這兩個問題展開說一下，另外以後針對此類可寫可不寫的文章先征求下大家的意見再來寫可能效果會更好點，一來可以回答大家的一些疑問（當然有些問題我也可能回答不上來，不過我盡量去通讀代碼回答好大家），二來希望對我公眾號裏的文章繼續保持不求最多，隻求最精的態度。

為了不辜負大家的熱情，我連夜趕寫了這篇文章，如果大家覺得我寫的這些文章對大家有幫助，希望您能將文章分享出去，同時將我的公眾號你假笨推薦給您身邊更多的技術人，能幫助到更多的人去了解更多的細節，在下在此先謝過。

依賴順序的場景

如果大家看過或者實現過序列化反序列化的代碼，這個問題就不難回答了，今天碰到的這個問題其實是發生在大家可能最常用的fastjson庫裏的，所以如果大家在使用這個庫，請務必檢查下你的代碼，以免踩到此坑

對象序列化

大家都知道當我們序列化好一個對象之後，要反序列回來，那問題就來了，就拿這個json序列化來說吧，我們要將對象序列化成json串，那意味著我們要先取出這個對象的屬性，然後寫成鍵值對的形式，那取值就意味著我們要遵循java bean的規範通過getter方法來取，那其實getter方法有兩種，一種是boolean類型的，一種是其他類型的，如果是boolean類型的，那我們通常是isXXX()這樣的方法，如果是其他類型的，一般是getXXX()這樣的方法。那假如說我們的類裏針對某個屬性a，同時存在兩個方法isA()和getA()，那究竟我們會調用哪個來取值？這個就取決於具體的序列化框架實現了，比如導致我們這篇文章誕生的fastjson，就是利用我們這篇文章的主角java.lang.Class.getMethods返回的數組，然後挨個遍曆，先找到哪個就是哪個，如果我們的這個數組正好因為jvm本身實現沒有保證順序，那麼可能先找到isA()，也可能先找到getA()，如果兩個方法都是返回a這個屬性其實問題也不大，假如正好是這兩個方法返回不同的內容呢？

private A a;public A getA(){    return a;
}public boolean isA(){    return false;
}public void setA(A a){    this.a=a;
}

如果是上麵的內容，那可能就會悲劇了，如果選了isA()，那其實是返回一個boolean類型的，將這個boolean寫入到json串裏，如果是選了getA()，那就是將A這個類型的對象寫到json串裏

對象反序列化

在完成了序列化過程之後，需要將這個字符串進行反序列化了，於是就會去找json串裏對應字段的setter方法，比如上麵的setA(A a)，假如我們之前選了isA()序列化好內容，那我們此時的值是一個boolean值false，那就無法通過setA來賦值還原對象了。

解決方案

相信大家看完我上麵的描述，知道這個問題所在了，要避免類似的問題，方案其實也挺多，比如對方法進行先排序，又比如說優先使用isXXX()方法，不過這種需要和開發者達成共識，和setter要對應得起來

jvm裏為什麼不保證順序

JDK層麵的代碼我就暫時不說了，大家都能看到代碼，從java.lang.Class.getMethods一層層走下去，相信大家細心點還是能抓住整個脈絡的，我這裏主要想說大家可能比較難看到的一些實現，比如JVM裏的具體實現

正常情況下大家跟代碼能跟到調用了java.lang.Class.getDeclaredMethods0這個native方法，其具體實現如下

JVM_ENTRY(jobjectArray, JVM_GetClassDeclaredMethods(JNIEnv *env, jclass ofClass, jboolean publicOnly))
{
  JVMWrapper("JVM_GetClassDeclaredMethods");  return get_class_declared_methods_helper(env, ofClass, publicOnly,                                           /*want_constructor*/ false,
                                           SystemDictionary::reflect_Method_klass(), THREAD);
}
JVM_END

其主要調用了get_class_declared_methods_helper方法

static jobjectArray get_class_declared_methods_helper(
                                  JNIEnv *env,
                                  jclass ofClass, jboolean publicOnly,
                                  bool want_constructor,
                                  Klass* klass, TRAPS) {

  JvmtiVMObjectAllocEventCollector oam;  // Exclude primitive types and array types
  if (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(ofClass))
      || java_lang_Class::as_Klass(JNIHandles::resolve_non_null(ofClass))->oop_is_array()) {    // Return empty array
    oop res = oopFactory::new_objArray(klass, 0, CHECK_NULL);    return (jobjectArray) JNIHandles::make_local(env, res);
  }  instanceKlassHandle k(THREAD, java_lang_Class::as_Klass(JNIHandles::resolve_non_null(ofClass)));  // Ensure class is linked
  k->link_class(CHECK_NULL);

  Array<Method*>* methods = k->methods();  int methods_length = methods->length();  // Save original method_idnum in case of redefinition, which can change
  // the idnum of obsolete methods.  The new method will have the same idnum
  // but if we refresh the methods array, the counts will be wrong.
  ResourceMark rm(THREAD);
  GrowableArray<int>* idnums = new GrowableArray<int>(methods_length);  int num_methods = 0;  for (int i = 0; i < methods_length; i++) {    methodHandle method(THREAD, methods->at(i));    if (select_method(method, want_constructor)) {      if (!publicOnly || method->is_public()) {
        idnums->push(method->method_idnum());
        ++num_methods;
      }
    }
  }  // Allocate result
  objArrayOop r = oopFactory::new_objArray(klass, num_methods, CHECK_NULL);  objArrayHandle result (THREAD, r);  // Now just put the methods that we selected above, but go by their idnum
  // in case of redefinition.  The methods can be redefined at any safepoint,
  // so above when allocating the oop array and below when creating reflect
  // objects.
  for (int i = 0; i < num_methods; i++) {    methodHandle method(THREAD, k->method_with_idnum(idnums->at(i)));    if (method.is_null()) {      // Method may have been deleted and seems this API can handle null
      // Otherwise should probably put a method that throws NSME
      result->obj_at_put(i, NULL);
    } else {
      oop m;      if (want_constructor) {
        m = Reflection::new_constructor(method, CHECK_NULL);
      } else {
        m = Reflection::new_method(method, UseNewReflection, false, CHECK_NULL);
      }
      result->obj_at_put(i, m);
    }
  }  return (jobjectArray) JNIHandles::make_local(env, result());
}

從上麵的k->method_with_idnum(idnums->at(i)),我們基本知道方法主要是從klass裏來的

Method* InstanceKlass::method_with_idnum(int idnum) {
  Method* m = NULL;  if (idnum < methods()->length()) {
    m = methods()->at(idnum);
  }  if (m == NULL || m->method_idnum() != idnum) {    for (int index = 0; index < methods()->length(); ++index) {
      m = methods()->at(index);      if (m->method_idnum() == idnum) {        return m;
      }
    }    // None found, return null for the caller to handle.
    return NULL;
  }  return m;
}

因此InstanceKlass裏的methods是關鍵，而這個methods的創建是在類解析的時候發生的

instanceKlassHandle ClassFileParser::parseClassFile(Symbol* name,
                                                    ClassLoaderData* loader_data,
                                                    Handle protection_domain,
                                                    KlassHandle host_klass,
                                                    GrowableArray<Handle>* cp_patches,
                                                    TempNewSymbol& parsed_name,
                                                    bool verify,
                                                    TRAPS) {


...
 Array<Method*>* methods = parse_methods(access_flags.is_interface(),
                                            &promoted_flags,
                                            &has_final_method,
                                            &declares_default_methods,

...                                            CHECK_(nullHandle));// sort methodsintArray* method_ordering = sort_methods(methods); 
...
this_klass->set_methods(_methods);
...
}

上麵的parse_methods就是從class文件裏挨個解析出method，並存到_methods字段裏，但是接下來做了一次sort_methods的動作，這個動作會對解析出來的方法做排序

intArray* ClassFileParser::sort_methods(Array<Method*>* methods) {  int length = methods->length();  // If JVMTI original method ordering or sharing is enabled we have to
  // remember the original class file ordering.
  // We temporarily use the vtable_index field in the Method* to store the
  // class file index, so we can read in after calling qsort.
  // Put the method ordering in the shared archive.
  if (JvmtiExport::can_maintain_original_method_order() || DumpSharedSpaces) {    for (int index = 0; index < length; index++) {
      Method* m = methods->at(index);      assert(!m->valid_vtable_index(), "vtable index should not be set");
      m->set_vtable_index(index);
    }
  }  // Sort method array by ascending method name (for faster lookups & vtable construction)
  // Note that the ordering is not alphabetical, see Symbol::fast_compare
  Method::sort_methods(methods);

  intArray* method_ordering = NULL;  // If JVMTI original method ordering or sharing is enabled construct int
  // array remembering the original ordering
  if (JvmtiExport::can_maintain_original_method_order() || DumpSharedSpaces) {
    method_ordering = new intArray(length);    for (int index = 0; index < length; index++) {
      Method* m = methods->at(index);      int old_index = m->vtable_index();      assert(old_index >= 0 && old_index < length, "invalid method index");
      method_ordering->at_put(index, old_index);
      m->set_vtable_index(Method::invalid_vtable_index);
    }
  }  return method_ordering;
}// This is only done during class loading, so it is OK to assume method_idnum matches the methods() array// default_methods also uses this without the ordering for fast find_methodvoid Method::sort_methods(Array<Method*>* methods, bool idempotent, bool set_idnums) {  int length = methods->length();  if (length > 1) {
    {
      No_Safepoint_Verifier nsv;
      QuickSort::sort<Method*>(methods->data(), length, method_comparator, idempotent);
    }    // Reset method ordering
    if (set_idnums) {      for (int i = 0; i < length; i++) {
        Method* m = methods->at(i);
        m->set_method_idnum(i);
        m->set_orig_method_idnum(i);
      }
    }
  }
}

從上麵的Method::sort_methods可以看出其實具體的排序算法是method_comparator

// Comparer for sorting an object array containing// Method*s.static int method_comparator(Method* a, Method* b) {  return a->name()->fast_compare(b->name());
}

比較的是兩個方法的名字，但是這個名字不是一個字符串，而是一個Symbol對象，每個類或者方法名字都會對應一個Symbol對象，在這個名字第一次使用的時候構建，並且不是在java heap裏分配的，比如jdk7裏就是在c heap裏通過malloc來分配的，jdk8裏會在metaspace裏分配

// Note: this comparison is used for vtable sorting only; it doesn't matter// what order it defines, as long as it is a total, time-invariant order// Since Symbol*s are in C_HEAP, their relative order in memory never changes,// so use address comparison for speedint Symbol::fast_compare(Symbol* other) const { return (((uintptr_t)this < (uintptr_t)other) ? -1
   : ((uintptr_t)this == (uintptr_t) other) ? 0 : 1);
}

從上麵的fast_compare方法知道，其實對比的是地址的大小，因為Symbol對象是通過malloc來分配的，因此新分配的Symbol對象的地址就不一定比後分配的Symbol對象地址小，也不一定大，因為期間存在內存free的動作，那地址是不會一直線性變化的，之所以不按照字母排序，主要還是為了速度考慮，根據地址排序是最快的。

綜上所述，一個類裏的方法經過排序之後，順序可能會不一樣，取決於方法名對應的Symbol對象的地址的先後順序

JVM為什麼要對方法排序

其實這個問題很簡單，就是為了快速找到方法呢，當我們要找某個名字的方法的時候，根據對應的Symbol對象，能根據對象的地址使用二分排序的算法快速定位到具體的方法。