Java AbstractMethodError 原因分析

拼搏现实的明天。 2023-05-22 04:55 1阅读 0赞

**背景**

AbstractMethodError异常对于我来说还是比较不常遇见的，最近有幸遇到，并侥幸的解决了，在这里把此种场景剖析一番，进入正题，下面是AbstractMethodError在Java的异常机制中所处的位置：

![AbstractMethodError类图][AbstractMethodError]

现在明确了AbstractMethodError所具有的特性：

1.它是Error的子类，Error类及其子类都是被划分在非检查异常之列的，就是说这些异常不能在编译阶段被检查出来，只能在运行时才会触发。

2.通过API文档里面的解释大致得出的结论就是说A依赖于B，但是执行的时候发现类B的定义发生了改变，这个改变是针对编译的时候发生了改变，也就是说将类A由java文件编译成.class文件的时候用到了类B的class文件，但是在执行的时候JVM发现真正用到的B的class文件和编译的时候用的不是一个了。于是这个异常就被抛了出来。

至此，AbstractMethodError发生的底层原因也了解的差不多了，再往深层的话就是java的编译机制，以及java代码的执行检查这些更靠近虚拟机的东东，那些我也没什么研究，暂且不表。

底层原因了解了，我们继续谈下平常遇到的更直观的场景:

ClassA ->ClassB  ClassA 依赖于ClassB，通常A是我们自己开发的类，而B则是引用的第三方jar包里面的类。我们的项目中又存在ClassB的多个版本，比如：1.0，1.2，2.0等版本，通常主版本号发生了改变的话，一般都是不兼容的。

类A

class A { 
    	B dependency = new BImpl();
    	
    	public void testMethod(){ 
    		dependency.changedMethodInDifVersion(arg1, arg2);
    	}
    }

1.0版本的类B：

abstract class B { 
        public abstract void changedMethodInDifVersion(int arg1);
    }

2.0版本的ClassB：

abstract class B { 
        public abstract void changedMethodInDifVersion(int arg1, String arg2);
    }

如果在编译的时候使用的2.0版本中的这个ClassB，然而执行的时候使用的又是1.0版本的ClassB，那么就会抛出AbstractMethodError，这个异常抛出以后会把运行时真正找到的那个方法签名给打印出来的，异常信息会入下：

Exception in Thread XXXXX java.lang.AbstractMehodError package.Class.运行时实际找到的方法

这个时候在你的classpath中寻找这个类,剔除掉不需要的版本就可以了。

[AbstractMethodError]: /images/20230521/7f32e143e2ab49588c4e82dd531677f1.png