您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“Null的問(wèn)題有哪些”的有關(guān)知識(shí),在實(shí)際案例的操作過(guò)程中,不少人都會(huì)遇到這樣的困境,接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
假設(shè)現(xiàn)在有一個(gè)需要三個(gè)參數(shù)的方法。其中第一個(gè)參數(shù)是必須的,后兩個(gè)參數(shù)是可有可無(wú)的。
第一種情況,在我們調(diào)用這個(gè)方法的時(shí)候,我們只能傳入兩個(gè)參數(shù),對(duì)第三個(gè)參數(shù),我們?cè)谏舷挛睦锸菦](méi)有的,那么我們調(diào)用方法的時(shí)候,就需要用一個(gè)特殊值去告知這個(gè)方法:
第三個(gè)參數(shù)我們拿不到,參數(shù)是不存在或者不明確的。
這個(gè)特殊的值應(yīng)該用什么呢?在 Java 中,我們會(huì)選擇用 null 去表示這種情況。
第二種情況,如果在調(diào)用方法的時(shí)候,我們有三個(gè)參數(shù),只是第三個(gè)參數(shù)沒(méi)有值,我們也需要傳入一個(gè)特殊的值去表示:
參數(shù)存在,但是沒(méi)有值。
這個(gè)特殊的值是什么呢?沒(méi)錯(cuò),在 Java 中,又是 null。
你看到了,現(xiàn)在 null 值的含義本身出現(xiàn)了兩個(gè)意思:
參數(shù)不存在
參數(shù)沒(méi)有值
二義性在計(jì)算機(jī)科學(xué)里是能避免就盡量避免的。所以,null 值的二義性是一個(gè) Java 中的設(shè)計(jì)缺陷。不過(guò),也不光是在 Java 語(yǔ)言中,null 的二義性在編程語(yǔ)言里是廣泛存在的一個(gè)問(wèn)題。這個(gè)問(wèn)題被稱為 Null 引用問(wèn)題。
Null 引用是計(jì)算機(jī)科學(xué)中一個(gè)歷史悠久又臭名昭著的問(wèn)題。在 1964 年,由快排算法的創(chuàng)造者東尼·霍爾發(fā)明。他自稱這是個(gè)十億美元的錯(cuò)誤。
在 Java 中,當(dāng)我們?nèi)フ{(diào)用一個(gè)對(duì)象值為 null 的方法或者屬性時(shí),就會(huì)報(bào) java.lang.NullPointerException,簡(jiǎn)稱為 NPE。
傳統(tǒng)上,這些 NPE 問(wèn)題,必須完全依賴程序員本身細(xì)致周密的檢查,對(duì)于 null 的檢查充斥在了 Java 代碼的字里行間,讓代碼變得臃腫丑陋,非常惡心。
同時(shí),由于 NPE 的二義性問(wèn)題,開(kāi)發(fā)人員往往無(wú)法完全防護(hù)住 NPE,這使得 NPE 成為了開(kāi)發(fā)人員的噩夢(mèng)。明明邏輯上,一個(gè)對(duì)象是存在的,只是不知道其明確含義,但是只要引用了這個(gè)沒(méi)有明確含義值的對(duì)象的方法,就會(huì)被告知NPE,簡(jiǎn)直讓人防不勝防。
并且,更可惡的是,在 Java 中,NPE 是運(yùn)行期異常,這就意味著 NPE 無(wú)法早期發(fā)現(xiàn),只有上線運(yùn)行了,才可能出現(xiàn)問(wèn)題。
討厭的 null,成本巨大的 NPE,讓 Java 開(kāi)發(fā)人員在不斷地實(shí)踐中,采用了各種方法去對(duì)付 null,讓我們看看這些方法。
NPE 是運(yùn)行期異常,只會(huì)在系統(tǒng)運(yùn)行期間造成,所以導(dǎo)致代碼檢查無(wú)法提前發(fā)現(xiàn)它。如果我們能想辦法把在運(yùn)行期出現(xiàn)的 NPE,提前在編譯代碼時(shí)探測(cè)到,那么我們就會(huì)大大減輕 NPE 對(duì)系統(tǒng)造成的損害。
于是,@NonNull 這個(gè)注解橫空出世了。
@NonNull 這個(gè)注解就是一個(gè)標(biāo)記,這個(gè)標(biāo)記可以和 IDE 聯(lián)動(dòng):當(dāng)可能出現(xiàn) NPE 時(shí),IDE 會(huì)標(biāo)出警告。
我們先看一段代碼:
上面的代碼沒(méi)有加入 @NonNull,可以看到 IDE 并沒(méi)有給出什么警告。
讓我們加上 @NonNull 注解看看:
可以看到,Idea 和 @NonNull 注解形成了聯(lián)動(dòng),并給出了可能出現(xiàn) NPE 的警告。
有了這個(gè)警告,其實(shí)對(duì)一個(gè)復(fù)雜的項(xiàng)目來(lái)說(shuō)還不夠,因?yàn)檫@些警告很容易就會(huì)被忽略過(guò)去了,即使忽略了,項(xiàng)目依然可以編譯運(yùn)行起來(lái)。
那么,我們是不是可以再增加一步檢查?當(dāng)檢查到了可疑的 NPE,根本不允許編譯通過(guò)。是時(shí)候給大家介紹一下 findbugs 了!
我們先在 maven 中配置好 findbugs:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.github</groupId> <artifactId>leetcodeMaster</artifactId> <version>1.0-SNAPSHOT</version> <build> <resources> <resource> <directory>src/main/resources</directory> <!--掃描resources包下的配置文件--> <filtering>true</filtering> <includes> <include>**/*.xml</include> <include>**/*.properties</include> </includes> </resource> <resource> <directory>src/main/java</directory><!--掃描java包下的配置文件--> <includes> <include>**/*.xml</include> <include>**/*.properties</include> </includes> </resource> </resources> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>8</source> <target>8</target> </configuration> </plugin> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>findbugs-maven-plugin</artifactId> <version>3.0.5</version> <configuration> <!-- 設(shè)置分析工作的等級(jí),可以為Min、Default和Max --> <effort>Low</effort> <!-- Low、Medium和High (Low最嚴(yán)格) High只掃描嚴(yán)重錯(cuò)誤。建議用Medium--> <threshold>Medium</threshold> <failOnError>true</failOnError> <includeTests>true</includeTests> <!--findbugs需要忽略的錯(cuò)誤的配置文件--> <!-- <excludeFilterFile>conf/findbugs-exclude-filter.xml</excludeFilterFile>--> <!--findbugs需要忽略的錯(cuò)誤的配置文件--> <includeFilterFile>conf/findbugs-include-filter.xml</includeFilterFile> </configuration> <executions> <execution> <id>run-findbugs</id> <!-- 在package(也可設(shè)為compile) 階段觸發(fā)執(zhí)行findbugs檢查,比如執(zhí)行 mvn clean package --> <phase>compile</phase> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin> </plugins> </build> <dependencies> <!-- https://mvnrepository.com/artifact/com.google.guava/guava --> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>19.0</version> </dependency> <!-- https://mvnrepository.com/artifact/org.apache.commons/commons-lang3 --> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.3.2</version> </dependency> <!-- https://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 --> <dependency> <groupId>com.google.code.findbugs</groupId> <artifactId>jsr305</artifactId> <version>3.0.2</version> </dependency> </dependencies> </project>
緊接著運(yùn)行maven,對(duì)項(xiàng)目進(jìn)行編譯。
mvn clean compile findbugs:findbugs
可以看到,findbugs 發(fā)現(xiàn)可能會(huì)在運(yùn)行期間出現(xiàn) NPE 后,中斷了項(xiàng)目構(gòu)建過(guò)程。
我們?cè)俅蜷_(kāi) findbugs 的界面看看具體的報(bào)錯(cuò)位置:
你瞧,findbugs 準(zhǔn)確的找到了可能出現(xiàn) NPE 的根源。
通過(guò)以上這些手段,我們盡可能的將 NPE 提前到編譯期發(fā)現(xiàn)。
但是啊但是,對(duì)一個(gè)規(guī)模龐大且復(fù)雜的項(xiàng)目來(lái)說(shuō),光使用靜態(tài)代碼檢查還是不夠的。因?yàn)轭愃?findbugs 這種的靜態(tài)代碼檢查工具,不可能對(duì)每個(gè) NPE 的檢查點(diǎn)都檢查到位。并且,探測(cè)的問(wèn)題有時(shí)候因?yàn)闃I(yè)務(wù)原因,也會(huì)放松檢查要求。
別慌,我們可以讓靜態(tài)代碼檢查再加上一些別的方法,來(lái)聯(lián)手堵住 NPE 問(wèn)題,這就是我們下面要說(shuō)的 Optional。
由于鋪天蓋地的 null 檢查,使得 Java 程序員叫苦不堪。于是官方自 Java8 起,參考了 google 的 guava,引入了 Optional 類型用來(lái)避免每次繁瑣丑陋的 null 檢查。
Optional 本質(zhì)上就是一個(gè)容器,這個(gè)容器持有了一個(gè)變量類型為 T 的值。所以,Optional 這個(gè)容器中的值只會(huì)有兩種情況,要么為類型 T 的變量值,要么為null。
對(duì)于可能出現(xiàn)的為 null 的情況,Optional 本身從創(chuàng)建、檢查,到抽取、使用,都提供了對(duì)應(yīng)的方法供使用者調(diào)用。并采用了意義很明確的方法去排除了null的二義性。
我們看示例代碼:
class Player{ private int id; private String name; public int getId() { return id; } public void setId(int id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } } public class Optional4NPE { public static void main(String[] args) { Optional<Player> optionalPlayer = Optional.ofNullable(null); optionalPlayer.ifPresent(u -> System.out.println(u.getName())); } }
以上代碼我們使用了一個(gè) Optional 中的 ofNullable,去創(chuàng)建了一個(gè)包含了類型為 Player、值為 null 的 Optional 容器。
運(yùn)行結(jié)果:
'Process finished with exit code 0'
運(yùn)行后,代碼沒(méi)有任何輸出,也沒(méi)有出現(xiàn) NPE 異常。沒(méi)有輸出的原因是我們傳入了一個(gè) null 值,這個(gè) null 表示值不存在。此時(shí),我們調(diào)用 Optional 的 ifPresent 方法做了判斷,只有存在值時(shí),才會(huì)執(zhí)行打印輸出。
接下來(lái),我們把 null 替換成有意義的值看看。
import java.util.Optional; class Player{ private int id; private String name; public int getId() { return id; } public void setId(int id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } } public class Optional4NPE { public static void main(String[] args) { Player player = new Player(); player.setId(1); player.setName("demoUser"); Optional<Player> optionalPlayer = Optional.ofNullable(player); optionalPlayer.ifPresent(u -> System.out.println(u.getName())); } }
輸出結(jié)果:
demoUser Process finished with exit code
可以看到,當(dāng)傳入一個(gè)我們創(chuàng)建的 player 時(shí),執(zhí)行了打印輸出方法。
上面我們已經(jīng)發(fā)現(xiàn),通過(guò) Optional 的 ifPresent 方法,我們明確了 null 的含義,明確認(rèn)定只要值為 null,就表示不存在。那如果一個(gè)變量存在,但是沒(méi)有值或者沒(méi)有有意義的值呢?
我們把代碼改改:
import java.util.Optional; class Player{ private int id; private String name; public int getId() { return id; } public void setId(int id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } } public class Optional4NPE { public static void main(String[] args) { Player player = null; Player defaultPlayer = new Player(); defaultPlayer.setId(1); defaultPlayer.setName("————undefinedNAME-----"); Player player1 = Optional.ofNullable(player).orElse(defaultPlayer); System.out.println(player1.getName()); } }
運(yùn)行結(jié)果如下:
————undefinedNAME----- Process finished with exit code 0
這里可以看到,我們使用 orElse 方法,當(dāng)一個(gè)變量值為 null 時(shí),返回一個(gè)默認(rèn)值。通過(guò)返回默認(rèn)值,我們明確了 null 的另外一個(gè)含義,對(duì)象存在,但是可能沒(méi)有實(shí)際意義。
Optional 的出現(xiàn),大大改善了我們的 Java 代碼質(zhì)量,減少了 NPE 的可能性,并使得代碼的可讀性大大增強(qiáng)。
通過(guò)使用 Optional,開(kāi)發(fā)人員還能非常自然輕松的使用 Null Object Pattern 模式去處理 Null 問(wèn)題。Optional 是非常值得在項(xiàng)目中大范圍使用的。
“Null的問(wèn)題有哪些”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。