Java泛型类型之间不存在继承关系，即使类存在继承关系，如ArrayList<Dog>也不是ArrayList<Animal>的子类；泛型具备不可变性（invariance），Box<String>与Box<Object>无继承关系，通配符用于解决类型安全的读写限制问题。
Java中自定义连接池若声明为 ObjectPool extends Resource>，这种写法本身**不合法**，也无法通过编译——它混淆了泛型继承与类型参数约束的语法，属于常见误写。真正影响借出（checkOut）与归还（checkIn）行为的，是泛型类型参数的通配符使用方式，而非“extends Resource”这种错误继承。
泛型声明必须明确类型参数
正确的基类定义应为：
-
abstract class ObjectPool<T>—— T 是具体资源类型（如Connection、Socket），不是父类； -
class JDBCConnectionPool extends ObjectPool<Connection>—— 子类固定绑定具体类型； -
Resource可作为T的上界（如<T extends Resource>），用于约束可池化对象需具备统一生命周期接口，但不能写成ObjectPool extends Resource>。
借出方法返回值不能用无界通配符
若借出方法写成 T checkOut()，调用方能直接获得具体类型，安全可用；但若错误地暴露为：
-
ObjectPool<?>.checkOut()→ 返回Object，丢失类型信息，无法直接转型使用； -
ObjectPool<? extends Resource>.checkOut()→ 返回? extends Resource，编译器禁止你调用任何非Resource声明的方法（即使实际是Connection），也无法安全归还（因类型不匹配）； - 正确做法：保持原始泛型实例，如
JDBCConnectionPool调用checkOut()直接返回Connection，无需擦除。
归还方法对通配符极其敏感
归还操作要求传入的对象类型必须与池中管理的类型完全一致或可赋值：
立即学习“Java免费学习笔记（深入）”；
-
void checkIn(T t)接收T，只接受该池创建/管理的同类型对象； - 若调用方持有
ObjectPool<? extends Resource>引用，就无法调用checkIn(...)—— 编译器不知道 ? 具体是什么，拒绝传入任何具体实例； - 常见规避写法是提供非泛型归还接口（如
void returnObject(Object obj)），但牺牲类型安全，需内部强转并验证； - 更稳妥的做法：归还始终通过原始类型引用调用，例如
jdbcPool.checkIn(conn)，而非通过通配符引用。
实际开发中推荐的泛型模式
避免通配符参与核心池操作，聚焦于具体类型复用：
- 池实现类不暴露通配符类型，对外提供
JDBCConnectionPool、RedisConnectionPool等具名子类； - 如需统一管理，定义接口
interface PooledResource<T> { T borrow(); void release(T t); }，各池实现该接口，而非泛型基类； - 工厂类或注册中心按类型获取具体池实例，绕过泛型擦除问题；
- 必要时用
<T extends AutoCloseable>约束，保证expire()可安全调用close()，而非依赖Resource抽象类。
