前面兩篇文章介紹了什麼是響應式編程？和響應式流的特性，一味講概念終是枯燥，還是上手敲一敲代碼實在感受一下響應式編程的「手感」吧。
（3）lambda與函數式——響應式Spring的道法術器這一節，我們先了解一下lambda與函數式（已經了解的朋友可以直接跳到1.3.2），熟悉一下如何使用Reactor進行響應式編程，然後使用Spring Boot2，基於Spring 5的Webflux和Reactive Spring Data逐步開發一個「Hello world」級別的RESTful service。
1.3.1 lambda與函數式在響應式編程中，lambda與函數式的出鏡率相當高，以至於網上經常有朋友直接用「函數響應式編程」用在「響應式編程」的介紹中。這兩個詞的異同一直存在爭議，其區別雖然不像「JavaScript與Java」、「雷鋒塔與雷峰」那麼大，但隨便混用還是會顯得非常不專業：
本系列文章討論的都是「響應式編程」，關於「函數響應式編程」，你就當沒聽過，並謹慎地使用它就好了。
1.3.1.1 lambda表達式書回正傳，為什麼響應式編程中會經常用到lambda與函數式呢？不知你對1.1.3節的一段偽代碼是否還有印象：
cartEventStream
.map(cartEvent -> cartEvent.getProduct().getPrice() * cartEvent.getQuantity())
...
cartEventStream是一個數據流，其中的元素就是一個一個的cartEvent，map方法能夠對cartEvent進行「轉換/映射」，這裡我們將其轉換為double類型的金額。
除了轉換/映射（map）外，還有過濾（filter）、提供（supply）、消費（consume）等等針對流中元素的操作邏輯/策略，而邏輯/策略通常用方法來定義。
在Java 8之前，這就有些麻煩了。我們知道，Java是面向對象的程式語言，除了少數的原生類型外，一切都是對象。用來定義邏輯/策略的方法不能獨立存在，必須被包裝在一個對象中。比如我們比較熟悉的Comparator，其唯一的方法compare表示一種比較策略，在使用的時候，需要包裝在一個對象中傳遞給使用該策略的方法。舉例說明（源碼）：
@Test
public void StudentCompareTest() {
@Data @AllArgsConstructor class Student {
private int id;
private String name;
private double height;
private double score;
}
List<Student> students = new ArrayList<>();
students.add(new Student(10001, "張三", 1.73, 88));
students.add(new Student(10002, "李四", 1.71, 96));
students.add(new Student(10003, "王五", 1.85, 88));
class StudentIdComparator<S extends Student> implements Comparator<S> {
@Override
public int compare(S s1, S s2) {
return Integer.compare(s1.getId(), s2.getId());
}
}
students.sort(new StudentIdComparator<>());
System.out.println(students);
}
@Data和@AllArgsConstructor是lombok提供的註解，能夠在編譯的字節碼中生成構造方法、getter/setter、toString等方法。依賴如下：
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.16.20</version>
</dependency>
註：本節及以後，關於maven的依賴，可自行至maven搜索庫中查詢新的合適版本。
StudentIdComparator中固化了一種針對Student.id的比較策略，當對students進行排序的時候，將StudentIdComparator的對象傳給sort方法。輸出順序如下：
[Student(id=10001, name=張三, height=1.73, score=88.0), Student(id=10002, name=李四, height=1.71, score=96.0), Student(id=10003, name=王五, height=1.85, score=88.0)]
假設這時候我們需要對學生的身高或分數進行排序，再定義Comparator的實現類有些麻煩了，而且沒必要，「傳統」的簡化方式是直接傳入匿名內部類：
students.sort(new Comparator<Student>() {
@Override
public int compare(Student s1, Student s2) {
return Double.compare(s1.getHeight(), s2.getHeight());
}
});
但其實，我們會發現，無論哪種比較策略，只有compare方法內的代碼發生變化，也就是說sort方法關心的只是傳入的兩個參數Student s1, Student s2以及返回的結論return Double.compare(s1.getHeight(), s2.getHeight())這一句比較策略，何不只保留它們呢？
students.sort((Student s1, Student s2) -> {return Double.compare(s1.getHeight(), s2.getHeight());});
這樣看起來代碼就少多了。其中
(Student s1, Student s2) -> {return Double.compare(s1.getHeight(), s2.getHeight())}
就是lambda表達式，lambda表達式的語法如下：
(type1 arg1, type2 arg2...) -> { body }
->前後分別表示參數和方法體。從代碼編寫方式上來說，這就可以算作是「函數式」編程範式了，因為我們傳給sort的是一個lambda表達式的形式定義的「函數」，這個「函數」有輸入和輸出，在開發者看起來是赤裸裸的，沒有使用對象封裝起來的。
「函數式」編程範式的核心特點之一：函數是"一等公民"。
所謂"一等公民"（first class），指的是函數與其他數據類型一樣，處於平等地位，可以賦值給其他變量，也可以作為參數，傳入另一個函數，或者作為別的函數的返回值。
但也僅僅是「看起來」是「函數式」的了，Java終究是面向對象的語言，List.sort的方法定義仍然是接受一個Comparator對象作為參數的。但是一定要糾結Java是不是純正的函數式語言嗎？沒這個必要，實用至上嘛。
既然如此，問題來了，sort是如何將這個lambda「看做」一個Comparator對象的呢？
不難發現，Comparator接口僅有一個抽象方法，因此sort也就不難「推斷」lambda所定義的輸入參數和方法體表示的正是這個唯一的抽象方法compare。
1.3.1.2 函數式接口像Comparator這樣的只有一個抽象方法的接口，叫做函數式接口（Functional Interface）。與Comparator類似，其他函數式接口的唯一的抽象方法也可以用lambda來表示。
我們看一下Comparator的源碼，發現其多了一個@FunctionalInterface的註解，用來表明它是一個函數式接口。標記了該註解的接口有且僅有一個抽象方法，否則會報編譯錯誤。
再看一下其他的僅有一個抽象方法的接口，比如Runnable和Callable，發現也都在Java 8之後加了@FunctionalInterface註解。對於Runnable來說，接口定義如下：
@FunctionalInterface
public interface Runnable {
public abstract void run();
}
不難推測，其lambda的寫法應該是 () -> { body }，它不接收任何參數，方法體中也無return返回值，用起來像這樣：
new Thread(() -> {doSomething();});
此外，隨lambda一同增加的還有一個java.util.function包，其中定義了一些常見的函數式接口的。比如：
Function，接受一個輸入參數，返回一個結果。參數與返回值的類型可以不同，我們之前的map方法內的lambda就是表示這個函數式接口的；
Consumer，接受一個輸入參數並且無返回的操作。比如我們針對數據流的每一個元素進行列印，就可以用基於Consumer的lambda；
Supplier，無需輸入參數，只返回結果。看接口名就知道是發揮了對象工廠的作用；
Predicate，接受一個輸入參數，返回一個布爾值結果。比如我們在對數據流中的元素進行篩選的時候，就可以用基於Predicate的lambda；
…
1.3.1.3 簡化的lambda以lambda作為參數的方法能夠推斷出來lambda所表示的是哪個函數式接口的那個抽象方法。類似地，編譯期還可以做更多的推斷。我們再回到最初的Comparator的例子並繼續簡化如下lambda表達式：
students.sort((Student s1, Student s2) -> {return Double.compare(s1.getHeight(), s2.getHeight());});
1）首先，傳入的參數類型是可以推斷出來的。因為students是以Student為元素的數組List，其sort方法自然接收Comparator<? super Student>的對象作為參數，這一切都可以通過泛型約束。
students.sort((s1, s2) -> {return Double.compare(s1.getHeight(), s2.getHeight());});
2）如果只有一個return語句的話，return和方法體的大括號都可以省略(compare方法的返回值就是lambda返回值）：
students.sort((s1, s2) -> Double.compare(s1.getHeight(), s2.getHeight()));
3）注意到，Comparator接口還提供了豐富的靜態方法，比如：
public static<T> Comparator<T> comparingDouble(ToDoubleFunction<? super T> keyExtractor) {
Objects.requireNonNull(keyExtractor);
return (Comparator<T> & Serializable)
(c1, c2) -> Double.compare(keyExtractor.applyAsDouble(c1), keyExtractor.applyAsDouble(c2));
}
這個方法為我們包裝好了Double.compare。它接收一個返回類型為Double的函數式接口ToDoubleFunction，可以看做是Function，用lambda表示的話就是student -> student.getHeight()。
因此，我們的sort方法又可以寫作：
students.sort(Comparator.comparingDouble((student) -> student.getHeight()));
其一，對於只有一個參數的lambda來說，參數外邊的小括號可以省略：
students.sort(Comparator.comparingDouble(student -> student.getHeight()));
其二，對於僅有一個方法調用的lambda方法體來說，通常又可以用類::方法進一步簡化，以上代碼又可以進一步簡化為：
students.sort(Comparator.comparingDouble(Student::getScore));
這裡是調用參數所代表對象的某個方法，與之類似的還有比如：
使用類::方法這種寫法是不是更加有函數式的感覺了呢，似乎真是把函數作為參數傳遞給某個方法了呢~
就不再繼續舉例了，以上這些形形×××的簡化你可能會感覺難以記憶，其實無需記憶，多數IDE都能夠提供簡化建議的。
1.3.1.4 總結在程式語言的世界裡，Java就像是一個穩健的中年人，它始終將語言的向後兼容性和穩定性放在首位，不會隨隨便便因為某種語言特性或語法糖就心動，但是對於有顯著預期收益的語言特性也會果斷出擊，泛型如此，lambda亦是如此，或許對它們的引入都不夠徹底和完美，但卻足夠實用，能夠給開發者帶來很大便利。這應該也是Java語言能夠持續保持活力的原因之一吧！
至於函數式方面更加複雜的概念，這裡就不多介紹了。