在Data Geekery ，我們喜歡Java。 而且，由于我們真的很喜歡jOOQ的流暢的API和查詢DSL ，我們對(duì)Java 8將為我們的生態(tài)系統(tǒng)帶來什么感到非常興奮。

Java 8星期五

每個(gè)星期五，我們都會(huì)向您展示一些不錯(cuò)的教程風(fēng)格的Java 8新功能，這些功能利用了lambda表達(dá)式，擴(kuò)展方法和其他好東西。 您可以在GitHub上找到源代碼 。

使用Streams API時(shí)的10個(gè)細(xì)微錯(cuò)誤

我們已經(jīng)完成了所有SQL錯(cuò)誤列表：

• Java開發(fā)人員在編寫SQL時(shí)常犯的10個(gè)錯(cuò)誤
• Java開發(fā)人員在編寫SQL時(shí)犯的10個(gè)常見錯(cuò)誤
• Java開發(fā)人員在編寫SQL時(shí)又犯了10個(gè)常見錯(cuò)誤（您不會(huì)相信最后一個(gè)）

但是我們還沒有用Java 8列出十大錯(cuò)誤列表！ 在今天的情況下（ 13日星期五 ），我們將趕上您使用Java 8時(shí)應(yīng)用程序中出現(xiàn)的問題（這不會(huì)發(fā)生在我們身上，因?yàn)槲覀儗ava 6留在了另一個(gè)Java 6上）而）。

1.意外重用流

想打賭，這至少每個(gè)人都會(huì)發(fā)生一次。 像現(xiàn)有的“流”（例如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);

您會(huì)得到：

java.lang.IllegalStateException: stream has already been operated upon or closed

因此，在使用流時(shí)要小心。 只能執(zhí)行一次。

2.意外創(chuàng)建“無限”流

您可以很容易地創(chuàng)建無限流而無需注意。 請(qǐng)看以下示例：

// Will run indefinitely IntStream.iterate(0, i -> i + 1).forEach(System.out::println);

如果您將流設(shè)計(jì)為無限的，那么流的全部要點(diǎn)就是事實(shí)。 唯一的問題是，您可能不需要這樣做。 因此，請(qǐng)確保始終設(shè)置適當(dāng)?shù)南拗?#xff1a;

// That's better IntStream.iterate(0, i -> i + 1).limit(10).forEach(System.out::println);

3.意外地創(chuàng)建“微妙”的無限流

我們不能這么說。 您最終將意外地創(chuàng)建無限流。 以以下流為例：

IntStream.iterate(0, i -> ( i + 1 ) % 2).distinct().limit(10).forEach(System.out::println);

所以…

• 我們生成交替的0和1
• 那么我們只保留不同的值，即單個(gè)0和單個(gè)1
• 那么我們將流的大小限制為10
• 然后我們消耗它

好吧…… distinct()操作不知道提供給iterate()方法的函數(shù)只會(huì)產(chǎn)生兩個(gè)不同的值。 它可能會(huì)期望更多。 因此它將永遠(yuǎn)消耗流中的新值，并且永遠(yuǎn)不會(huì)達(dá)到limit(10) 。 不幸的是，您的應(yīng)用程序停頓了。

4.意外地創(chuàng)建“微妙”的并行無限流

我們確實(shí)需要堅(jiān)持，您可能會(huì)意外地嘗試消耗無限的流。 讓我們假設(shè)您認(rèn)為 distinct()操作應(yīng)該并行執(zhí)行。 您可能正在寫：

IntStream.iterate(0, i -> ( i + 1 ) % 2).parallel().distinct().limit(10).forEach(System.out::println);

現(xiàn)在，我們已經(jīng)看到，這種情況將永遠(yuǎn)發(fā)生。 但至少在以前，您僅消耗計(jì)算機(jī)上的一個(gè)CPU。 現(xiàn)在，您可能會(huì)消耗其中的四個(gè)，可能會(huì)意外地?zé)o限消耗流，從而幾乎占據(jù)整個(gè)系統(tǒng)。 真不好 之后，您可能可以硬重啟服務(wù)器/開發(fā)計(jì)算機(jī)。 在爆炸之前，最后查看一下我的筆記本電腦的外觀：

如果我是筆記本電腦，這就是我想要的方式。

5.混合操作順序

那么，為什么我們堅(jiān)持要您絕對(duì)無意中創(chuàng)建無限流？ 這很簡(jiǎn)單。 因?yàn)槟赡苤皇桥既坏剡@樣做。 如果您切換limit()和distinct()的順序，則可以完美地使用上述流：

