雖然Java 8已經(jīng)出了好幾年了，但是很多朋友可能對于其中的一些特性還是不太了解。甚至對lambda表達(dá)式這個(gè)特性可能會(huì)產(chǎn)生誤解，誤認(rèn)為lambda表達(dá)式會(huì)影響程序的速度。其中也不乏很多誤人子弟的自媒體傳播這些錯(cuò)誤的觀點(diǎn)。

今天我看到一篇自媒體推送的文章，號(hào)稱用Java字節(jié)碼分析為什么lambda表達(dá)式速度慢，但是其中漏洞百出，搞得我忍不住寫了這么一篇文章，為一些受到誤導(dǎo)的朋友糾正一個(gè)概念：lambda表達(dá)式和普通的循環(huán)一樣，不會(huì)影響到程序速度，大家可以放心使用。

因?yàn)轭^條壓縮圖片的緣故，所以對于小段代碼，我用高亮代碼圖片的形式貼出。對于大段代碼，直接貼代碼，可能會(huì)影響大家的閱讀體驗(yàn)。也希望頭條能夠允許上傳高清圖片，讓大家的閱讀體驗(yàn)更好一下。

lambda表達(dá)式是什么

可能還有一些朋友對lambda表達(dá)式還是不太清楚，所以我先介紹一下lambda表達(dá)式的概念。簡單來說lambda表達(dá)式就是匿名函數(shù)，在一些支持匿名函數(shù)的語言中，用不用lambda表達(dá)式其實(shí)不是那么重要。但是因?yàn)镴ava不支持匿名函數(shù)，所以lambda表達(dá)式可以極大的簡化這些場合的代碼。

先來看看一個(gè)例子。假如我們需要在一個(gè)新線程中運(yùn)行代碼，可能需要?jiǎng)?chuàng)建一個(gè)新的Runnable對象。此處使用了Java的一項(xiàng)特性匿名內(nèi)部類，創(chuàng)建了一個(gè)新的臨時(shí)的Runnable對象。但是代碼如你所見非常難看，大段的縮進(jìn)和方括號(hào)，非常影響閱讀。

如果換成了lambda表達(dá)式的實(shí)現(xiàn)，如你所見，代碼非常干凈整潔。

這種形如(a,b)->{ ..... }的表達(dá)式就是lambda表達(dá)式。上面已經(jīng)提到過了，lambda表達(dá)式其實(shí)就是匿名函數(shù)，箭頭前面的括號(hào)內(nèi)部的就是函數(shù)的參數(shù)列表；箭頭后面的括號(hào)內(nèi)部的就是方法體，假如方法體只有一行語句或者表達(dá)式，方法體的括號(hào)可以省略。

lambda表達(dá)式參數(shù)的類型也不需要寫明，編譯器會(huì)自動(dòng)從前面的類型中推斷。在上面的例子中，因?yàn)镽unnable中的run函數(shù)沒有參數(shù)，所以lambda表達(dá)式自然也不需要參數(shù)。你可能會(huì)想到，假如類型中有多個(gè)函數(shù)怎么辦呢？這時(shí)候編譯器無法推斷，程序就會(huì)報(bào)錯(cuò)。這也是Java lambda表達(dá)式的一個(gè)限制，前面的接口類型中只能有一個(gè)函數(shù)聲明。

很多古板的程序員不喜歡這個(gè)特性，認(rèn)為它會(huì)影響到程序的可讀性。但是實(shí)際情況恰恰相反，合理的利用lambda表達(dá)式，不僅不會(huì)污染代碼的可讀性，反而會(huì)大大加強(qiáng)可讀性。lambda表達(dá)式這個(gè)特性，已經(jīng)被現(xiàn)在很多新的編程語言吸收，足見其流行程度。

錯(cuò)誤的測試方法

很多朋友可能對lambda表達(dá)式的運(yùn)行速度產(chǎn)生疑問，會(huì)不會(huì)用了這種寫法，程序的運(yùn)行速度就會(huì)變慢呢？這種擔(dān)心也是完全多余的，Java作為一門經(jīng)典的企業(yè)級(jí)應(yīng)用開發(fā)語言，Oracle對每個(gè)新添加的特性都是小心翼翼的。既然這個(gè)特性被添加到Java語言中，那么足以說明Oracle對其進(jìn)行了深刻的優(yōu)化，運(yùn)行速度絕對是有保證的，就算比普通循環(huán)慢一點(diǎn)，也不會(huì)慢到哪里去。

可能有些人用了錯(cuò)誤的測試方法對lambda表達(dá)式進(jìn)行了測試，發(fā)現(xiàn)速度不如普通的for循環(huán)，然后就得出結(jié)論：lambda表達(dá)式運(yùn)行速度慢。這種測試是完全不負(fù)責(zé)任的。下面的代碼就是一種錯(cuò)誤的測試方法，測試結(jié)果：lambda表達(dá)式用時(shí)150毫秒，而普通循環(huán)用時(shí)7毫秒。因此得出結(jié)論：lambda表達(dá)式慢。大家可以看看代碼，然后想想問題在哪里。

