快捷導(dǎo)航

Java AbstractMethodError案例分析詳解

更新時(shí)間：2021年08月23日 10:24:33 作者：liunim90

這篇文章主要介紹了Java AbstractMethodError案例分析詳解,本篇文章通過(guò)簡(jiǎn)要的案例,講解了該項(xiàng)技術(shù)的了解與使用,以下就是詳細(xì)內(nèi)容,需要的朋友可以參考下

背景

AbstractMethodError異常對(duì)于我來(lái)說(shuō)還是比較不常遇見(jiàn)的，最近有幸遇到，并僥幸的解決了，在這里把此種場(chǎng)景剖析一番，進(jìn)入正題，下面是AbstractMethodError在Java的異常機(jī)制中所處的位置：

AbstractMethodError類圖

現(xiàn)在明確了AbstractMethodError所具有的特性：

1.它是Error的子類，Error類及其子類都是被劃分在非檢查異常之列的，就是說(shuō)這些異常不能在編譯階段被檢查出來(lái)，只能在運(yùn)行時(shí)才會(huì)觸發(fā)。

2.通過(guò)API文檔里面的解釋大致得出的結(jié)論就是說(shuō)A依賴于B，但是執(zhí)行的時(shí)候發(fā)現(xiàn)類B的定義發(fā)生了改變，這個(gè)改變是針對(duì)編譯的時(shí)候發(fā)生了改變，也就是說(shuō)將類A由java文件編譯成.class文件的時(shí)候用到了類B的class文件，但是在執(zhí)行的時(shí)候JVM發(fā)現(xiàn)真正用到的B的class文件和編譯的時(shí)候用的不是一個(gè)了。于是這個(gè)異常就被拋了出來(lái)。

至此，AbstractMethodError發(fā)生的底層原因也了解的差不多了，再往深層的話就是java的編譯機(jī)制，以及java代碼的執(zhí)行檢查這些更靠近虛擬機(jī)的東東，那些我也沒(méi)什么研究，暫且不表。

底層原因了解了，我們繼續(xù)談下平常遇到的更直觀的場(chǎng)景:

ClassA ->AbstractClassB ClassA 依賴于AbstractClassB，通常A是我們自己開(kāi)發(fā)的類，而B(niǎo)則是引用的第三方j(luò)ar包里面的抽象類。我們的項(xiàng)目中又存在AbstractClassB的多個(gè)實(shí)現(xiàn)版本，比如：1.0，1.2，2.0等版本，通常主版本號(hào)發(fā)生了改變的話，一般都是不兼容的。

類A

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

1.0版本的AbstractClassB：

abstract class B {
    // v1.0
    public abstract void changedMethodInDifVersion(int arg1);
}
 
class BImpl extends B{
    public void changedMethodInDifVersion(int arg1){
        System.out.prinln("我是AbstractClassB 的 1.0 版本實(shí)現(xiàn),Class A編譯的時(shí)候我沒(méi)參與，但是Class A運(yùn)行的時(shí)候我卻參與了。");        
    }
}

2.0版本的AbstractClassB：

abstract class B {
    //v2.0
    public abstract void changedMethodInDifVersion(int arg1, String arg2);
}
 
class BImpl extends B{
    public void changedMethodInDifVersion(int arg1, String arg2){
        System.out.prinln("我是AbstractClassB 的 2.0 版本實(shí)現(xiàn),編譯的時(shí)候是我參與了編譯");        
    }
}

如果在編譯的時(shí)候使用的2.0版本中的BImpl和2.0版本的AbstractClassB，然而執(zhí)行的時(shí)候使用的又是1.0版本的BImpl，那么就會(huì)拋出AbstractMethodError，這個(gè)異常拋出以后會(huì)把運(yùn)行時(shí)真正找到的那個(gè)方法簽名給打印出來(lái)的，異常信息會(huì)入下：

Exception in Thread XXXXX java.lang.AbstractMehodError package.Class.運(yùn)行時(shí)實(shí)際找到的方法

這個(gè)時(shí)候在你的classpath中尋找這個(gè)類,剔除掉不需要的版本就可以了。

如果在編譯的時(shí)候使用的2.0版本中的BImpl和2.0版本的AbstractClassB，然而執(zhí)行的時(shí)候使用的又是1.0版本的BImpl 和 1.0版本的AbstractClassB，就會(huì)報(bào)NoSuchMethodError。

到此這篇關(guān)于Java AbstractMethodError案例分析詳解的文章就介紹到這了,更多相關(guān)Java AbstractMethodError詳解內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: