雖然CollectionAPI 提供了三個多載toArray
Object[] toArray()T[] toArray(IntFunction<T[]> generator)T[] toArray(T[] a)
API 僅提供前Stream兩個。也就是說，它不提供使用現有陣列作為流到陣列轉換的回傳值的方法。
toArray(T[] a)--> in省略的原因是什么Stream？
我想主要原因是流的功能精神，這會產生副作用，例如不希望寫入現有陣列。這個對嗎 ？還有其他原因會使其他兩個版本更受歡迎嗎？也許甚至有一些原因使它們在 a 上也更受歡迎Collection？
uj5u.com熱心網友回復：
使用的常見模式（至少根據我的觀察）Collection.toArray(T[])是這樣的：
var array = list.toArray( new T[0] );
這意味著提供了一個大小為 0 的空陣列。
使用現有陣列呼叫toArray()允許回傳正確型別的陣列，與Object. 除了通過“樣本”之外，沒有其他方法可以將所需回傳型別的型別提供給方法。您可以考慮 like toArray( Class<T> elementType )，但如果T它也是引數化型別，那也不能正常作業。
引入 Lambda 時，帶有 的IntFunction<T[]>變體在其功能中用現有陣列替換了變體，因此對于Stream. 我希望它Collection.toArray(T[])很快就會被棄用，并且會隨著即將到來的 LTS 版本之一被洗掉——當然不是下一個版本，或者下一個版本之后的版本！
uj5u.com熱心網友回復：
如果我們考慮 的規范Collection.toArray(T[])：
[…] 如果集合適合指定的陣列，則在其中回傳。否則，將使用指定陣列的運行時型別和此集合的大小分配一個新陣列。
但是，有一些問題會阻止對流執行相同的操作：
- 實作無法提前知道未知大小的流是否適合
- 對于并行流，如果原始拆分器不存在，拆分
Spliterator已知大小（即SIZED）的流（）可能會導致 2 個大小未知的拆分器SUBSIZED，因此拆分后您將不知道將資料放在哪里
在這兩種情況下，實作仍然必須創建新陣列并通過復制資料來完成，這違背了上述要求的目的。
在許多情況下，您正在使用大小未知的流（簡單filter()或flatMap()將洗掉該屬性），您通常會陷入上述限制。
此外，即使對于已知大小的情況，人們也經常在呼叫時分配一個大小合適的新陣列Collection.toArray(T[])。這在最近的 JVM 版本中實際上適得其反，因此在 Stream API 中引入同樣的問題將是一件壞事。
最后，基于現有陣列創建新陣列只能通過反射來完成，這會增加自己的開銷。
最后，如果我們洗掉填充提供的陣列的要求，該版本似乎沒有太多好處toArray(IntFunction<T[]>)。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/422254.html
標籤：