public class LambdaTest { public static int N = 1_0000_0000; static List list = IntStream.range(0, N).boxed().collect(Collectors.toList()); public static void main(String[] args) { long start, end; start = System.currentTimeMillis(); lambdaTest(); end = System.currentTimeMillis(); System.out.println("lambda:" + (end - start)); start = System.currentTimeMillis(); loopTest(); end = System.currentTimeMillis(); System.out.println("loop:" + (end - start)); } static void lambdaTest() { list.forEach(i -> { }); } static void loopTest() { for (int i = 0; i < list.size(); i++) { } }}

好了不賣關(guān)子了，直接說結(jié)論吧。上面測試方法的問題在于，兩種測試方法實(shí)際上根本不對等。lambda表達(dá)式的測試中，雖然方法體是空的，但是程序執(zhí)行的時(shí)候，仍然會(huì)取出每一個(gè)元素，然后再應(yīng)用空的方法。而循環(huán)測試中，真的只是執(zhí)行了一個(gè)空循環(huán)，什么也沒干。因此這種方法測出來的結(jié)論，完全不能證明lambda表達(dá)式比空循環(huán)慢。

公平的測試方法應(yīng)該是怎么樣的呢？對于循環(huán)，一樣要加上取元素和應(yīng)用空方法的操作。為此在空循環(huán)中增加了一部分代碼。這樣測出來的結(jié)果，lambda表達(dá)式和普通循環(huán)一樣都是150毫秒左右，存在幾毫秒的誤差。這次的結(jié)果可以反映真實(shí)情況了，那就是兩者沒有什么速度差別。大家可以自己運(yùn)行代碼試試。

更加實(shí)際的測試

不管怎么說，用空的方法來測試lambda表達(dá)式和普通循環(huán)并不具有實(shí)際意義。所以我換了一種更加實(shí)際的方法，來看看lambda相較于普通的循環(huán)有沒有優(yōu)勢所在。

首先準(zhǔn)備一個(gè)用戶類，這里用到了lombok自動(dòng)生成各種工具方法，為我們節(jié)約時(shí)間。

然后準(zhǔn)備一個(gè)隨機(jī)類，準(zhǔn)備用來生成10萬個(gè)隨機(jī)用戶，來進(jìn)行下一步的操作。

接下來就是測試代碼了。測試代碼其實(shí)也很簡單，隨機(jī)生成一千萬個(gè)用戶，然后進(jìn)行簡單的篩選操作，選出來所有ID大于1000且為偶數(shù)，用戶名以字母a開頭的用戶。兩種測試結(jié)果輸出各自的篩選結(jié)果數(shù)量，以保證結(jié)果是相同的。因?yàn)檫@次的測試比較復(fù)雜，所以可以看出實(shí)際的差異。在我的電腦上，lambda表達(dá)式耗時(shí)100毫秒左右，而循環(huán)耗時(shí)80毫秒左右。可見lambda表達(dá)式雖然比循環(huán)慢一點(diǎn)，但是差距很小，在千萬次循環(huán)的級(jí)別僅差幾十毫秒，對程序的運(yùn)行基本沒有什么影響。

public class LambdaTest { public static int N = 1000_0000; static List list; public static void main(String[] args) { init(); long start, end; start = System.currentTimeMillis(); lambdaTest(); end = System.currentTimeMillis(); System.out.println("lambda:" + (end - start)); start = System.currentTimeMillis(); loopTest(); end = System.currentTimeMillis(); System.out.println("loop:" + (end - start)); } static void init() { list = new ArrayList<>(); for (int i = 0; i < N; i++) { list.add(new User(MyRandom.randomId(), MyRandom.randomUsername())); } } static void lambdaTest() { List r = list.stream() .filter(e -> e.getName().startsWith("a")) .filter(e -> e.getId() % 2 == 0) .filter(e -> e.getId() > 1000) .collect(Collectors.toList()); System.out.println(r.size()); } static void loopTest() { List r = new ArrayList<>(); for (User user : list) { if (user.getName().startsWith("a") && user.getId() % 2 == 0 && user.getId() > 1000) { r.add(user); } } System.out.println(r.size()); }}

這次的測試算是一個(gè)比較實(shí)際的測試了，生成一千萬個(gè)用戶并對其屬性進(jìn)行檢查，過濾出符合條件的用戶。測試的數(shù)量是一千萬，但是測試結(jié)果相差并不大?？梢娖鋵?shí)lambda表達(dá)式并不怎么影響程序的運(yùn)行速度。值得注意的是，這個(gè)測試數(shù)據(jù)完全是保存在內(nèi)存上的，而一般情況下數(shù)據(jù)都是從數(shù)據(jù)庫中加載出來的。這時(shí)候程序的瓶頸在數(shù)據(jù)庫的IO上，就算程序本身速度相差幾十毫秒，相較于數(shù)據(jù)庫的延遲完全可以忽略不計(jì)。

