Java泛型不是语法糖，它在编译期做类型检查并擦除类型信息，导致运行时无法获取真实泛型参数，因此不能直接new T()或使用T.class，必须显式传入Class对象或用Supplier封装构造逻辑。
Java 的泛型不是语法糖，它在编译期做类型检查、擦除后生成桥接方法，但不能绕过类型擦除去获取真实泛型参数——这意味着你无法在运行时 new T>() 或直接用 Class<t></t> 做实例化，这是绝大多数泛型数据结构出错的根源。
为什么不能直接 new T()？类型擦除导致的实例化限制
泛型信息在 JVM 运行时不存在，T 被擦除为 Object（或上界类型），所以 new T() 编译不通过。常见错误包括：
- 写
return new T();→ 编译报错Cannot instantiate the type T - 试图用
T.class获取类对象 → 编译失败，T不是类字面量 - 反射调用
constructor.newInstance()时传入Class<t></t>却没真正持有该 Class 实例
解决办法是显式传入 Class<t></t> 参数，或用 Supplier<t></t> 封装构造逻辑：
public class Stack<T> {
private final Class<T> type;
public Stack(Class<T> type) { this.type = type; }
public T createNew() throws Exception {
return type.getDeclaredConstructor().newInstance();
}
}
如何设计一个支持泛型的链表节点？注意引用与类型安全
泛型节点本身很简单，但关键在于：节点类必须声明自己的类型参数，并把泛型传递给引用字段，否则会丢失类型约束。错误写法是让 next 是原始类型 Node，正确写法是保持 Node<t></t>：
立即学习“Java免费学习笔记（深入）”；
public class Node<T> {
final T data;
Node<T> next; // ✅ 不是 Node，也不是 Node<?>
public Node(T data) {
this.data = data;
}
}
如果写成 Node next，则插入 String 后再取值需强制转型，破坏类型安全；若写成 Node>，则无法向 next 赋值新节点（通配符不可变）。实际使用中还要注意：
- 泛型节点类最好设为
static，避免隐式持有所在泛型容器的this引用 - 不要在节点内缓存
Class<t></t>，除非构造时明确传入——节点不负责实例化，只负责存储和链接 - 若需序列化，确保
T实现Serializable，否则运行时抛NotSerializableException
泛型集合里存基本类型怎么办？包装类与自动装箱的代价
Java 泛型不支持基本类型，List<int></int> 是非法的。必须用 List<integer></integer> 等包装类。这带来两个现实问题：
- 频繁装箱/拆箱造成 GC 压力，尤其在数值密集计算场景（如统计、排序）
- 空值风险：
Integer x = null;→x.intValue()抛NullPointerException
应对策略分三层：
— 日常开发：接受 Integer/Double，用 Objects.requireNonNull() 或 Optional 包裹输入值
— 性能敏感路径：改用第三方库如 fastutil 或 trove，它们提供 IntArrayList、DoubleLinkedOpenHashSet 等原生类型集合
— 自研泛型结构时：若仅服务单一基本类型，可单独写特化版本（如 IntStack），避免泛型擦除+装箱双重开销
泛型方法 vs 泛型类：什么时候该用哪一个？
泛型类适用于整个结构都围绕同一组类型参数运作（如 HashMap<k></k>）；泛型方法则适合局部需要类型推导的操作，比如工具函数。典型误用是把本该是泛型方法的逻辑硬塞进泛型类：
// ❌ 错误：为一个静态工具方法强行套泛型类
class ArrayUtils<T> {
static <T> T[] copyOf(T[] src, int len) { ... } // 静态方法不用依赖类泛型
}
// ✅ 正确：泛型方法独立存在，调用时自动推导
public class Arrays {
public static <T> T[] copyOf(T[] original, int newLength) { ... }
}
判断依据很实在：
- 如果类里所有方法都依赖相同的
T，且实例状态含T字段 → 用泛型类 - 如果只是某个方法要处理任意类型，且不维护
T状态 → 用泛型方法 - 如果方法返回类型依赖参数类型（如
<T> T get(String key)），必须用泛型方法，否则无法保证调用端类型一致
泛型方法还能规避“泛型类继承时类型参数污染”问题——比如子类想固定 T 为 String，但父类泛型仍保留，容易引发意外的类型放宽。
泛型真正的复杂点不在怎么写，而在怎么不让它泄漏到不该出现的地方：比如把 List<? extends Number> 当作 List<Integer> 用，或者在反射操作中误以为 getTypeParameters() 能拿到运行时真实类型。这些地方没有编译错误，却会在某次数据流穿过三层泛型嵌套后突然崩掉。
