Hibernate中出现未知HashMap来源的ClassCastException问题排查

我之前也踩过类似的坑，这种看起来“逻辑上完全没问题”的类型转换异常，往往藏着容易被忽略的细节，咱们一步步拆解排查：

• 先确认DAO方法的真实返回类型
  别光看方法签名，实际运行时可能因为泛型擦除、框架动态代理或者方法内部实现的小疏漏，返回的并不是你以为的ArrayList<Object[]>。可以在调用后加几行调试代码，直接打印真实类型：

  System.out.println("集合类型：" + queryList.getClass());
  if (!queryList.isEmpty()) {
      System.out.println("第一个元素类型：" + queryList.get(0).getClass());
  }
  

  说不定方法内部偷偷返回了List<List<Object>>，或者把单个Object包装成了列表，这时候强转List<Object[]>自然会报错。

• 检查ORM框架的结果映射逻辑
  如果用了Hibernate、MyBatis这类框架，queryGenericArray的实现可能没处理好结果映射。比如有些框架默认会把单行查询结果映射成实体类，而不是Object[]；或者当查询字段是数据库特殊类型（比如JSON、枚举）时，框架自动映射成了自定义对象，导致列表元素不是预期的Object[]。

• 警惕泛型类型擦除的坑
  Java泛型是编译时检查，运行时会被擦除。如果DAO方法是通过反射、动态代理实现的，返回的可能是原始类型List，你强转成List<Object[]>时编译不会报错，但后续遍历取元素时，JVM发现实际元素不是Object[]，就会抛出ClassCastException。这种情况可以先转成原始List逐个检查：

  List rawList = dao.queryGenericArray("SELECT a, b FROM db");
  for (Object item : rawList) {
      System.out.println("元素实际类型：" + item.getClass());
  }
  

• 排查数据库字段与Java类型的匹配问题
  哪怕SQL简化了，也得留意a、b字段的数据库类型。比如如果字段是MySQL的JSON类型，框架可能把它映射成JSONObject而不是字符串或数组；如果是数组类型，可能返回的是java.sql.Array对象，这些都会导致元素类型不符合预期。

最后给个实用建议：直接debug进DAO方法的实现里，看看查询结果被封装成什么结构了，比猜原因高效得多。

内容的提问来源于stack exchange，提问作者Lee Carr