自從2013年放棄了Java就再也沒有碰過。期間Java還發布了重大更新:引入lambda,可是那會兒我已經玩了一段時間Scala,對Java已經瞧不上眼。相比Scala Java 8 的lambda仍是too young, too naive!再後來,我有機會學習了一下C#。雖然C#師承Java,但它已是一門很是現代化的語言了,青出於藍而勝於藍。首先是LINQ,提供了一致的,而且很是有表達力的數據操做API。還有像擴展函數,匿名類這些語法特性,用起來也是很是趁手。在技術層面微軟比甲骨文強了不知道多少倍。並且這幾年Java社區也有點蕭條,國內再也沒有出現過相似JavaEye這樣的高質量技術社區。種種緣由都致使我離Java愈來愈遠。java
今年五月份,公司要作新的業務,團隊裏的一些老成員已經被動態語言(主要是Python,還有一些Ruby)折磨的迫不得已,決定從新用回Java。若是不是應爲這,我恐怕不再會用Java了。可是工做嘛,沒有太多選擇的餘地。既然團隊決定了那就硬着頭皮上吧。第一步確定是要了解一下Java8的函數式特性(這但是千呼萬喚始出來啊)。這段時間用下來的整體感受是,沒我想象中的那麼糟,還湊合。下邊總結了一些Java8函數式編程的要點:包括Optional,lambda表達式,Stream程序員
NullPointerException,這個應該是Java裏被人詬病最多的了,有的公司應爲這個損失的錢可不是小數。那在Java 8裏引入了一個Optional類型來解決這個問題。Optional是什麼呢?在函數式編程裏Optional其實就是一個Monad。和其餘編程語言中,好比Scala的Option,Haskell的Maybe殊途同歸。express
在沒有Optional以前,一般作法是返回null,或者程序拋出異常,具體使用要看團隊的規範。但這兩種方式都有各自的問題,我再數落一遍。編程
對於返回null,試想若是全部的方法都由可能返回null,那對方法使用者來講很是恐怖的。到處防,到處防。並且每個null都是一個地雷,哪個地方疏忽了都有可能被「炸」到。json
拋出異常呢,不會有到處寫防護代碼的問題了。可是這種解決方案也是很是「湊合」。Java中異常分爲兩種:受檢異常和非受檢異常。若是使用了非受檢異常程序就會直接被異常中斷,一般在Spring中是提倡直接拋出非受檢異常的,再搭配上Spring的攔截器,省去了程序員很多麻煩。閉包
受檢異常就不同了,使用受檢異常毫不會比使用null好到哪裏去。在方法的簽名上附帶上函數可能拋出的異常,讓方法使用者去判斷如何處理這個異常。看起來這是一種負責任的作法,事實確是把本身不想作的事情(異常處理)交給了方法調用者。Jackson類庫就是這樣,每次使用它序列化對象時都得考慮是try-catch仍是修改方法簽名(告知外部方法處理)。很是不友好。app
再有一點,拋出Exception意味着這個函數(方法)是帶有反作用的。函數反作用會給程序設計帶來沒必要要的麻煩,引入潛在的bug,並下降程序的可讀性。試想一個函數從其簽名上來看應該返回一個訂單,可是結果倒是它不總可以返回訂單,有時還拋出異常。編程語言
終於能夠開始說Optional了。用白話形容,Optional就是一個盒子。當你拿到這個盒子的時候,盒子可能裏邊有想要的東西,但也可能只是一個空盒子。因此原來返回null,或者跑出異常的方法咱們能夠直接返回一個盒子。來一個例子,這個例子來改進一下Jackson的API:ide
public Optional<String> json(Object object) { String jsonString = null; try { jsonString = new ObjectMapper().writeValueAsString(object); } catch (JsonProcessingException e) { e.printStackTrace(); } return Optional.ofNullable(jsonString); }
這個新的方法再也不讓調用者處理異常,也不存在返回null的風險。可是問題來了,拿到了這個「盒子」咱們接下來該怎麼辦啊?彆着急,Optional提供了很是豐富的接口,幾乎可以知足你平常所有的使用場景。如下接口都是很是經常使用的:函數式編程
判斷Optional是否有值:op.isPresent()
基於Optional封裝的結果作一些操做,並繼續返回一個Optional類型的結果:op.map(str -> str.trim())
合併兩個Optional爲一個:op.flatMap(s -> op2.map(s2 -> s1 + s2))
只有在有值的狀況下才進行一些操做:op.ifPresent(s -> s.trim())
若是Optional有值則返回,沒有返回給定的默認值:op.orElse("hello")
還有一些其它的接口,請自行查閱Optional API文檔。注意在使用Optional的時候不推薦直接使用get()
,由於這樣可能會拋出異常。
我曾經把方法的參數也置爲Optional類型,可是的到了IDEA的警告:Optional不推薦用做方法的參數。我隨後Google了一些帖子,獲得的答案就是:對於方法的參數,null可能比Optional更好用一些。在Scala和Haskell裏是沒有這樣的限制的,你能夠任意的把Option和Maybe當作參數。由於在Scala和Haskell中Option和Maybe是基本的數據類型。Java中的Optional則只是一種受限的實現,主要的目的是提供一種清晰,友好的表達「空」的方式。
lambda表達式在上邊咱們已經用到了,好比op.map(str -> str.trim())
,str -> str.trim()
就是一個lambda表達式。Java和其餘大多數支持lambda的語言同樣採用箭頭:-> 來標示lambda。在箭頭的的左邊是0或多個參數,箭頭的右邊是一個表達式或者代碼塊。咱們來看幾個lambda的實例:
() -> {} // No parameters; result is void () -> 42 // No parameters, expression body () -> null // No parameters, expression body () -> { return 42; } // No parameters, block body with return () -> { System.gc(); } // No parameters, void block body () -> { // Complex block body with returns if (true) return 12; else { int result = 15; for (int i = 1; i < 10; i++) result *= i; return result; } } (int x) -> x+1 // Single declared-type parameter (int x) -> { return x+1; } // Single declared-type parameter (x) -> x+1 // Single inferred-type parameter x -> x+1 // Parentheses optional for // single inferred-type parameter (String s) -> s.length() // Single declared-type parameter (Thread t) -> { t.start(); } // Single declared-type parameter s -> s.length() // Single inferred-type parameter t -> { t.start(); } // Single inferred-type parameter (int x, int y) -> x+y // Multiple declared-type parameters (x, y) -> x+y // Multiple inferred-type parameters (x, int y) -> x+y // Illegal: can't mix inferred and declared types (x, final y) -> x+y // Illegal: no modifiers with inferred types
憶苦思甜,咱們先來回憶一下在沒有lambda以前若是咱們想爲Optional實現map功能咱們應該如何作。一般作法是這樣的:
interface Function<E> { public E exec(E e); } public static <E> Optional<E> map(Optional<E> original, Function<E> fn) { if(!original.isPresent()) return Optional.empty(); E e = original.get(); return Optional.of(fn.exec(e)); } map(Optional.of(1), new Function<Integer>() { @Override public Integer exec(final Integer i) { return i * i; } });
使用一個接口來承載一個函數。在Java中函數不是一等公民,是不能用來傳遞的。因此只能採用這種「曲線救國」的方式。Java 8則是把這種」曲線救國」拿到了檯面上,並昭告天下,同時還對lambda提供了一些語法支持。因此上邊咱們看到的一些很是簡短的lambda表達式,其實都是一個interface+一個抽象方法。
咱們能夠藉助IDE(我使用的是IDEA)把上邊列舉的一些lambda表達式抽做變量,IDE能夠幫助咱們自動推導類型,咱們來觀察下他們的類型。
Runnable runnable = () -> {}; DoubleSupplier doubleSupplier = () -> 42; Callable vCallable = () -> null; IntToDoubleFunction intToDoubleFunction = (int x) -> x + 1; IntBinaryOperator intBinaryOperator = (int x, int y) -> x + y;
像Callable,Runnable,DoubleSupplier這些接口就是Java內置的函數式接口。Java還提供了很是多的函數式接口,你能夠在java.util.function下找到他們。函數式接口相比普通的接口有一個限制:只能有一個抽象方法。並且Java還提供了一個註解:@FunctionalInterface。你能夠本身聲明新的接口併爲它加上這個註解。
@FunctionalInterface interface Function<E> { public E exec(E e); }
上邊說過Java 8對lambda提供了一些額外支持,這種額外的支持就是一些已經實現的方法也可以用做lambda表達式。咱們看一個例子:
Optional<Integer> arg = ...; arg.ifPresent(System.out::print);
print是PrintStream中已經實現的方法。這種用法至關於:x -> System.out.print(x)
。對於類的靜態方法,類的實例方法,對象的實例方法均可以使用::操做符用在須要傳遞lambda表達式的地方。
咱們接下來比較一下Java8先後,實現閉包的異同。先來看一下閉包的概念。
閉包是指能夠包含自由變量的代碼塊。自由變量沒有在當前代碼塊內或者任何全局上下文中定義的,而是在定義代碼塊的環境中定義(執行環境上下文)。因此一次閉包過程即要執行的代碼塊中的自由變量得到了執行環境上下文中的值。
在Java 8以前閉包能夠經過內部類來實現。
import java.util.HashMap; import java.util.Map; class Cache { private Map<String, Object> contents = new HashMap<>(); class Monitor { public Integer size() { return Cache.this.contents.size(); } } } public class Library { public static void main(String[] args) { Cache cache = new Cache(); Cache.Monitor monitor = cache.new Monitor(); System.out.println("Cache size is: " + monitor.size()); } }
contents是自由變量,cache提供執行上下文,monitor.size()觸發閉包執行。若是有其餘函數式語言背景的人看到這種方式可能會感到很是的奇怪,但這就是Java的方式。再來看一下Java 8中如何實現一個閉包。
因爲有了lambda表達式,建立一個閉包就至關簡潔了:(Integer x) -> x + y
。並且這種形式也很是的functional。接着建立一個執行上下文:
int y = 1; Function<Integer, Integer> add = (Integer x) -> x + y; add.apply(3); // 4
兩種風格迥異,單從語法表達力來講確定是lambda更勝一籌。但社區裏也有人擔憂這種簡潔性會影響Java的簡單,形成代碼風格不一致,下降代碼可讀性增長維護成本。仁者見仁智者見智吧,我確定是支持使用lambda的。代碼風格的話團隊最好能有一個標準,不要好東西給用爛了。
Stream能夠說是集合處理的殺手鐗(就當它是殺手鐗吧)。咱們先拿Stream來玩一玩:Stream.of(0, 1, 2, 3, 4, 5, 6, 7, 8, 9).map(i -> i * i).reduce(0, (i, r) -> r + i)
這個例子是計算0到9的平方和。咱們能夠想象一下若是用for循環實現一樣的邏輯,代碼行數至少是四五倍。
下面咱們對這個程序做一個分解:第一部分是初始化Stream,加載數據Stream.of(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
;第二部分是定義數據轉化:map(i -> i * i)
,第三部分是聚合結果:reduce(0, (i, r) -> r + i)
。這基本囊括了Stream全部能做以及要做的事情。
Stream類提供了提供了幾個工廠方法來構建一個新的Stream。咱們先來看一下of,of用來構建有限個數的Stream,好比咱們構建一個包含十個元素的Stream:Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 0)
。
Stream還有兩個方法:generate, iterate,這兩個函數都是用來構造無限流。
generate就收一個無參函數:Supplier<T> s
,當須要一個常數或隨機數隊列的時候可使用這個函數。 Stream.generate(() -> 1)
。
iterate會生成一個迭代的Stream,你須要指定初始值,以及迭代函數。Stream.iterate(5, x -> x * 10)
。
除了上邊的幾種方式,咱們還可以方便的將集合轉化爲Stream,好比List,Set。你只須要在集合變量上.stream()
就能夠獲得一個Stream。實際場景中應用更多的仍是將一個集合類轉化爲Stream。
轉化函數咱們最經常使用的是map和filter。Stream也提供了flatMap函數,可是它的使用比較受限,因此本來flatMap的威力大大減弱了。下邊具體解釋一下map和filter函數。map的工做原理是:爲全部的元素應用一個函數。爲了加強理解舉個現實生活中的例子:有一簍子蘋果,咱們要爲它們都貼上標籤。map過程就是拿出每一個蘋果貼上標籤而後放到另外一個簍子裏。filter就是一個過濾器,過濾出咱們想要的東西。好比,咱們要從上邊簍子裏挑選出大於500克的蘋果。逐個拿出蘋果稱重,若是大於500克留在簍子中,則放到新簍子中。因此操做數據時,直接往這兩個例子上套用就能夠了。
看一個例子,計算全部學生的總分,並取出總分大於450分的學生:students.map(s -> calculate(s.getScore())).filter(score -> score > 450);
。
聚合函數主要用來收集最終的結果。好比,求出一個數字隊列的總和,求最大最小值,或將結果收集到一個集合中。下邊咱們來操做一個Integer的Stream,首先求出最大值和最小值:
Stream<Integer> ints = Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 0); Optional<Integer> max = ints.max(Integer::compare); Optional<Integer> min = ints.min(Integer::compare);
接下來咱們求出這個數列的總和,求和咱們可使用reduce函數。reduce函數起到一個彙總的做用。它和hadoop中的reduce,fork/join中的join做用都是同樣的。
Integer sum = ints.reduce(0, (x, y) -> x + y);
咱們爲reduce傳遞了兩個參數,第一個是初始值(執行累加操做的第一個值),第二個是求和lambda。
Java 8還爲基本類型提供了相應的Stream,好比IntStream,LongStream。使用IntStream咱們直接使用sum就能夠執行求和操做:
IntStream intsStream = ints.mapToInt(i -> i); intsStream.sum();
下邊咱們看一下收集函數:collect()。collect()函數是將Stream中的元素放到一個新的容器中。咱們上邊的例子中求出了總分大於450分的同窗,咱們把它放到一個List中,看一下如何操做:
students.map(s -> calculate(s.getScore())).filter(score -> score > 450).collect(Collectors.toList())
以上Java 8的函數式特性所有講完,這只是一個入門講解,不能涵蓋全部的特性及工具類。有興趣的同窗,自行探索java.util.stream包。