java8 streams_Java 8 Friday：使用Streams API时的10个细微错误
java8 streams
在Data Geekery ，我們喜歡Java。 而且，由于我們真的很喜歡jOOQ的流暢的API和查詢DSL ，我們對Java 8將為我們的生態系統帶來什么感到非常興奮。
Java 8星期五
每個星期五，我們都會向您展示一些不錯的教程風格的Java 8新功能，這些功能利用了lambda表達式，擴展方法和其他出色的功能。 您可以在GitHub上找到源代碼 。
使用Streams API時的10個細微錯誤
我們已經完成了所有SQL錯誤列表：
- Java開發人員在編寫SQL時常犯的10個錯誤
- Java開發人員在編寫SQL時犯的10個常見錯誤
- Java開發人員在編寫SQL時再犯的10個常見錯誤（您不會相信最后一個）
但是我們還沒有用Java 8列出前10個錯誤列表！ 在今天的場合（ 13日星期五 ），我們將趕上您使用Java 8時應用程序中出現的問題（這不會發生在我們身上，因為我們將Java 6留在了另一個Java 6上）而）。
1.意外重用流
想打賭，這至少每個人都會發生一次。 像現有的“流”（例如InputStream ）一樣，您只能使用一次流。 以下代碼不起作用：
IntStream stream = IntStream.of(1, 2); stream.forEach(System.out::println);// That was fun! Let's do it again! stream.forEach(System.out::println);您將獲得：
java.lang.IllegalStateException: stream has already been operated upon or closed因此在使用流時要小心。 只能執行一次。
2.意外創建“無限”流
您無需注意即可輕松創建無限流。 請看以下示例：
// Will run indefinitely IntStream.iterate(0, i -> i + 1).forEach(System.out::println);如果您將流設計為無限的，那么流的全部要點就是事實。 唯一的問題是，您可能不需要這樣做。 因此，請確保始終設置適當的限制：
// That's better IntStream.iterate(0, i -> i + 1).limit(10).forEach(System.out::println);3.意外地創建“微妙”的無限流
我們不能這么說。 您最終將意外地創建無限流。 以以下流為例：
IntStream.iterate(0, i -> ( i + 1 ) % 2).distinct().limit(10).forEach(System.out::println);所以…
- 我們生成交替的0和1
- 那么我們只保留不同的值，即單個0和單個1
- 那么我們將流的大小限制為10
- 然后我們消耗它
好吧…… distinct()操作不知道提供給iterate()方法的函數只會產生兩個不同的值。 它可能會期望更多。 因此它將永遠消耗流中的新值，并且永遠不會達到limit(10) 。 不幸的是，您的應用程序停頓了。
4.意外地創建“微妙”的并行無限流
我們確實需要堅持，您可能會意外地嘗試消耗無限的流。 讓我們假設您認為 distinct()操作應并行執行。 您可能正在編寫：
IntStream.iterate(0, i -> ( i + 1 ) % 2).parallel().distinct().limit(10).forEach(System.out::println);現在，我們已經看到，這種情況將永遠發生。 但至少在以前，您僅消耗計算機上的一個CPU。 現在，您可能會消耗其中的四個，可能會意外地無限消耗流，從而幾乎占據整個系統。 真不好 之后，您可能可以硬重啟服務器/開發計算機。 在爆炸之前，最后查看一下我的筆記本電腦的外觀：
如果我是筆記本電腦，這就是我想去的方式。
5.混合操作順序
那么，為什么我們堅持要您絕對意外地創建無限流？ 這很簡單。 因為您可能只是偶然地這樣做。 如果您切換limit()和distinct()的順序，則可以完美地使用上述流：
IntStream.iterate(0, i -> ( i + 1 ) % 2).limit(10).distinct().forEach(System.out::println);現在產生：
0 1為什么？ 因為我們首先將無限流限制為10個值（0 1 0 1 0 1 0 1 0 1），然后再將有限流減小為無限個流中包含的不同值（0 1）。
當然，這在語義上可能不再正確，因為您確實希望從一組數據中獲得前10個不同的值（您剛好“忘記”了數據是無限的）。 沒有人真正想要10個隨機值，然后才將它們減小到與眾不同。
如果您來自SQL背景，則可能不會期望有這種差異。 以SQL Server 2012為例。 以下兩個SQL語句相同：
-- Using TOP SELECT DISTINCT TOP 10 * FROM i ORDER BY ..-- Using FETCH SELECT * FROM i ORDER BY .. OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY因此，作為SQL專家，您可能沒有意識到流操作順序的重要性。
6.再次混合操作順序
說到SQL，如果您是MySQL或PostgreSQL人，則可能會習慣LIMIT .. OFFSET子句。 SQL充滿了微妙的怪癖，這就是其中之一。 該OFFSET子句應用首先 ，在SQL Server 2012中的（即建議的SQL：2008標準的）語法。
如果將MySQL / PostgreSQL方言直接轉換為流，則可能會出錯：
IntStream.iterate(0, i -> i + 1).limit(10) // LIMIT.skip(5) // OFFSET.forEach(System.out::println);以上收益
5 6 7 8 9是。 它不會在9之后繼續，因為現在先應用limit() ，生成（0 1 2 3 4 5 6 7 8 9）。 之后應用skip() ，將流減少到（5 6 7 8 9）。 不是您可能想要的。
注意LIMIT .. OFFSET與"OFFSET .. LIMIT"陷阱！
7.使用過濾器遍歷文件系統
以前我們已經在博客上寫過 。 似乎一個好主意是使用過濾器遍歷文件系統：
Files.walk(Paths.get(".")).filter(p -> !p.toFile().getName().startsWith(".")).forEach(System.out::println);上面的流似乎僅在非隱藏目錄（即不以點開頭的目錄）中移動。 不幸的是，您再次犯了＃5和＃6錯誤。 walk()已經生成了當前目錄的整個子目錄流。 雖然懶惰，但邏輯上包含所有子路徑。 現在，過濾器將正確過濾出名稱以點“。”開頭的路徑。 例如.git或.idea將不屬于結果流。 但是這些路徑將是： .\.git\refs或.\.idea\libraries 。 不是你想要的。
現在，不要通過編寫以下內容解決此問題：
Files.walk(Paths.get(".")).filter(p -> !p.toString().contains(File.separator + ".")).forEach(System.out::println);盡管這將產生正確的輸出，但仍將通過遍歷完整的目錄子樹，然后遞歸到“隱藏”目錄的所有子目錄來實現。
我猜您將不得不再次使用舊的JDK 1.0 File.list() 。 好消息是， FilenameFilter和FileFilter都是功能接口。
8.修改流的后備集合
在迭代List ，一定不要在迭代主體中修改相同的列表。 在Java 8之前確實如此，但是對于Java 8流，它可能變得更加棘手。 考慮以下來自0..9的列表：
// Of course, we create this list using streams: List<Integer> list = IntStream.range(0, 10).boxed().collect(toCollection(ArrayList::new));現在，假設我們要在使用每個元素時將其刪除：
list.stream()// remove(Object), not remove(int)!.peek(list::remove).forEach(System.out::println);有趣的是，這將適用于某些元素！ 您可能獲得的輸出是以下內容：
0 2 4 6 8 null null null null null java.util.ConcurrentModificationException如果我們在捕獲到該異常之后對列表進行了自省，那么將會發現一個有趣的發現。 我們會得到：
[1, 3, 5, 7, 9]嘿，它對所有奇數都有效。 這是一個錯誤嗎？ 不，它看起來像個功能。 如果您正在研究JDK代碼，則可以在ArrayList.ArraListSpliterator找到以下注釋：
/** If ArrayLists were immutable, or structurally immutable (no* adds, removes, etc), we could implement their spliterators* with Arrays.spliterator. Instead we detect as much* interference during traversal as practical without* sacrificing much performance. We rely primarily on* modCounts. These are not guaranteed to detect concurrency* violations, and are sometimes overly conservative about* within-thread interference, but detect enough problems to* be worthwhile in practice. To carry this out, we (1) lazily* initialize fence and expectedModCount until the latest* point that we need to commit to the state we are checking* against; thus improving precision. (This doesn't apply to* SubLists, that create spliterators with current non-lazy* values). (2) We perform only a single* ConcurrentModificationException check at the end of forEach* (the most performance-sensitive method). When using forEach* (as opposed to iterators), we can normally only detect* interference after actions, not before. Further* CME-triggering checks apply to all other possible* violations of assumptions for example null or too-small* elementData array given its size(), that could only have* occurred due to interference. This allows the inner loop* of forEach to run without any further checks, and* simplifies lambda-resolution. While this does entail a* number of checks, note that in the common case of* list.stream().forEach(a), no checks or other computation* occur anywhere other than inside forEach itself. The other* less-often-used methods cannot take advantage of most of* these streamlinings.*/現在，檢查當我們告訴流產生sorted()結果時會發生什么：
list.stream().sorted().peek(list::remove).forEach(System.out::println);現在將產生以下“預期”輸出
0 1 2 3 4 5 6 7 8 9和流消費后的清單？ 它是空的：
[]因此，所有元素都將被消耗并正確刪除。 sorted()操作是“有狀態中間操作” ，這意味著后續操作不再對后備集合進行操作，而是對內部狀態進行操作。 現在從列表中刪除元素是“安全的”！
好吧，我們真的可以嗎？ 讓我們繼續進行parallel() ， sorted()移除：
list.stream().sorted().parallel().peek(list::remove).forEach(System.out::println);現在產生：
7 6 2 5 8 4 1 0 9 3并且列表包含
[8]真是的 我們沒有刪除所有元素！ 解決此流難題的任何人都可以免費獲得啤酒（ 和jOOQ貼紙 ）！
這一切看起來都是相當隨機和微妙的，我們只能建議您在使用流時不要真正修改后備集合。 就是行不通。
9.忘記實際消耗流
您認為以下信息流有什么作用？
IntStream.range(1, 5).peek(System.out::println).peek(i -> { if (i == 5) throw new RuntimeException("bang");});閱讀此書時，您可能會認為它將打印（1 2 3 4 5），然后引發異常。 但這是不正確的。 它什么也不會做。 流只是坐在那里，從未被消耗過。
與任何流暢的API或DSL一樣，您實際上可能會忘記調用“終端”操作。 當您使用peek()時尤其如此，因為peek()與forEach()非常相似。
當您忘記調用execute()或fetch()時， jOOQ可能會發生相同的情況：
DSL.using(configuration).update(TABLE).set(TABLE.COL1, 1).set(TABLE.COL2, "abc").where(TABLE.ID.eq(3));哎呀。 沒有execute()
是的，“最佳”方法-1-2次警告！
10.并行流死鎖
現在這才是真正的禮物！
如果您未正確同步所有事物，則所有并發系統都可能陷入死鎖。 雖然找不到現實的例子很明顯，但找到強制的例子很明顯。 保證下面的parallel()流會陷入死鎖：
Object[] locks = { new Object(), new Object() };IntStream.range(1, 5).parallel().peek(Unchecked.intConsumer(i -> {synchronized (locks[i % locks.length]) {Thread.sleep(100);synchronized (locks[(i + 1) % locks.length]) {Thread.sleep(50);}}})).forEach(System.out::println);請注意Unchecked.intConsumer()的使用，該函數將功能性IntConsumer接口轉換為org.jooq.lambda.fi.util.function.CheckedIntConsumer ，允許拋出已檢查的異常。
好。 您的機器運氣不好。 這些線程將永遠被阻塞！
好消息是，用Java編寫死鎖的教科書示例從未如此簡單！
有關更多詳細信息，另請參見Brian Goetz對Stack Overflow的此問題的回答 。
結論
借助流和功能性思維，我們將遇到大量新的，細微的錯誤。 這些錯誤很少可以預防，除非通過實踐和保持專注。 您必須考慮如何訂購您的手術。 您必須考慮流是否可能是無限的。
流（和lambda）是一個非常強大的工具。 但是首先需要掌握的工具。
翻譯自: https://www.javacodegeeks.com/2014/06/java-8-friday-10-subtle-mistakes-when-using-the-streams-api.html
java8 streams
總結
以上是生活随笔為你收集整理的java8 streams_Java 8 Friday：使用Streams API时的10个细微错误的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： linux 进程用户和组（linux 进
- 下一篇： Java面试准备：15个Java面试问题