IntStream.iterate(0, i -> ( i + 1 ) % 2).limit(10).distinct().forEach(System.out::println);

現(xiàn)在產(chǎn)生：

0 1

為什么？ 因?yàn)槲覀兪紫葘o限流限制為10個(gè)值（0 1 0 1 0 1 0 1 0 1），然后再將有限流減少為無限值包含在其中（0 1）。

當(dāng)然，這在語義上可能不再正確，因?yàn)槟_實(shí)希望從一組數(shù)據(jù)中獲得前10個(gè)不同的值（您剛好“忘記”了數(shù)據(jù)是無限的）。 沒有人真正想要10個(gè)隨機(jī)值，然后才將它們減小到與眾不同。

如果您來自SQL背景，那么您可能不會(huì)想到這樣的差異。 以SQL Server 2012為例。 以下兩個(gè)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專家，您可能沒有意識(shí)到流操作順序的重要性。

6.再次混合操作順序

說到SQL，如果您是MySQL或PostgreSQL的人，則可能會(huì)習(xí)慣LIMIT .. OFFSET子句。 SQL充滿了微妙的怪癖，這就是其中之一。 該OFFSET子句應(yīng)用首先 ，在SQL Server 2012中的（即建議的SQL：2008標(biāo)準(zhǔn)的）語法。

如果將MySQL / PostgreSQL的方言直接轉(zhuǎn)換為流，則可能會(huì)出錯(cuò)：

IntStream.iterate(0, i -> i + 1).limit(10) // LIMIT.skip(5) // OFFSET.forEach(System.out::println);

以上收益

5 6 7 8 9

是。 它不會(huì)在9之后繼續(xù)，因?yàn)楝F(xiàn)在先應(yīng)用limit() ，生成（0 1 2 3 4 5 6 7 8 9）。 之后應(yīng)用skip() ，將流減少到（5 6 7 8 9）。 不是您可能想要的。

注意LIMIT .. OFFSET與"OFFSET .. LIMIT"陷阱！

7.使用過濾器遍歷文件系統(tǒng)

以前我們已經(jīng)在博客上寫過 。 似乎一個(gè)好主意是使用過濾器遍歷文件系統(tǒng)：

Files.walk(Paths.get(".")).filter(p -> !p.toFile().getName().startsWith(".")).forEach(System.out::println);

上面的流似乎僅在非隱藏目錄（即不以點(diǎn)開頭的目錄）中移動(dòng)。 不幸的是，您又犯了＃5和＃6錯(cuò)誤。 walk()已經(jīng)產(chǎn)生了當(dāng)前目錄的整個(gè)子目錄流。 雖然懶惰，但邏輯上包含所有子路徑。 現(xiàn)在，過濾器將正確過濾出名稱以點(diǎn)“。”開頭的路徑。 例如.git或.idea將不屬于結(jié)果流。 但是這些路徑將是： .\.git\refs或.\.idea\libraries 。 不是你想要的。

現(xiàn)在，不要通過編寫以下內(nèi)容解決此問題：

Files.walk(Paths.get(".")).filter(p -> !p.toString().contains(File.separator + ".")).forEach(System.out::println);

盡管這將產(chǎn)生正確的輸出，但仍將通過遍歷完整的目錄子樹，然后遞歸到“隱藏”目錄的所有子目錄中來實(shí)現(xiàn)。

我猜您將不得不再次使用舊的JDK 1.0 File.list() 。 好消息是， FilenameFilter和FileFilter都是功能接口。

8.修改流的后備集合

在迭代List ，一定不能在迭代主體中修改相同的列表。 在Java 8之前確實(shí)如此，但是對(duì)于Java 8流，它可能變得更加棘手。 考慮以下來自0..9的列表：

// Of course, we create this list using streams: List<Integer> list = IntStream.range(0, 10).boxed().collect(toCollection(ArrayList::new));

現(xiàn)在，假設(shè)我們要在使用每個(gè)元素時(shí)將其刪除：

list.stream()// remove(Object), not remove(int)!.peek(list::remove).forEach(System.out::println);

有趣的是，這將適用于某些元素！ 您可能獲得的輸出是以下內(nèi)容：

0 2 4 6 8 null null null null null java.util.ConcurrentModificationException

