1.
1

2.
Lambda
學習目標
• 認識Lambda語法
• 運用方法參考
• 瞭解介面預設方法
• 善用Functional與Stream API
• Lambda、平行化與非同步處理
2

3.
Lambda語法概覽
• 使用者名稱依長度排序
3

4.
• 使用Lambda表示式
4

5.
方法參考
5

6.
• 依名稱長度排序
• 重用既有方法實作，可避免到處寫下Lambda
運算式
6

7.
• 依字典順序排序名稱呢？
7

8.
• 按照字典順序排序，但忽略大小寫差異
• 方法參考不僅避免了重複撰寫Lambda運算式
，還能讓程式碼更為清楚
8

9.
Lambda表示式與函式介面
• Lambda表示式（Expression）
9

10.
• 目標型態（Target type）
• Lambda表示式本身不代表任何型態的實例
10

11.
• Lambda沒有導入新型態來作為Lambda表示
式的型態
• 基於interface語法定義函式介面，作為表
示式的目標型態
– 要求僅具單一抽象方法
11

12.
• 匿名類別不是不好，只不過有其應用的場合
• 只想關心參數及實作本體
12

13.
• 只關心方法簽署的參數與回傳定義，然而忽
略方法名稱
13

14.
• interface語法做了演進，允許有預設方法
• 新標註@FunctionalInterface被引入
• 編譯錯誤
14

15.
Lambda遇上this與final
15

16.
• Lambda 表示式本體中this，來自Lambda
的周圍環境（Context）
• 顯示兩次"Hello, World!"
16

17.
• 以下在JDK8以後不會有錯：
• Lambda表示式不能修改捕獲的區域變數值
17

18.
方法與建構式參考
• 只要靜態方法的方法簽署中，參數與傳回值
定義相同，也可以使用靜態方法來定義函式
介面實作
18

19.
• 避免到處寫下Lambda表示式，儘量運用既有
的API實作，也可以改善可讀性
19

20.
• 函式介面實作可以參考靜態方法之外，還可
以參考特定物件的實例方法
20

21.
• 函式介面實作也可以參考類別定義的非靜態
方法，函式介面會試圖用第一個參數作為方
法接收者
21

22.
• 建構式參考可重用既有API的類別建構式
22

23.
介面預設方法
• 在JDK8以後，interface定義時可以有預
設實作
23

24.
• 預設方法必須使用default關鍵字修飾，預
設權限為public
• 預設方法不能使用資料成員
24

25.
• 共用相同實作
25

26.
• 從JDK9開始，介面可以定義private方法
26

27.
辨別方法的實作版本
• 實作介面是廣義的多重繼承
• 介面也可以被繼承，而抽象方法或預設方法
都會繼承下來
• 子介面再以抽象方法重新定義父介面已定義
的抽象方法，通常是為了文件化
27

28.
• 父介面有個預設方法，子介面再度宣告與父
介面相同的方法簽署，但沒有寫出default
• 子介面就直接重新定義該方法為抽象方法了
• BiIterable的forEach()方法沒有實作了
28

29.
• 兩個父介面定義相同方法簽署的預設方法，
就會引發衝突
• 解決的方式是明確重新定義
– 假設Part與Canvas介面都定義了default的
draw()方法
29

30.
• 如果類別實作的兩個介面擁有相同的父介面
，其中一個介面重新定義了父介面的預設方
法，而另一個介面沒有
– 實作類別會採用重新定義的版本
• 若子類別繼承了父類別同時又實作某介面，
而父類別的方法與介面中的預設方法具有相
同方法簽署
– 採用父類別的方法定義。
30

31.
• 簡單來說，類別的定義優先於介面的定義，
若有重新定義，就以重新定義為主，必要時
使用介面與super指定預設方法
31

32.
• JDK8除了讓介面可以定義預設方法，也允許
在介面中定義靜態方法
• 從JDK9開始，可以定義為private的靜態
方法
32

33.
Iterable
• forEach()預設方法
33

34.
Iterator
• forEachRemaining()的預設實作
34

35.
Comparator
35

36.
使用Optional取代null
• Java Collection API及JSR166參與者之一Doug
Lea的話：
• 圖靈獎得主、快速排序發明者Tony Hoare：
36
"Null sucks."
"I call it my billion-dollar mistake."

37.
NullPointerException
• null的根本問題在於語意含糊不清
– 可以是「不存在」、「沒有」、「無」或「空」
的概念
• 當開發者想到「嘿！這邊可以沒有東西…」
、「嗯！沒什麼東西可以傳回…」，就不假
思索地傳回null
• 然後使用者就總是忘了檢查null，引發各種
可能的錯誤。
37

38.
• 確認使用null的時機與目的，使用明確語義
• 開發者於方法中傳回null，通常代表著客戶
端必須檢查是否為null，並在null的情況
下使用預設值
38

39.
39

40.
• 如果呼叫getNickName()時忘了檢查傳回
值，執行結果就會直接顯示null
• 若後續的執行流程牽涉到至關重要的結果，
程式快樂地繼續執行下去，錯誤可能到某個
執行環節才會發生，造成不可預期的結果
40

41.
• getNickName()傳回Optional<String>
• 方法若傳回Optional實例，表示該實例可
能包裹也可能不包裹值
41

42.
• 客戶端要意識到必須進行檢查，若不檢查就
直接呼叫Optional的get()方法：
• java.util.NoSuchElementException
，這實現了速錯（Fail fast）的概念
42

43.
• 使用orElse()方法，指定值不存在時的替
代值：
43

44.
• 程式庫無法說改就改，可使用Optional的
ofNullable()來銜接程式庫會傳回null
的方法
44

45.
標準API的函式介面
• Consumer
• Function
• Predicate
• Supplier
45

