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对象,能根据对象的地址使用二分排序的算法快速定位到具体的方法。

时间: 2024-09-13 22:38:13

JVM源码分析之不保证顺序的Class.getMethods的相关文章

JVM源码分析之不可控的堆外内存

概述 之前写过篇文章,关于堆外内存的,JVM源码分析之堆外内存完全解读,里面重点讲了DirectByteBuffer的原理,但是今天碰到一个比较奇怪的问题,在设置了-XX:MaxDirectMemorySize=1G的前提下,然后统计所有DirectByteBuffer对象后面占用的内存达到了7G,远远超出阈值,这个问题很诡异,于是好好查了下原因,虽然最终发现是我们统计的问题,但是期间发现的其他一些问题还是值得分享一下的. 不得不提的DirectByteBuffer构造函数 打开DirectBy

JVM源码分析之一个Java进程究竟能创建多少线程

概述 虽然这篇文章的标题打着JVM源码分析的旗号,不过本文不仅仅从JVM源码角度来分析,更多的来自于Linux Kernel的源码分析,今天要说的是JVM里比较常见的一个问题 这个问题可能有几种表述 一个Java进程到底能创建多少线程? 到底有哪些因素决定了能创建多少线程? java.lang.OutOfMemoryError: unable to create new native thread的异常究竟是怎么回事 不过我这里先声明下可能不能完全百分百将各种因素都理出来,因为毕竟我不是做Lin

JVM源码分析之javaagent原理完全解读

前言 本系列文章都是基于Hotspot/JDK源码,从源码角度来分析我们常见的JVM参数,Java概念以及对应的实现原理及玩法等,希望从根本上来理清Java知识点,我们会不定期地分享这个系列的文章,这些文章可能源于最近碰到的问题,也可能是同学们的提问,甚至有可能是我们突然想到的话题等,有些东西我们现在可能也不一定清楚,但是我们非常愿意花时间去了解清楚并分享给大家. 概述 本文重点讲述javaagent的具体实现,因为它面向的是我们java程序员,而且agent都是用java编写的,不需要太多的c

JVM源码分析之谨防JDK8重复类定义造成的内存泄漏

概述 如今JDK8成了主流,大家都紧锣密鼓地进行着升级,享受着JDK8带来的各种便利,然而有时候升级并没有那么顺利?比如说今天要说的这个问题.我们都知道JDK8在内存模型上最大的改变是,放弃了Perm,迎来了Metaspace的时代.如果你对Metaspace还不熟,之前我写过一篇介绍Metaspace的文章,大家有兴趣的可以看看我前面的那篇文章. 我们之前一般在系统的JVM参数上都加了类似-XX:PermSize=256M -XX:MaxPermSize=256M的参数,升级到JDK8之后,因

JVM源码分析之Attach机制实现完全解读

Attach是什么 在讲这个之前,我们先来点大家都知道的东西,当我们感觉线程一直卡在某个地方,想知道卡在哪里,首先想到的是进行线程dump,而常用的命令是jstack ,我们就可以看到如下线程栈了 2014-06-18 12:56:14 Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode): "Attach Listener" daemon prio=5 tid=0x00007fb0c6800

JVM源码分析之SystemGC完全解读

概述 JVM的GC一般情况下是JVM本身根据一定的条件触发的,不过我们还是可以做一些人为的触发,比如通过jvmti做强制GC,通过System.gc触发,还可以通过jmap来触发等,针对每个场景其实我们都可以写篇文章来做一个介绍,本文重点介绍下System.gc的原理 或许大家已经知道如下相关的知识 system.gc其实是做一次full gc system.gc会暂停整个进程 system.gc一般情况下我们要禁掉,使用-XX:+DisableExplicitGC system.gc在cms

JVM源码分析之JDK8下的僵尸(无法回收)类加载器

概述 这篇文章基于最近在排查的一个问题,花了我们团队不少时间来排查这个问题,现象是有一些类加载器是作为key放到WeakHashMap里的,但是经历过多次full gc之后,依然坚挺地存在内存里,但是从代码上来说这些类加载器是应该被回收的,因为没有任何强引用可以到达这些类加载器了,于是我们做了内存dump,分析了下内存,发现除了一个WeakHashMap外并没有别的GC ROOT途径达到这些类加载器了,那这样一来经过多次FULL GC肯定是可以被回收的,但是事实却不是这样,为了让这个问题听起来更

JVM源码分析之Metaspace解密

概述 metaspace,顾名思义,元数据空间,专门用来存元数据的,它是jdk8里特有的数据结构用来替代perm,这块空间很有自己的特点,前段时间公司这块的问题太多了,主要是因为升级了中间件所致,看到大家讨论来讨论去,看得出很多人对metaspace还是模棱两可,不是很了解它,因此我觉得有必要写篇文章来介绍一下它,解开它神秘的面纱,当我们再次碰到它的相关问题的时候不会再感到束手无策. 通过这篇文章,你将可以了解到 为什么会有metaspace metaspace的组成 metaspace的VM参

JVM源码分析之临门一脚的OutOfMemoryError完全解读

概述 OutOfMemoryError,说的是java.lang.OutOfMemoryError,是JDK里自带的异常,顾名思义,说的就是内存溢出,当我们的系统内存严重不足的时候就会抛出这个异常(PS:注意这是一个Error,不是一个Exception,所以当我们要catch异常的时候要注意哦),这个异常说常见也常见,说不常见其实也见得不多,不过作为Java程序员至少应该都听过吧,如果你对jvm不是很熟,或者对OutOfMemoryError这个异常了解不是很深的话,这篇文章肯定还是可以给你带