如果我們?cè)诓东@到異常之后對(duì)列表進(jìn)行內(nèi)省，那么就會(huì)發(fā)現(xiàn)一個(gè)有趣的發(fā)現(xiàn)。 我們會(huì)得到：

[1, 3, 5, 7, 9]

嘿，它對(duì)所有奇數(shù)都有效。 這是錯(cuò)誤嗎？ 不，它看起來像個(gè)功能。 如果您正在研究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.*/

現(xiàn)在，檢查當(dāng)我們告訴流產(chǎn)生sorted()結(jié)果時(shí)會(huì)發(fā)生什么：

list.stream().sorted().peek(list::remove).forEach(System.out::println);

現(xiàn)在將產(chǎn)生以下“預(yù)期”輸出

0 1 2 3 4 5 6 7 8 9

和流消費(fèi)后的清單？ 它是空的：

[]

因此，所有元素都被消耗并正確刪除。 sorted()操作是“有狀態(tài)中間操作” ，這意味著后續(xù)操作不再對(duì)后備集合進(jìn)行操作，而是對(duì)內(nèi)部狀態(tài)進(jìn)行操作。 現(xiàn)在從列表中刪除元素是“安全的”！

好吧，我們真的可以嗎？ 讓我們繼續(xù)進(jìn)行parallel() ， sorted()移除：

list.stream().sorted().parallel().peek(list::remove).forEach(System.out::println);

現(xiàn)在產(chǎn)生：

7 6 2 5 8 4 1 0 9 3

并且列表包含

[8]

真是的 我們沒有刪除所有元素！ 解決此流難題的任何人都可以免費(fèi)獲得啤酒（ 和jOOQ貼紙 ）！

所有這些看起來都是非常隨機(jī)和微妙的，我們只能建議您在使用流時(shí)不要真正修改后備集合。 就是行不通。

9.忘記實(shí)際消耗流

您如何看待以下信息流？

IntStream.range(1, 5).peek(System.out::println).peek(i -> { if (i == 5) throw new RuntimeException("bang");});

閱讀此內(nèi)容時(shí)，您可能會(huì)認(rèn)為它將打印（1 2 3 4 5），然后引發(fā)異常。 但這是不正確的。 它什么也不會(huì)做。 流只是坐在那里，從來沒有被消耗過。

與任何流暢的API或DSL一樣，您實(shí)際上可能會(huì)忘記調(diào)用“終端”操作。 當(dāng)您使用peek()時(shí)尤其如此，因?yàn)閜eek()與forEach()非常相似。

當(dāng)您忘記調(diào)用execute()或fetch()時(shí)， jOOQ可能會(huì)發(fā)生同樣的情況：

DSL.using(configuration).update(TABLE).set(TABLE.COL1, 1).set(TABLE.COL2, "abc").where(TABLE.ID.eq(3));

哎呀。 沒有execute()

是的，“最佳”方法-1-2次警告！

10.并行流死鎖

現(xiàn)在這真是個(gè)好東西！

如果您未正確同步所有事物，則所有并發(fā)系統(tǒng)都可能陷入死鎖。 雖然找不到真實(shí)的例子很明顯，但找到強(qiáng)制的例子很明顯。 保證以下parallel()流會(huì)陷入死鎖：

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

請(qǐng)注意Unchecked.intConsumer()的使用，該函數(shù)將IntConsumer函數(shù)的接口轉(zhuǎn)換為org.jooq.lambda.fi.util.function.CheckedIntConsumer ，允許拋出已檢查的異常。

好。 您的機(jī)器運(yùn)氣不好。 這些線程將永遠(yuǎn)被阻塞！

好消息是，用Java編寫死鎖的教科書示例從未如此簡(jiǎn)單！

有關(guān)更多詳細(xì)信息，另請(qǐng)參見Brian Goetz對(duì)Stack Overflow的此問題的回答 。

結(jié)論

借助流和功能性思維，我們將遇到大量新的，細(xì)微的錯(cuò)誤。 除了實(shí)踐和保持專注之外，幾乎無法避免這些錯(cuò)誤。 您必須考慮如何訂購(gòu)您的手術(shù)。 您必須考慮流是否可能是無限的。

流（和lambda）是一個(gè)非常強(qiáng)大的工具。 但是首先我們需要掌握一種工具。

翻譯自: https://www.javacodegeeks.com/2014/06/java-8-friday-10-subtle-mistakes-when-using-the-streams-api.html

總結(jié)

以上是生活随笔為你收集整理的Java 8 Friday：使用Streams API时的10个细微错误的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。