46.
Consumer函式介面
• 接受一個引數，處理後不傳回值
46

47.
• Iterable的forEach方法：
47

48.
• 對於基本型態有IntConsumer、
LongConsumer、DoubleConsumer
• BiConsumer接受兩個物件作為引數的介面
• 還有ObjIntConsumer、
ObjLongConsumer、
ObjDoubleConsumer
48

49.
Function函式介面
• 接受一個引數，執行後傳回結果
• 就像數學函數y=f(x)
49

50.
• 子介面UnaryOperator，參數與傳回值都
是相同型態
• 基本型態的函式轉換，有IntFunction、
LongFunction、DoubleFunction、
IntToDoubleFunction、
IntToLongFunction…
50

51.
• 接受兩個引數、傳回一個結果
51

52.
Predicate函式介面
• 接受一個引數、傳回boolean值
52

53.
• BiPredicate接受兩個引數，傳回
boolean值
• 基本型態對應的函式介面，則有
IntPredicate、LongPredicate、
DoublePredicate
53

54.
Supplier函式介面
• 不接受任何引數就傳回值
54

55.
使用Stream進行管線操作
55

56.
• 管線（Pipeline）操作風格
• 惰性求值（Lazy evaluation）
– 外部迭代（External iteration）
– 內部迭代（Internal iteration）
56

57.
• 絕大多數Stream不需要呼叫close()方法
• 除了一些I/O操作，例如Files.lines()、
Files.list()與Files.walk()方法
• 建議這類操作可以搭配嘗試關閉資源語法
57

58.
• 管線基本上包括了幾個部份：
– 來源（Source）
– 零或多個中介操作（Intermediate operation）
– 一個最終操作（Terminal operation）
58

59.
59

60.
• 每個中介操作隱藏了細節，隱含了效率改進
的空間，也鼓勵開發者多利用這類風格
– 避免撰寫一些重複流程
– 思考目前的複雜演算中，實際上會是由哪些小任
務完成
60

61.
61

62.
• for迴圈若滲雜了許多小任務，會使for迴圈
中的程式碼艱澀難懂
• Stream只能迭代一次
62

63.
Stream的reduce與collect
• 求得一組員工的男性平均年齡：
63

64.
• 求得一組員工的男性最大年齡：
64

65.
• 類似的流程結構
• 從閱讀程式碼角度來看，無法一眼察覺程式
意圖
65

66.
66

67.
67

68.
68

69.
• 將男性員工收集至另一個List<Employee>
• Collector主要的四個方法：
– supplier()
– accumulator()
– combiner()
– finisher()
69

70.
70

71.
71

72.
72

73.
73

74.
關於flatMap()方法
• 巢狀或瀑布式的流程
74

75.
75

76.
• 將Optional<T>轉換為Optional<U>的方
式可由外部指定
76

77.
77

78.
• flatMap()就像從盒子取出另一盒子（flat
是平坦化的意思）
• Lambda表示式指定了前一盒子的值與下個盒
子間的轉換關係
• 避免巢狀或瀑布式的複雜檢查流程
78

79.
• 若沒辦法修改傳回Optional型態怎麼辦？
79

80.
80

81.
81

82.
Stream相關API
• Arrays的stream()
• Stream、IntStream、DoubleStream等
都有of()靜態方法，也各有generate()與
iterate()靜態方法
• IntStream有range()與rangeClosed()
82

83.
• CharSequence新增chars()與
codePoints()
• java.util.Random類別
83

84.
Optional的API增強
84

85.
85

86.
86

87.
Stream的API增強
87

88.
• 若試著運行底下程式，會從x為4開始迭代：
• 若想設定迭代中止的條件：
88

89.
• takeWhile()與dropWhile()方法
89

90.
Stream與平行化
• 想獲得平行處理能力
• Java在API的設計上，希望你進行平行處理
時，能有明確的語義
90

91.
• 不代表就會平行處理而使得執行必然變快
• 必須思考處理過程是否能夠分而治之而後合
併結果
91

92.
• Stream實例若具有平行處理能力，處理過程
會試著分而治之
92

93.
• 希望最後順序是照著原來Stream來源的順序
• 使用forEachOrdered()這類有序處理時
，可能會失去平行化部份（甚至全部）優勢
• 有些中介操作亦有可能發生類似情況，例如
sorted()方法 93

94.
• API文件基本上會記載終結操作時是否依來
源順序
94

95.
• 在collect()操作時若想有平行效果，必須
符合以下三個條件：
– Stream必須有平行處理能力。
– Collector必須有
Collector.Characteristics.CONCURREN
T特性。
– Stream是無序或者Collector具有
Collector.Characteristics.UNORDERED
特性。
95

96.
• API在處理小任務時，不應該進行干擾
• 會引發ConcurrentModifiedException
96

97.
• 思考目前任務是由哪些小任務組成
97

98.
• 一次只做一件事
98

99.
• 避免寫出以下的程式：
99

100.
• 這樣的程式不僅不易理解，若試圖進行平行
化處理時：
• added10s的順序並不照著numbers的順序
100

101.
• 一次處理一個任務的版本，可以簡單地改為
平行化版本，又沒有順序問題：
101

102.
Arrays與平行化
• 針對超長陣列的平行化操作，Arrays新增：
– parallelPrefix()
– parallelSetAll()
– parallelSort()
102

103.
CompletableFuture
103

104.
• 回呼（Callback）風格
• 回呼地獄（Callback hell）
104

105.
105

106.
• 若第一個CompletableFuture任務完成後
，想繼續以非同步方式處理結果
106

107.
• CompletableFuture也有個
thenCompose()（以及非同步的
thenComposeAsnyc()版本），作用就類
似flatMap()
107

108.
CompletableFuture增強
108

109.
109

110.
110