抽象类在java框架底层的核心作用是定义统一扩展契约、封装共用逻辑并强制子类实现关键行为，通过模板方法固化主流程、开放钩子方法、预置基础设施、约束必要能力，并配合工厂/spi实现解耦装配。
抽象类在 Java 框架底层设计中，核心作用是定义统一的扩展契约、封装共用逻辑，并强制子类实现关键行为。它不是用来被直接实例化的，而是作为框架可插拔机制的“骨架”。
定义标准流程与钩子方法
框架常通过抽象类固化主流程（模板方法模式），把变化点声明为 abstract 或 protected 方法，留给用户定制。比如 Spring 的 AbstractController（老版本）或 MyBatis 的 BaseExecutor，都把“执行前准备→真正执行→结果处理”串成 final 方法，只开放 doQuery()、doUpdate() 等钩子让子类重写。
- 主流程逻辑写在 final 方法里，避免子类误改顺序
- 钩子方法用
protected或abstract声明，明确哪些环节必须/可以定制 - 抽象类内部可预置通用工具，如日志、事务判断、参数校验等，子类自动继承
封装重复的基础设施调用
框架底层往往要对接线程池、事件总线、配置中心、监控埋点等。这些代码若每处都重写，既冗余又易错。抽象类可集中初始化和复用这些资源。
- 在构造器或
init()模板方法中加载配置、注册监听器 - 提供
getMetricsReporter()、publishEvent()等受保护方法，子类按需调用 - 避免每个具体组件都重复写 try-catch + close 资源逻辑，统一在抽象基类中处理
约束子类必须实现的关键能力
当框架需要某类组件具备特定语义行为时（如序列化、类型推断、条件匹配），抽象类比接口更合适——它既能强制实现，又能自带默认逻辑。
- 例如 Dubbo 的
AbstractClusterInvoker强制子类实现doInvoke()，同时自带负载均衡、失败重试等公共逻辑 - 对比接口：抽象类可含字段、构造器、非 public 方法，更适合封装有状态的框架组件
- 一个抽象类可继承另一个抽象类，形成层次化能力抽象，如
AbstractDataSource→AbstractPooledDataSource
配合工厂或 SPI 实现运行时装配
框架通常不直接 new 抽象类，而是通过工厂、SPI 或注解扫描找到具体子类，再实例化。抽象类在此扮演“类型契约”角色。
- Spring 的
BeanFactoryPostProcessor是接口，但很多内置实现（如PropertyPlaceholderConfigurer）继承自AbstractBeanFactoryAwareInvocationHandler类来复用代理逻辑 - Java SPI 服务提供者可返回抽象类的子类实例，框架仅依赖抽象类类型编程，实现解耦
- 注解驱动场景下（如
@EventListener），底层监听器基类常是抽象的，确保所有监听器共享事件分发、异常处理等机制
抽象类不是越多越好，关键在识别出稳定不变的部分和必须由使用者决定的部分。用得好，它能让框架既有约束力，又有延展性；用得滥，反而增加理解成本和继承链负担。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
