反射调用触发NoSuchMethodException，求排查方案（Specification模式场景）

接手别人的代码遇到这种反射异常确实闹心，尤其是明明觉得构造方法应该存在的时候。结合你用Specification模式构建SearchCriteria的场景，给你几个具体的排查点：

• 精确核对构造方法的参数类型与顺序
  别想当然以为参数对得上，一定要打开对应的Specification类源码仔细看：

  • 是不是SearchCriteria的全类名和你反射时用的完全一致？比如有没有可能是com.xxx.SearchCriteria vs com.xxx.search.SearchCriteria这种包路径差异？
  • 构造方法的参数顺序是不是和你反射调用的(SearchCriteria.class, String[].class)完全一致？比如有没有被写成(String[], SearchCriteria)？
  • 参数类型是不是严格匹配？比如构造方法用的是List<String>而不是String[]，或者是SearchCriteria的子类（比如AdvancedSearchCriteria），反射时父类类型是匹配不到子类参数的构造方法的。

• 检查构造方法的访问权限与类加载器问题

  • 虽然getDeclaredConstructor能访问私有构造方法，但如果目标类的构造方法是default权限（包私有），而你的反射代码在不同包下，有没有可能因为模块权限（比如Java Module系统）导致无法访问？不过这种情况通常会抛出IllegalAccessException，但也可以排查下。
  • 类加载器冲突是容易忽略的点：如果你的REST服务是多模块架构，clazzSpec和SearchCriteria可能被不同的类加载器加载，这时候JVM会认为它们是不同的类，自然找不到对应构造方法。可以打印两个类的类加载器信息对比：

    System.out.println("clazzSpec class loader: " + clazzSpec.getClassLoader());
    System.out.println("SearchCriteria class loader: " + SearchCriteria.class.getClassLoader());
    

• 打印目标类的所有构造方法，直观对比
  最直接的方式就是把目标类的所有构造方法都打印出来，看看有没有你要找的那个：

  Constructor<?>[] allConstructors = clazzSpec.getDeclaredConstructors();
  for (Constructor<?> constructor : allConstructors) {
      // 打印构造方法的完整签名，包括参数类型
      System.out.println("Found constructor: " + constructor.toGenericString());
  }
  

  运行这段调试代码后，就能清楚看到实际存在的构造方法签名，和你反射调用的对比，差异一目了然。

• 排查动态加载类的逻辑是否有遗漏
  因为你是做通用搜索引擎，可能会动态加载多个Specification类，有没有可能某个类根本就没有定义这个构造方法？比如有些老的Specification类是用其他方式初始化的，没有适配这个通用的构造方法签名？

内容的提问来源于stack exchange，提问作者Jim C