Java中泛型数组不能直接创建，因类型擦除导致运行时无法获取元素真实类型，Hessian2、Kryo等序列化框架反序列化时易出现ClassCastException等问题；推荐用List<List<T>>或封装类替代。
Java中泛型数组本身不能直接创建（如 List<String>[] 会编译报错），这是由泛型擦除和类型安全机制共同决定的。但在序列化/反序列化场景中，开发者常误以为“泛型数组”能被正确还原，结果在 Hessian2、Kryo 等框架中频繁出现 ClassCastException、NullPointerException 或字段丢失等问题。核心矛盾在于：**运行时无法获取泛型数组的真实元素类型，而多数序列化器默认按 Object[] 或原始数组处理，导致反序列化后类型信息丢失。**
泛型数组为何不能直接声明
Java 不允许创建具体泛型类型的数组，例如：
List<String>[] arr = new ArrayList<String>[10]; // 编译失败- 只能退而求其次写成：
List[] arr = new ArrayList[10];或Object[] arr = new Object[10];
这种写法绕过了编译检查，但代价是：数组元素在运行时完全丢失泛型信息，反序列化器无法知道每个 arr[i] 原本应是 List<String> 还是 List<Integer>。
Hessian2 对泛型数组的处理局限
Hessian2 虽支持跨语言和类描述缓存，但它对数组的泛型推断仅依赖静态声明类型（即变量声明的左值类型），不解析实际元素的泛型参数：
立即学习“Java免费学习笔记（深入）”；
- 若字段声明为
private List<User>[] users;，Hessian2 反序列化时只识别为List[]，内部每个List默认反序列化为ArrayList，但User类型信息丢失 → 元素变成LinkedHashMap或原始 map，强转User报错 - Hessian2 不读取泛型签名字节码（不像 FastJSON 可通过
TypeReference显式传入），也不支持运行时反射提取数组元素泛型 - 即使类加了
@ApiModel或@JsonProperty，Hessian2 也基本忽略——它本质是二进制协议，不依赖注解驱动
Kryo 的泛型数组风险与规避方式
Kryo 性能高、体积小，但默认注册器对泛型数组更“激进”：
- 未显式注册泛型类型时，Kryo 将
List<String>[]视为Object[]，序列化后所有元素都按Object处理；反序列化时每个元素变成LinkedHashMap（因 Kryo 默认用 map 表示未知 POJO） - 解决方法不是靠注解，而是注册专用的序列化器：
kryo.register(List[].class, new ArraySerializer<List>(kryo, List.class));
但注意：这只能保证数组结构，仍无法恢复List<User>中的User类型 - 真正可行的做法是改用容器类封装：定义
public class UserListArray { private List<User>[] data; }，再为该类注册自定义Serializer，在read()中手动用Class.forName("com.example.User")构造并反序列化每个元素
实用建议：绕过泛型数组，用可序列化的替代结构
与其硬扛泛型数组的反序列化缺陷，不如采用语义等价、框架友好的结构：
- 用
List<List<User>>替代List<User>[]：所有主流序列化器（Hessian2/Kryo/FastJSON）都能完整保留嵌套泛型 - 若需随机访问性能，定义
public final class GenericArray<T> implements Serializable { private final List<T> list; ... }，提供get(int)和toArray(Class<T>)方法 - 在 RPC 或缓存场景（如 Dubbo + Redis），统一约定传输格式为 JSON 字符串，配合
new TypeReference<List<List<User>>>(){}让 FastJSON/Gson 精确还原 —— 虽有性能损耗，但类型安全零妥协 - 如必须用数组且用 Hessian2，可在序列化前手动展开：将
List<User>[]转为Object[][]，每个内层数组存User的 JSON 字符串；反序列化后再逐个 parse，代价是增加编码/解码步骤，但规避了类型擦除
