Java 8為什么需要Lambda表達式
函數(shù)編程在C#、Python、JavaScript中都得到充分體現(xiàn)。而Java直到最新的Java 8才開始正式支持函數(shù)編程，最明顯的改進就是對Lamba表達式的支持。正如C#之父Anders Hejlsberg在那篇文章 編程語言大趨勢 中所講，未來的編程語言將逐漸融合各自的特性，而不存在單純的聲明式語言（如之前的Java）或者單純的函數(shù)編程語言。將來聲明式編程語言借鑒函數(shù)編程思想，函數(shù)編程語言融合聲明式編程特性...這幾乎是一種必然趨勢。如下圖所示：
影響力較大的三個趨勢
那具體而言我們?yōu)槭裁葱枰狶ambda表達式呢？難道Java的OO和命令式編程（imperative programming）特性不夠強大嗎？下面讓我們來分析下其原因。
1、內(nèi)部循環(huán)和外部循環(huán)
先看一個大家耳熟能詳?shù)睦樱?/p>
- List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
- for (int number : numbers) {
- System.out.println(number);
- }
是不是很常見呢？這個叫外部循環(huán)（External Iteration）。但是外部循環(huán)有什么問題呢？簡單來說存在下面三個缺點：
1.只能順序處理List中的元素（process one by one）
2.不能充分利用多核CPU
3.不利于編譯器優(yōu)化
而如果利用內(nèi)部循環(huán)，代碼寫成下面這樣：
- List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
- numbers.forEach((Integer value) -> System.out.println(value));
這樣就能規(guī)避上面的三個問題：
1.不一定需要順序處理List中的元素，順序可以不確定
2.可以并行處理，充分利用多核CPU的優(yōu)勢
3.有利于JIT編譯器對代碼進行優(yōu)化
類似的C#從4.0版本開始也支持集合元素并行處理，代碼如下：
- List<int> nums = new List<int> { 1, 2, 3, 4, 5, 6 };
- Parallel.ForEach(nums, (value) =>
- {
- Console.WriteLine(value);
- });
#p#
2、傳遞行為，而不僅僅是傳值
如果你使用C#有一段時間的話，那么你很可能已經(jīng)明白這個標(biāo)題的意思了。在C#中，經(jīng)?？吹揭恍┖瘮?shù)的參數(shù)是Action或者Func類型，比如下面這個：
- public class ArticleDac {
- ...
- public Article GetArticles(Func<IDbSet<Article>, Article> func) // 這里傳遞的就是行為
- {
- using(var db = xx) {
- return func(db.Articles);
- }
- }
- ...
- }
- // 下面是調(diào)用
- int articleId = 119;
- var firstArticle = new ArticleDac().GetArticles(
- articleDbSet =>
- articleDbSet.AsQueryable().FirstOrDefault(x => x.id == articleId)
- );
看不懂？沒關(guān)系。我們先來看一個體現(xiàn)傳值局限性的場景吧，上代碼：
- List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
- public int sumAll(List<Integer> numbers) {
- int total = 0;
- for (int number : numbers) {
- total += number;
- }
- return total;
- }
sumAll算法很簡單，完成的是將List中所有元素相加。某一天如果我們需要增加一個對List中所有偶數(shù)求和的方法sumAllEven，如下：
- public int sumAllEven(List<Integer> numbers) {
- int total = 0;
- for (int number : numbers) {
- if (number % 2 == 0) {
- total += number;
- }
- }
- return total;
- }
又有一天，我們需要增加第三個方法：對List中所有大于3的元素求和，那是不是繼續(xù)加下面的方法呢?
- public int sumAllEven(List<Integer> numbers) {
- int total = 0;
- for (int number : numbers) {
- if (number > 3) {
- total += number;
- }
- }
- return total;
- }
比較這三個方法，我們發(fā)現(xiàn)了一個很明顯的“代碼臭味”—— 代碼重復(fù)（詳情參考《重構(gòu)》），三個方法的唯一區(qū)別在于if判斷這一行代碼。如果脫離這里的上下文，我們會怎么做呢？我首先會先想到利用策略模式重構(gòu)代碼如下：
- public interface Strategy {
- public boolean test(int num);
- }
- public class SumAllStrategy implements Strategy {
- public boolean test(int num) {
- return true;
- }
- }
- public class SumAllEvenStrategy implements Strategy {
- public boolean test(int num) {
- return num % 2 == 0;
- }
- }
- public class ContextClass {
- private Strategy stragegy = null;
- private final static Strategy DEFAULT_STRATEGY = new SumAllStrategy();
- public ContextClass() {
- this(null);
- }
- public ContextClass(Stragegy stragegy) {
- if(strategy != null) {
- this.strategy = strategy;
- }
- else {
- this.strategy = DEFAULT_STRATEGY;
- }
- }
- public int sumAll(List<Integer> numbers) {
- int total = 0;
- for (int number : numbers) {
- if (strategy.test(number)) {
- total += number;
- }
- }
- return total;
- }
- }
- // 調(diào)用
- ContextClass context = new ContextClass();
- context.sumAll(numbers);
設(shè)計模式在這里發(fā)揮了作用，OO特性還是蠻強大的！但這是唯一的解決方案嗎（當(dāng)然不考慮用其他設(shè)計模式來解決，因為都是OO范疇！）？當(dāng)然有，該輪到Java 8 Lambda表達式中的謂詞（Predicate）發(fā)揮作用了！
- public int sumAll(List<Integer> numbers, Predicate<Integer> p) {
- int total = 0;
- for (int number : numbers) {
- if (p.test(number)) {
- total += number;
- }
- }
- return total;
- }
- sumAll(numbers, n -> true);
- sumAll(numbers, n -> n % 2 == 0);
- sumAll(numbers, n -> n > 3);
代碼是不是比上面簡潔很多了？語義應(yīng)該也很明確，就不多解釋了，如果實在看不懂，請參考我的另外一篇文章： http://www.cnblogs.com/feichexia/archive/2012/11/15/Java8_LambdaExpression.html 從這里也可以看出未引入Lambda表達式之前的Java代碼的冗長（Java這點被很多人詬?。?。
當(dāng)然C#早已經(jīng)支持這種用法，用C#改寫上面的代碼如下：
- public int SumAll(IEnumerable<int> numbers, Predicate<int> predicate) {
- return numbers.Where(i => predicate(i)).Sum();
- }
- SumAll(numbers, n => true);
- SumAll(numbers, n => n % 2 == 0);
- SumAll(numbers, n => n > 3);
#p#
3、Consumer與Loan Pattern
比如我們有一個資源類Resource：
- public class Resource {
- public Resource() {
- System.out.println("Opening resource");
- }
- public void operate() {
- System.out.println("Operating on resource");
- }
- public void dispose() {
- System.out.println("Disposing resource");
- }
- }
我們必須這樣調(diào)用：
- Resource resource = new Resource();
- try {
- resource.operate();
- } finally {
- resource.dispose();
- }
因為對資源對象resource執(zhí)行operate方法時可能拋出RuntimeException，所以需要在finally語句塊中釋放資源，防止可能的內(nèi)存泄漏。
但是有一個問題，如果很多地方都要用到這個資源，那么就存在很多段類似這樣的代碼，這很明顯違反了DRY（Don't Repeat It Yourself）原則。而且如果某位程序員由于某些原因忘了用try/finally處理資源，那么很可能導(dǎo)致內(nèi)存泄漏。那咋辦呢？Java 8提供了一個Consumer接口，代碼改寫為如下：
- public class Resource {
- private Resource() {
- System.out.println("Opening resource");
- }
- public void operate() {
- System.out.println("Operating on resource");
- }
- public void dispose() {
- System.out.println("Disposing resource");
- }
- public static void withResource(Consumer<Resource> consumer) {
- Resource resource = new Resource();
- try {
- consumer.accept(resource);
- } finally {
- resource.dispose();
- }
- }
- }
調(diào)用代碼如下：
- Resource.withResource(resource -> resource.operate());
外部要訪問Resource不能通過它的構(gòu)造函數(shù)了（private），只能通過withResource方法了，這樣代碼清爽多了，而且也完全杜絕了因人為疏忽而導(dǎo)致的潛在內(nèi)存泄漏。
#p#
4、stream+laziness => efficiency
像之前一樣先來一段非常簡單的代碼：
- List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
- for (int number : numbers) {
- if (number % 2 == 0) {
- int n2 = number * 2;
- if (n2 > 5) {
- System.out.println(n2);
- break;
- }
- }
- }
這段代碼有什么問題？ 沒錯，可讀性非常差。第一步，我們利用《重構(gòu)》一書中的最基礎(chǔ)的提取小函數(shù)重構(gòu)手法來重構(gòu)代碼如下：
- public boolean isEven(int number) {
- return number % 2 == 0;
- }
- public int doubleIt(int number) {
- return number * 2;
- }
- public boolean isGreaterThan5(int number) {
- return number > 5;
- }
- for (int number : numbers) {
- if (isEven(number)) {
- int n2 = doubleIt(number);
- if (isGreaterThan5(n2)) {
- System.out.println(n2);
- break;
- }
- }
- }
OK，代碼的意圖清晰多了，但是可讀性仍然欠佳，因為循環(huán)內(nèi)嵌套一個if分支，if分支內(nèi)又嵌套另外一個分支，于是繼續(xù)重構(gòu)代碼如下：
- public boolean isEven(int number) {
- return number % 2 == 0;
- }
- public int doubleIt(int number) {
- return number * 2;
- }
- public boolean isGreaterThan5(int number) {
- return number > 5;
- }
- List<Integer> l1 = new ArrayList<Integer>();
- for (int n : numbers) {
- if (isEven(n)) l1.add(n);
- }
- List<Integer> l2 = new ArrayList<Integer>();
- for (int n : l1) {
- l2.add(doubleIt(n));
- }
- List<Integer> l3 = new ArrayList<Integer>();
- for (int n : l2) {
- if (isGreaterThan5(n)) l3.add(n);
- }
- System.out.println(l3.get(0));
現(xiàn)在代碼夠清晰了，這是典型的“流水線”風(fēng)格代碼。但是等等，現(xiàn)在的代碼執(zhí)行會占用更多空間（三個List）和時間，我們來分析下。首先第二版代碼的執(zhí)行流程是這樣的：
- isEven: 1
- isEven: 2
- doubleIt: 2
- isGreaterThan5: 2
- isEven: 3
- isEven: 4
- doubleIt: 4
- isGreaterThan5: 4
- 8
而我們的第三版代碼的執(zhí)行流程是這樣的：
- isEven: 1
- isEven: 2
- isEven: 3
- isEven: 4
- isEven: 5
- isEven: 6
- doubleIt: 2
- doubleIt: 4
- doubleIt: 6
- isGreaterThan5: 2
- isGreaterThan5: 4
- isGreaterThan5: 6
- 8
步驟數(shù)是13:9，所以有時候重構(gòu)得到可讀性強的代碼可能會犧牲一些運行效率（但是一切都得實際衡量之后才能確定）。那么有沒有“三全其美”的實現(xiàn)方法呢？即：
1.代碼可讀性強
2.代碼執(zhí)行效率不比第一版代碼差
3.空間消耗小
Streams come to rescue! Java 8提供了stream方法，我們可以通過對任何集合對象調(diào)用stream()方法獲得Stream對象，Stream對象有別于Collections的幾點如下：
1.不存儲值：Streams不會存儲值，它們從某個數(shù)據(jù)結(jié)構(gòu)的流水線型操作中獲取值（“酒肉穿腸過”）
2.天生的函數(shù)編程特性：對Stream對象操作能得到一個結(jié)果，但是不會修改原始數(shù)據(jù)結(jié)構(gòu)
3.Laziness-seeking（延遲搜索）：Stream的很多操作如filter、map、sort和duplicate removal(去重）可以延遲實現(xiàn)，意思是我們只要檢查到滿足要求的元素就可以返回
4.可選邊界：Streams允許Client取足夠多的元素直到滿足某個條件為止。而Collections不能這么做
上代碼：
- System.out.println(
- numbers.stream()
- .filter(Lazy::isEven)
- .map(Lazy::doubleIt)
- .filter(Lazy::isGreaterThan5)
- .findFirst()
- );
現(xiàn)在的執(zhí)行流程是：
- isEven: 1
- isEven: 2
- doubleIt: 2
- isGreaterThan5: 4
- isEven: 3
- isEven: 4
- doubleIt: 4
- isGreaterThan5: 8
- IntOptional[8]
流程基本和第二版代碼一致，這歸功于Laziness-seeking特性。怎么理解呢？讓我來構(gòu)造下面這個場景：
- Stream流對象要經(jīng)過下面這種流水線式處理：
- 過濾出偶數(shù) => 乘以2 => 過濾出大于5的數(shù) => 取出第一個數(shù)
- 注意：=> 左邊的輸出是右邊的輸入
而Laziness-seeking意味著 我們在每一步只要一找到滿足條件的數(shù)字，馬上傳遞給下一步去處理并且暫停當(dāng)前步驟。比如先判斷1是否偶數(shù)，顯然不是；繼續(xù)判斷2是否偶數(shù)，是偶數(shù)；好，暫停過濾偶數(shù)操作，將2傳遞給下一步乘以2，得到4；4繼續(xù)傳遞給第三步，4不滿足大于5，所以折回第一步；判斷3是否偶數(shù)，不是；判斷4是否偶數(shù)，是偶數(shù)；4傳遞給第二步，乘以2得到8；8傳遞給第三步，8大于5；所以傳遞給最后一步，直接取出得到 IntOptional[8]。
IntOptional[8]只是簡單包裝了下返回的結(jié)果，這樣有什么好處呢？如果你接觸過Null Object Pattern的話就知道了，這樣可以避免無謂的null檢測。
參考自：
http://java.dzone.com/articles/why-we-need-lambda-expressions
http://java.dzone.com/articles/why-we-need-lambda-expressions-0
