Java 8为什么需要Lambda表达式

最新推荐文章于 2024-04-08 10:49:04 发布

tnblog技术分享～

最新推荐文章于 2024-04-08 10:49:04 发布

阅读量845

点赞数

分类专栏： java

java 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

函数编程在C#、Python、JavaScript中都得到充分体现。而Java直到最新的Java 8才开始正式支持函数编程，最明显的改进就是对Lamba表达式的支持。正如C#之父Anders Hejlsberg在那篇文章编程语言大趋势中所讲，未来的编程语言将逐渐融合各自的特性，而不存在单纯的声明式语言（如之前的Java）或者函数编程语言。将来声明式编程语言借鉴函数编程思想，函数编程语言融合声明式编程特性...这几乎是一种必然趋势。如下图所示：

影响力较大的三个趋势

那具体而言我们为什么需要Lambda表达式呢？难道Java的OO和命令式编程（imperative programming）特性不够强大吗？下面让我们来分析下其原因。

1、内部循环和外部循环

先看一个大家耳熟能详的例子：

 
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
 
 
 
for (int number : numbers) {
 
    System.out.println(number);
 
}

是不是很常见呢？这个叫外部循环（External Iteration）。但是外循环有什么问题呢？简单来说存在下面三个缺点：

只能顺序处理List中的元素（process one by one）
不能充分利用多核CPU
不利于编译器优化

而如果利用内部循环，代码写成下面这样：

 
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
 
 
 
numbers.forEach((Integer value) -> System.out.println(value));

这样就能规避上面的三个问题：

不一定需要顺序处理List中的元素，顺序可以不确定
可以并行处理，充分利用多核CPU的优势
有利于JIT编译器对代码进行优化

类似的C#从4.0版本开始也支持集合元素并行处理，代码如下：

 
List<int> nums = new List<int> { 1, 2, 3, 4, 5 };
 
Parallel.ForEach(nums, (value) =>
 
{
 
   Console.WriteLine(value);
 
});

2、传递行为，而不仅仅是传值

如果你使用C#有一段时间的话，那么你很可能已经明白这个标题的意思了。在C#中，经常看到一些函数的参数是Action或者Func类型，比如下面这个：

 
public class ArticleDac {
 
   ...
 
   public Article GetArticles(Func<IDbSet<Article>, Article> func)   // 这里传递的就是行为
 
   {
 
      using(var db = xx) {
 
         return func(db.Articles);
 
      } 
 
   }
 
   ...
 
}
 
// 下面是调用
 
int articleId = 119;
 
var firstArticle = new ArticleDac().GetArticles(
 
    articleDbSet =>
 
    articleDbSet.AsQueryable().FirstOrDefault(x => x.id == articleId)
 
);

看不懂？没关系。我们先来看一个体现传值局限性的场景吧，上代码：

 
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中所有偶数求和的方法sumAllEven，如下：

 
public int sumAllEven(List<Integer> numbers) {
 
    int total = 0;
 
    for (int number : numbers) {
 
        if (number % 2 == 0) {
 
            total += number;
 
        }
 
    }
 
    return total;
 
}

又有一天，我们需要增加第三个方法：对List中所有大于3的元素求和，那是不是继续加下面的方法呢?

 
public int sumAllEven(List<Integer> numbers) {
 
    int total = 0;
 
    for (int number : numbers) {
 
        if (number > 3) {
 
            total += number;
 
        }
 
    }
 
    return total;
 
}

比较这三个方法，我们发现了一个很明显的“代码臭味”—— 代码重复（详情参考《重构》），三个方法的唯一区别之处在于if判断这一行代码。如果脱离这里的上下文，我们会怎么做呢？我首先会先想到利用策略模式重构代码如下：

 
public interface Strategy {
 
   public boolean test(int num);
 
}
 
 
 
public class SumAllStrategy {
 
   public boolean test(int num) {
 
      return true;
 
   }
 
}
 
 
 
public class SumAllEvenStrategy {
 
   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;
 
   }
 
}
 
 
 
 
 
// 调用
 
ContextClass context = new ContextClass();
 
context.sumAll(numbers);

设计模式在这里发挥了作用，OO特性还是蛮强大的！但是这是唯一的解决方案吗（当然不考虑用其他设计模式来解决，因为都是OO范畴！）？当然有，该轮到Java 8 Lambda表达式中的谓词（Predicate）该发挥作用了！

 
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);

代码是不是比上面简洁很多了？语义应该也很明确，就不多解释了，如果实在看不懂，请参考我的另外一篇文章： http://www.cnblogs.com/feichexia/archive/2012/11/15/Java8_LambdaExpression.html 从这里也可以看出未引入Lambda表达式之前的Java代码的冗长（Java这点被很多人诟病）。

