Why overload the varargs method of() in Java Stream interface?(为什么要在 Java Stream 接口中重载 varargs 方法 of()?)
问题描述
流 接口对方法 of() 有两个重载.其中一个是可变参数方法,而另一个采用单个参数.
The Stream interface has two overloads for the method of(). One of these is a variable-arity method while the other takes a single argument.
与将一个参数传递给可变参数方法相比,单参数方法是一种性能优化吗?如果是这样,它如何提高性能?可以对 empty() 方法提出相同的问题,这似乎是可变参数 of() 周围的语法糖.
Is the single-argument method a performance optimization versus passing one argument to the variable-arity method? If so, how does it improve performance? The same questions could be asked of the empty() method, which would seem to be syntax sugar around the variable-arity of().
我发现这些方法的实现方式不同,区别显然在于 Spliterator 的实例化方式;但这对 Stream API 有什么好处?
I see that the implementation differs between these methods, with the difference apparently being how the Spliterator is instantiated; but what advantage does this offer to the Stream API?
推荐答案
是的,这是一种优化,可以避免创建一个只包含单个元素的数组的开销,如果你使用 varargs 版本,你会得到这样的结果.
Yes, it's an optimization to avoid the overhead of creating an array to hold only a single element, which is what you'd get if you used the varargs version.
empty() 方法也可以问同样的问题,这似乎是围绕可变参数 of() 的语法糖
The same questions could be asked of the empty() method, which would seem to be syntax sugar around the variable-arity of()
您在看什么实施版本?当我查看实现时,我看不到这一点.
What implementation version are you looking at? When I look at the implementation I don't see this.
这篇关于为什么要在 Java Stream 接口中重载 varargs 方法 of()?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:为什么要在 Java Stream 接口中重载 varargs 方法 of()?
基础教程推荐
- RabbitMQ:消息保持“未确认"; 2022-01-01
- 问题http://apache.org/xml/features/xinclude测试日志4j 2 2022-01-01
- 存储 20 位数字的数据类型 2022-01-01
- Spring AOP错误无法懒惰地为此建议构建thisJoinPoin 2022-09-13
- 如何对 Java Hashmap 中的值求和 2022-01-01
- REST Web 服务返回 415 - 不支持的媒体类型 2022-01-01
- 使用堆栈算法进行括号/括号匹配 2022-01-01
- Struts2 URL 无法访问 2022-01-01
- 修改 void 函数的输入参数,然后读取 2022-01-01
- 无法复制:“比较方法违反了它的一般约定!" 2022-01-01