我們的原則是不進(jìn)行過早的優(yōu)化。寫程序的時(shí)候，該怎么寫就怎么寫，lambda這種好用的新特性，該用的時(shí)候就應(yīng)該用，不要害怕它影響性能。等到程序?qū)懲?#xff0c;需要優(yōu)化的時(shí)候，老老實(shí)實(shí)的跑profile，查看程序的瓶頸究竟在哪里。一般情況下程序問題都在數(shù)據(jù)庫IO、算法不夠高效或者是內(nèi)存泄露上，我還真沒聽說過哪個(gè)程序?qū)懙姆浅Ｍ昝?#xff0c;就是被lambda表達(dá)式的速度拖后腿的。實(shí)際上，雖然很多程序員都擔(dān)心lambda表達(dá)式的速度，但是他們的程序完全優(yōu)秀到需要扣lambda表達(dá)式細(xì)節(jié)的這種程度。

反過來說適當(dāng)?shù)臅r(shí)候應(yīng)用這些新特性，反而會(huì)增加代碼的可讀性。就拿上面這個(gè)例子來說，通過三次filter方法過濾程序，最后用collect方法得到結(jié)果，這種流式函數(shù)調(diào)用不僅非常簡單易讀，而且十分優(yōu)雅。反觀循環(huán)版本中的查找操作，只能通過if判斷簡單粗暴的進(jìn)行。這還是一個(gè)簡單的例子，假如查找操作比較復(fù)雜，帶了十幾個(gè)查詢條件的話，那么循環(huán)版本的代碼就會(huì)變成可讀性的災(zāi)難。

這里還有一個(gè)細(xì)節(jié)值得注意。為了最高效的運(yùn)行，循環(huán)版本的代碼只能在一個(gè)if中不斷的增加判斷條件。而lambda表達(dá)式版本則是流式調(diào)用了三次filter語句，但是它們的運(yùn)行結(jié)果相差不大。相信你應(yīng)該也猜到原因了：lambda表達(dá)式和流類庫內(nèi)部做了特殊的優(yōu)化，就算是多個(gè)過濾條件，也會(huì)保證僅僅循環(huán)一次。因此放心大膽的使用lambda表達(dá)式吧！它是編寫代碼的利器！

lambda表達(dá)式，更加強(qiáng)大

寫到這里，本文的內(nèi)容應(yīng)該是差不多了。但是我猜很多朋友看了以后，會(huì)說“你說了這么多，lambda表達(dá)式不還是比循環(huán)慢嘛。說來說去，我還是要繼續(xù)用循環(huán)”。在這里我想說明一下，我的觀點(diǎn)是：lambda表達(dá)式雖然比循環(huán)慢那么一點(diǎn)點(diǎn)，但是帶來的便利性和優(yōu)化空間，遠(yuǎn)遠(yuǎn)不是普通循環(huán)可以比擬的。

上面的例子用了一千萬次的循環(huán)，才得到了幾十毫秒的差距。而實(shí)際情況中，幾千次或者幾萬次的循環(huán)，差距便會(huì)忽略不計(jì)。而且如果加上數(shù)據(jù)庫等外部數(shù)據(jù)源的讀寫延遲，程序的這點(diǎn)運(yùn)行速度完全就不值一提了。所有擔(dān)心lambda表達(dá)式的朋友基本都是杞人憂天。而lambda表達(dá)式帶來的方便確實(shí)實(shí)實(shí)在在的。更重要的是，普通循環(huán)的優(yōu)化非常困難，基本要重寫整個(gè)代碼，在這之中很容易發(fā)生錯(cuò)誤。而lambda表達(dá)式的優(yōu)化則簡單許多。

上面的例子恰好是一個(gè)適合并行化的例子，優(yōu)化方法很簡單，多加一行parallel()方法調(diào)用即可。并行化是另外一個(gè)非常復(fù)雜的主題，但是在這個(gè)例子中，第一數(shù)據(jù)量大(一千萬之多)，第二數(shù)據(jù)易于分割和和合并(ArrayList可以用下標(biāo)直接定位中間的元素)，第三操作都是只讀的(不會(huì)影響到數(shù)據(jù)集本身)，所以正好適合并行化。并行化之后，lambda表達(dá)式的運(yùn)行速度已經(jīng)和循環(huán)相差無幾了(僅差幾毫秒左右)。而普通代碼的并行化，我想這就不是一般程序員可以輕松寫出來的東西了。

好了，本文終于寫完了，其實(shí)本來準(zhǔn)備反駁一下錯(cuò)誤觀點(diǎn)就結(jié)束的，結(jié)果不知不覺寫了這么多。如果大家覺得本文不錯(cuò)的話，歡迎點(diǎn)贊、評(píng)論、轉(zhuǎn)發(fā)，創(chuàng)作不易，還請大家多多支持！在此先謝謝各位了。

總結(jié)

以上是生活随笔為你收集整理的lambda函数if_lambda表达式速度如何呢？看完这篇文章你就明白了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。