1. 继承是什么——先搞懂它解决什么问题1.1 从生活类比看继承几乎所有讲Java的书都会把继承放到面向对象三大特性的核心位置但很多初学者学完语法之后反而陷入一种会写但不知道什么时候用的状态。我接触过不少刚入行的开发者问他继承是什么他能把子类继承父类重写父类方法背得滚瓜烂熟但真正拿到一个需求依然不知道哪些类该抽父类哪些地方该用继承而不是组合。先做个最直白的类比。你把一份通用模板发给团队所有人每个人在模板基础上改出自己的版本——通用模板就是父类各人改出来的版本就是子类。继承做的事情本质上就是把大家都有的公共部分沉淀到一处让每个子类只关注自己独有的差异。这个类比虽然简单但能帮我们抓住继承最核心的价值消除重复提取共性。Java的继承用一句话概括就是子类自动获得父类非私有的属性和方法同时可以扩展自己的新能力或者改写父类的已有能力。关键词是自动获得和改写前者解决复用问题后者解决扩展问题。1.2 继承的为什么代码复用和体系建模继承解决两个层面的问题。第一个层面是代码复用这是最直接、最容易被感知的。比如你要写三种支付类——支付宝支付、微信支付、银行卡支付如果不用继承每个类里都要写一堆校验签名、记录日志、处理回调的重复代码。抽一个BasePayment父类把这些公共逻辑放进去三个子类只写各自不同的支付调用逻辑代码量瞬间缩水一大半。第二个层面是体系建模这层价值经常被忽略。继承不只是代码层面的复用它还会在类型层面建立一种is-a关系。Dog继承Animal表达的语义是狗是一种动物。这种语义有多重要当你的方法参数声明为Animal时所有动物子类都能传进来这就是多态的基础。没有继承多态就无从谈起没有多态面向对象编程就失去了一半的灵活性。实际项目中继承最常见的应用场景是框架设计、模板方法模式和公共基础类抽取。框架里你经常看到这样的写法继承某个BaseActivity或者BaseController父类里封装好了生命周期处理、参数校验、日志埋点子类只需要关注自己的业务逻辑。这就是继承在真实工程里最朴素也最有效的用法。1.3 继承不是万能的它有哪些代价我必须先泼一盆冷水继承不是银弹滥用继承的代价非常大。最典型的问题是继承破坏了封装性。子类可能通过重写父类方法改变父类的内部行为而父类作者完全不知情。如果你的父类被几十个子类继承你改父类的一个方法签名或者修改某个protected字段的语义所有子类都可能悄悄出问题。另一个代价是继承层级过深带来的僵化。我曾经接手过一个遗产代码一个业务父类下面继承链条达到五层最底层子类要调用的方法已经说不清是第几层父类定义的改一处行为要顺着继承链往上排查好几层。这种代码维护成本极高我当时把这条继承链重构成了组合加策略模式代码清晰了一大截。所以下面讲的所有语法细节和设计方法都有一个前提继承是工具不是目的。该用的时候大胆用该用组合的时候也千万别死磕继承。这个度怎么把握后面专门有一节说。2. Java继承的语法陷阱与核心细节2.1 super和this你真的用对了吗继承语法里最先让人犯迷糊的就是super和this。this指向当前对象这个大多数人理解没问题super不是指向父类对象而是指向父类中被当前对象继承下来的那一部分。理解这一点很关键super并不是一个独立的对象引用你不能把super赋值给别的变量然后到处传。super的核心用途有两个调用父类构造器访问父类成员方法、字段。构造函数里调用父类构造器必须用super(参数)而且必须是构造器的第一行语句。这个第一行限制是有原因的——Java要求先初始化父类部分才能初始化子类部分如果允许把super()放在后面就可能出现子类字段已经初始化但父类还没构造完的中间状态容易埋隐患。有一个细节很多人忽略子类构造器里如果没有显式写super(...)编译器会自动加一个无参的super()。这时候如果父类只定义了带参构造器而没有无参构造器编译器会直接报错。遇到这个报错要么在父类补一个无参构造器要么子类显式调用带参的父类构造器。我在给新人review代码时这个错误出现的频率相当高。public class Base { private String name; // 父类只有带参构造器 public Base(String name) { this.name name; } } public class Child extends Base { private int level; // 子类必须显式调用父类带参构造器否则编译失败 public Child(String name, int level) { super(name); // 必须放在第一行 this.level level; } }2.2 方法重写的硬性规则方法重写是继承里最常用也最容易踩坑的语法点。重写的规则总结起来是方法签名必须相同返回类型可以相同或者是父类返回类型的子类型协变返回访问权限不能比父类更严格且不能抛出比父类更宽泛的受检异常。访问权限这条要特别记牢父类方法是protected子类重写时可以是protected或public但不能是private或包私有。这背后的逻辑是里氏替换原则——凡是能用父类对象的地方都应该能用子类对象替换如果子类把方法权限缩小了替换之后就调不到了系统行为就变了。另一个容易忽略的点是静态方法不存在重写。子类里定义一个和父类静态方法签名完全相同的方法它只是隐藏了父类方法而不是重写。调用哪个方法取决于引用类型而不是运行时类型。public class Base { public static void hello() { System.out.println(hello from Base); } } public class Child extends Base { public static void hello() { // 这是隐藏不是重写 System.out.println(hello from Child); } } public class Main { public static void main(String[] args) { Base base new Child(); base.hello(); // 输出 hello from Base不是 Child } }这个现象常被称为静态方法重写失效本质上是因为静态方法属于类不参与实例的运行时多态调度。实际开发中我建议父类和子类的静态方法不要设计成相同签名这种隐藏行为只会让人困惑。2.3 构造器执行顺序最容易搞错的一个点实例化一个子类对象时构造器的执行顺序是先执行父类构造器再执行子类构造器。这个先父后子的顺序不只针对直接父类而是沿着继承链一路向上从最顶层的父类开始依次往下执行。换句话说创建一个子类对象实际上把整条继承链上所有父类的构造器都触发了一遍。为什么要这么设计因为子类对象在内存中就是一个完整的整体它包含所有父类中定义的字段。如果父类字段还没初始化子类构造器里访问这些字段就会拿到默认值null、0、false行为根本不可预测。所以Java强制先完成父类部分的初始化再初始化子类部分。实操中这个顺序带来的常见问题是什么是父类构造器里调用了被子类重写的方法。Java的动态绑定在构造器执行期间就已经生效了也就是说父类构造器里调用的方法如果被子类重写了实际执行的是子类版本。但此时子类的字段可能还没初始化就会读到默认值埋下莫名其妙的空指针或逻辑错误。public class Base { public Base() { display(); // 调用的是子类重写后的方法 } protected void display() { System.out.println(base display); } } public class Child extends Base { private String message child message; Override protected void display() { System.out.println(message); // 输出 null因为 message 还未初始化 } }这个坑非常隐蔽项目里真实发生过的案例是父类构造器里调了一个初始化方法子类重写了这个方法加载自己的配置结果每次启动子类实例都读到空配置。排查了半天才定位到是构造器时期的动态绑定问题。我的经验是父类构造器里尽量不要调用任何可能被重写的方法如果要调用初始化逻辑优先设计成private方法或者干脆放到子类自己的构造流程里。2.4 final、访问修饰符与继承边界final关键字在继承语境里有两个作用。final方法表示该方法不能被子类重写通常用于锁定核心算法骨架final类表示整个类不能被继承最典型的例子就是String类。为什么String要被声明成final因为String被广泛用作哈希键、常量池等场景如果可以继承并重写它的行为整个字符串体系的稳定性都会受到威胁。访问修饰符对继承的影响也值得单独捋一遍。private成员不参与继承子类看不到也访问不了public和protected成员被子类继承其中protected的设计初衷就是让子类访问但对外部世界隐藏包私有默认权限成员只有同包下的子类能继承跨包子类无法直接访问。这里的常见误区有两个。第一个误区认为子类对象可以访问父类的private字段。不能子类只能通过父类提供的getter/setter或者protected方法间接访问。第二个误区protected成员被继承后子类方法和外部类访问它的权限不同。子类可以访问从父类继承来的protected成员但子类的外部代码想通过子类实例访问protected成员Java会限定只能访问到子类自己类型批准的部分。这个细节偏冷门了解即可。3. 从语法到设计继承在实战里的正确打开方式3.1 抽取基类和抽象类的判断标准语法学会了真正难的是设计层面什么时候该抽父类该抽抽象类还是普通类这里我给出我在实战中常用的几条判断标准都是踩过坑之后总结出来的。第一条多个类之间有真实的公共代码和公共语义才值得抽父类。如果只是代码长得很像但业务含义完全不同强行抽父类反而会造成误导。判断依据是is-a关系能不能说通——Triangle是Shape合理User和Order都有createTime字段不代表User是Order这种共性更适合用组合或者工具类处理。第二条如果父类本身不应该被实例化就用抽象类。比如你定义了一个Animal父类里面有个makeSound()方法但你根本不需要一个既不是狗也不是猫的普通动物实例。这时候应该把Animal声明为abstractmakeSound()声明为抽象方法强制子类实现。抽象类的语义就是定义一个模板但不允许直接使用模板本身。第三条抽象方法的设计要能表达子类必须提供的核心差异。抽象方法数量宁少勿多只把那些真正无法在父类层面给出通用实现的逻辑声明为抽象。如果一个方法在80%的子类里实现相同、20%不同更好的做法是在父类里给出默认实现子类按需重写而不是把它搞成抽象方法。3.2 模板方法模式继承最经典的落地场景模板方法模式是我认为继承最具说服力的实战场景。它的结构很简单父类定义一个完整的算法骨架骨架中的某些步骤声明为抽象方法或者可重写方法由子类提供具体实现整体流程由父类控制子类只负责填充差异部分。这样做的最大好处是流程逻辑不会散落在各个子类重复编写流程变了只改父类一处。举个实际例子。一个数据上报系统不同渠道的上报流程都要经历数据校验→数据转换→发送上报→记录日志四步校验和日志逻辑对所有渠道都一样但数据转换和具体发送方式各渠道完全不同。于是父类里把校验和日志实现完整写死把转换和发送声明为抽象方法每个渠道子类只需要实现自己独有的转换和发送逻辑。public abstract class ReportTask { // 模板流程用 final 防止子类篡改流程顺序 public final void execute() { validateData(); Object converted convertData(); send(converted); writeLog(); } private void validateData() { // 通用校验逻辑 } protected abstract Object convertData(); protected abstract void send(Object data); private void writeLog() { // 通用日志逻辑 } }这个模式我用过很多次它最大的实践价值在于新增加一个渠道时继承父类、实现两个抽象方法整个上报流程就能跑通完全不用关心流程细节。父类用final修饰execute()方法是为了锁死流程顺序防止子类不小心改变了整体流程。3.3 继承和组合怎么选一个真实取舍案例关于继承和组合的争论很多文章都提过优先使用组合而非继承但这个建议经常让新手很迷茫什么时候继承就一定不行我举个真实经历来拆解。曾经做一个推送服务要区分普通通知、营销通知、语音通知。第一版设计我抽了一个BaseNotification父类三个子类继承它各自实现发送方法。到了一期迭代需求变了营销通知需要支持多渠道多模板配置语音通知还要支持回调重试两者共同的逻辑越来越少父类不断膨胀子类里也开始出现一大片魔法式的if (this instanceof MarketingNotification)分支代码味道越来越浓。后来我重构把继承改成组合。定义一个Notifier接口普通、营销、语音各实现一个Notifier。再定义一个Notification业务类它持有Notifier的引用发送时委托给Notifier去处理。想加能力加新的Notifier实现类就行完全不碰已有代码。这个方案的灵活度明显更高各策略之间也没有继承带来的强耦合。用这个案例我想说明的取舍原则很明确当子类之间的差异是同类扩展都是同一类事务的不同分支共用流程骨架继承合适当子类之间的差异是行为策略同一个行为有很多种不相关的实现路径组合接口更合适。前者典型是模板方法模式中的场景后者典型是策略模式中的场景。这个判断能力需要在真实项目中慢慢磨但至少你要有一个意识继承会带来类型上的强绑定组合带来的则是行为上的灵活替换。3.4 接口与继承Java单继承双刃剑的破局手段Java只支持类的单继承一个类只能有一个直接父类。这个设计简化了类型系统但也带来一个限制一个类可能同时具有多重身份。比如一个类既是一个可比较的对象Comparable又是一个可序列化的内容Serializable还是一个可完成的异步任务Runnable这些能力无法通过多重继承都从父类拿到。接口就是破局手段。Java允许一个类实现多个接口接口之间可以多继承interface A extends B, C这等于在类型层面对多继承做了补偿。更重要的是接口定义的是能做什么的能力契约和继承表达的是什么的语义不同。设计上推荐把能力设计成接口把共性骨架设计成抽象类两者各司其职。一个常见的组合套路是抽象类接口搭配使用接口定义公共契约抽象类实现一部分通用逻辑具体子类继承抽象类。这样既保证了契约清晰又复用了通用实现。Java集合框架就是这种设计的典型代表List接口定义契约AbstractList抽象类提供通用实现骨架ArrayList和LinkedList分别继承它实现各自的存储逻辑。4. 常见问题与排查技巧实录4.1 构造器调用顺序引发的初始化异常现象描述子类实例化的时候某些字段读到null或0程序逻辑表现异常但代码看起来完全正常。排查思路优先检查父类的构造器中是否调用了可被重写的方法尤其是initialize()、init()、load()这类命名的方法。如果是子类重写的方法在父类构造函数执行阶段就会被调用此时子类字段尚未完成初始化赋值所有字段都停留在默认值状态。解决方案把初始化拆成两段——父类构造器只负责父类自有字段的初始化子类字段的初始化放在子类构造器中。如果确实需要在构造阶段执行多态逻辑我建议改成提供一个protected的回调方法让子类覆写但在父类构造器里不要调用它而是由子类构造器在完成自身字段初始化后再显式调用。4.2 重写equals/hashCode导致的HashSet异常现象描述子类重写了equals()但忘记重写hashCode()导致把子类对象放进HashSet或作为HashMap的key时出现放得进去取不出来或者重复元素的问题。排查思路HashSet依赖两个方法同时判断对象是否相等——先比较哈希码哈希码相同再调用equals()做细节比对。如果两个逻辑上相等的子类对象拥有不同的hashCode()它们在哈希表里会被分到不同的桶中equals()根本不会被调用到。解决方案凡是重写equals()必须重写hashCode()保证相等的对象必须有相同的哈希码。继承场景下还要额外注意如果你在父类里实现了基于业务字段的equals()子类加了自己的字段后又覆盖了equals()父类和子类的混合比较行为很容易失控。我的做法是尽量不让父子类各自维护一套相等性逻辑实在要比较就在同一个层级处理避免混用。这条经验在面试中也经常被问到值得认真对待。4.3 继承层级过深带来的维护噩梦现象描述改动一个底层父类的方法名或行为上层多个类都跟着报错运行期行为也变了排查起来无从下手。排查思路先用工具IDE的层级视图把继承链完整拉出来看看到底有多少类直接或间接受影响。如果链条超过三层基本可以认定设计出了问题。我见过有些项目的继承链长得离谱A继承BB继承CC继承DD继承E最底层的某个类要找一个方法的来源都费劲更别提理解整个体系。解决方案遇到这种代码不要想着在现有继承链上继续打补丁。比较稳妥的重构路线是把链条中间层的具体逻辑下推或上提能合并的层级就合并与此同时用组合接口替代一部分仅仅为了复用代码的继承关系。重构过程要配合充分的单元测试每改一步跑一遍测试防止行为漂移。4.4 自查清单写完继承代码前过一遍我给自己定了一套继承代码的自查清单每次写完之后都会过一遍建议你也养成这个习惯子类和父类的关系能否用is-a说通说不通就考虑用组合。父类构造器是否调用了可重写的方法有就改掉。子类重写的方法是否违反了里氏替换原则比如抛了更宽的异常、收窄了访问权限、改变了方法的契约语义父类的equals()、hashCode()、toString()是否被子类正确协同重写继承层级是否超过三层超过三层就警惕重新审视设计。这个继承是为了复用实现还是为了表达多态接口如果只是复用实现接口组合往往更合适。父类的设计是否把所有子类共性的部分都收拢干净了有没有子类里还重复写着一大段父类已有的逻辑提示清单不追求面面俱到但每一条都是我在真实开发里碰到过问题的地方。自查不是走流程每条都要能说清为什么检查它这样才有效。多聊一句经验我刚开始写代码的时候特别喜欢用继承觉得这样代码很面向对象后来做了几个大型项目经历了多次重构才逐渐明白继承是众多工具中的一种它既不是高层次的象征也不是必须绕开的坑。真正靠谱的做法是明确它解决什么问题、带来什么代价、在哪些场景下无可替代然后让设计意图来决定用还是不用。把这一节里讲到的语法细节和设计原则消化掉面对绝大多数继承相关的日常开发问题你都能有自己的判断。