当然C#早已经支持这种用法，用C#改写上面的代码如下，是不是与上面的代码极其类似呢？

 
public int SumAll(List<int> numbers, Func<int, bool> func) {
 
    var total = 0;
 
    foreach (var number in numbers) {
 
        if (func(number)) {
 
            total += number;
 
        }
 
    }
 
 
 
    return total;
 
}
 
 
 
SumAll(numbers, n => true);
 
SumAll(numbers, n => n % 2 == 0);
 
SumAll(numbers, n => n > 3);

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");
 
    }
 
}

我们必须这样调用：

 
Resource resource = new Resource();
 
try {
 
    resource.operate();
 
} finally {
 
    resource.dispose();
 
}

因为对资源对象resource执行operate方法时可能抛出RuntimeException，所以需要在finally语句块中释放资源，防止可能的内存泄漏。

但是有一个问题，如果很多地方都要用到这个资源，那么就存在很多段类似这样的代码，这很明显违反了DRY（Don't Repeat It Yourself）原则。而且如果某位程序员由于某些原因忘了用try/finally处理资源，那么很可能导致内存泄漏。那咋办呢？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();
 
        }
 
    }
 
}

调用代码如下：

`1`	`Resource.withResource(resource -> resource.operate());`

外部要访问Resource不能通过它的构造函数了（private），只能通过withResource方法了，这样代码清爽多了，而且也完全杜绝了因人为疏忽而导致的潜在内存泄漏。

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;
 
        }
 
    }
 
}

这段代码有什么问题？没错，可读性非常差。第一步，我们利用《重构》一书中的最基础的提取小函数重构手法来重构代码如下：

 
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，代码的意图清晰多了，但是可读性仍然欠佳，因为循环内嵌套一个if分支，if分支内又嵌套另外一个分支，于是继续重构代码如下：

 
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));

现在代码够清晰了，这是典型的“流水线”风格代码。但是等等，现在的代码执行会占用更多空间（三个List）和时间，我们来分析下。首先第二版代码的执行流程是这样的：

 
isEven: 1
 
isEven: 2
 
doubleIt: 2
 
isGreaterThan5: 2
 
isEven: 3
 
isEven: 4
 
doubleIt: 4
 
isGreaterThan5: 4
 
8

而我们的第三版代码的执行流程是这样的：

 
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

步骤数是13:9，所以有时候重构得到可读性强的代码可能会牺牲一些运行效率（但是一切都得实际衡量之后才能确定）。那么有没有“三全其美”的实现方法呢？即：

代码可读性强
代码执行效率不比第一版代码差
空间消耗小

Streams come to rescue! Java 8提供了stream方法，我们可以通过对任何集合对象调用stream()方法获得Stream对象，Stream对象有别于Collections的几点如下：

不存储值：Streams不会存储值，它们从某个数据结构的流水线型操作中获取值（“酒肉穿肠过”）
天生的函数编程特性：对Stream对象操作能得到一个结果，但是不会修改原始数据结构
Laziness-seeking（延迟搜索）：Stream的很多操作如filter、map、sort和duplicate removal(去重）可以延迟实现，意思是我们只要检查到满足要求的元素就可以返回
可选边界：Streams允许Client取足够多的元素直到满足某个条件为止。而Collections不能这么做

上代码：

 
System.out.println(
 
    numbers.stream()
 
            .filter(Lazy::isEven)
 
            .map(Lazy::doubleIt)
 
            .filter(Lazy::isGreaterThan5)
 
            .findFirst()
 
);

现在的执行流程是：

 
isEven: 1
 
isEven: 2
 
doubleIt: 2
 
isGreaterThan5: 4
 
isEven: 3
 
isEven: 4
 
doubleIt: 4
 
isGreaterThan5: 8
 
IntOptional[8]

流程基本和第二版代码一致，这归功于Laziness-seeking特性。怎么理解呢？让我来构造下面这个场景：

 
Stream流对象要经过下面这种流水线式处理：
 
过滤出偶数 => 乘以2 => 过滤出大于5的数 => 取出第一个数
 
 
 
注意：=> 左边的输出是右边的输入

而Laziness-seeking意味着我们在每一步只要一找到满足条件的数字，马上传递给下一步去处理并且暂停当前步骤。比如先判断1是否偶数，显然不是；继续判断2是否偶数，是偶数；好，暂停过滤偶数操作，将2传递给下一步乘以2，得到4；4继续传递给第三步，4不满足大于5，所以折回第一步；判断3是否偶数，不是；判断4是否偶数，是偶数；4传递给第二步，乘以2得到8；8传递给第三步，8大于5；所以传递给最后一步，直接取出得到IntOptional[8]。

IntOptional[8]只是简单包装了下返回的结果，这样有什么好处呢？如果你接触过Null Object Pattern的话就知道了，这样可以避免无谓的null检测。

本文完，希望对大家有所帮助，O(∩_∩)O

http://www.open-open.com/lib/view/open1365053088359.html