Question

似乎这个问题应该已经有了答案，但我找不到重复的答案。

无论如何，我想知道社区对这样的Stream.map用例有何看法？

Wrapper wrapper = new Wrapper();
list.stream()
    .map( s -> {
        wrapper.setSource(s);
        return wrapper;
    } )
    .forEach( w -> processWrapper(w) );

public static class Source {
    private final String name;

    public Source(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

public static class Wrapper {
    private Source source = null;

    public void setSource(Source source) {
        this.source = source;
    }

    public String getName() {
        return source.getName();
    }
}

public void processWrapper(Wrapper wrapper) {
}

我不赞成使用map，但是在处理大型流时，它可能有助于提高性能，并避免为每个Wrapper创建不必要的Source。

这肯定有其局限性，例如对并行流和collect之类的终端操作几乎毫无用处。

更新- 问题不是关于“怎么做”，而是“我可以这样吗”。例如，我可以有一个仅适用于Wrapper的代码，但我想在forEach中调用它，但又希望避免为每个Source元素创建一个新实例。

基准测试结果

通过可重复使用的包装器显示出 8 倍的改进-

基准（N）模式Cnt得分错误单位

BenchmarkTest.noReuse 10000000平均5 870.253 ±122.495 ms / op

BenchmarkTest.withReuse 10000000 avgt 5 113.694 ±2.528 ms / op

基准代码-

import java.util.List;
import java.util.ArrayList;
import java.util.concurrent.TimeUnit;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
@Fork(value = 2, jvmArgs = {"-Xms2G", "-Xmx2G"})
public class BenchmarkTest {

    @Param({"10000000"})
    private int N;

    private List<Source> data;

    public static void main(String[] args) throws Exception {
        Options opt = new OptionsBuilder()
            .include(BenchmarkTest.class.getSimpleName())
            .forks(1)
            .build();
        new Runner(opt).run();
    }

    @Setup
    public void setup() {
        data = createData();
    }

    @Benchmark
    public void noReuse(Blackhole bh) {
        data.stream()
            .map( s -> new Wrapper1( s.getName() ) )
            .forEach( t -> processTarget(bh, t) );
    }

    @Benchmark
    public void withReuse(Blackhole bh) {
        Wrapper2 wrapper = new Wrapper2();
        data.stream()
            .map( s -> { wrapper.setSource(s); return wrapper; } )
            .forEach( w -> processTarget(bh, w) );
    }

    public void processTarget(Blackhole bh, Wrapper t) {
        bh.consume(t);
    }

    private List<Source> createData() {
        List<Source> data = new ArrayList<>();
        for (int i = 0; i < N; i++) {
            data.add( new Source("Number : " + i) );
        }
        return data;
    }

    public static class Source {
        private final String name;

        public Source(String name) {
            this.name = name;
        }

        public String getName() {
            return name;
        }
    }

    public interface Wrapper {
        public String getName();
    }

    public static class Wrapper1 implements Wrapper {
        private final String name;

        public Wrapper1(String name) {
            this.name = name;
        }

        public String getName() {
            return name;
        }
    }

    public static class Wrapper2 implements Wrapper {
        private Source source = null;

        public void setSource(Source source) {
            this.source = source;
        }

        public String getName() {
            return source.getName();
        }
    }
}

完整基准测试报告-

# JMH version: 1.21
# VM version: JDK 1.8.0_191, Java HotSpot(TM) 64-Bit Server VM, 25.191-b12
# VM invoker: /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/bin/java
# VM options: -Xms2G -Xmx2G
# Warmup: 5 iterations, 10 s each
# Measurement: 5 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: BenchmarkTest.noReuse
# Parameters: (N = 10000000)

# Run progress: 0.00% complete, ETA 00:03:20
# Fork: 1 of 1
# Warmup Iteration   1: 1083.656 ms/op
# Warmup Iteration   2: 846.485 ms/op
# Warmup Iteration   3: 901.164 ms/op
# Warmup Iteration   4: 849.659 ms/op
# Warmup Iteration   5: 903.805 ms/op
Iteration   1: 847.008 ms/op
Iteration   2: 895.800 ms/op
Iteration   3: 892.642 ms/op
Iteration   4: 825.901 ms/op
Iteration   5: 889.914 ms/op


Result "BenchmartTest.noReuse":
  870.253 ±(99.9%) 122.495 ms/op [Average]
  (min, avg, max) = (825.901, 870.253, 895.800), stdev = 31.812
  CI (99.9%): [747.758, 992.748] (assumes normal distribution)


# JMH version: 1.21
# VM version: JDK 1.8.0_191, Java HotSpot(TM) 64-Bit Server VM, 25.191-b12
# VM invoker: /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/bin/java
# VM options: -Xms2G -Xmx2G
# Warmup: 5 iterations, 10 s each
# Measurement: 5 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: BenchmarkTest.withReuse
# Parameters: (N = 10000000)

# Run progress: 50.00% complete, ETA 00:01:58
# Fork: 1 of 1
# Warmup Iteration   1: 113.780 ms/op
# Warmup Iteration   2: 113.643 ms/op
# Warmup Iteration   3: 114.323 ms/op
# Warmup Iteration   4: 114.258 ms/op
# Warmup Iteration   5: 117.351 ms/op
Iteration   1: 114.526 ms/op
Iteration   2: 113.944 ms/op
Iteration   3: 113.943 ms/op
Iteration   4: 112.930 ms/op
Iteration   5: 113.124 ms/op


Result "BenchmarkTest.withReuse":
  113.694 ±(99.9%) 2.528 ms/op [Average]
  (min, avg, max) = (112.930, 113.694, 114.526), stdev = 0.657
  CI (99.9%): [111.165, 116.222] (assumes normal distribution)


# Run complete. Total time: 00:03:40

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

Benchmark                     (N)  Mode  Cnt    Score     Error  Units
BenchmarkTest.noReuse    10000000  avgt    5  870.253 ± 122.495  ms/op
BenchmarkTest.withReuse  10000000  avgt    5  113.694 ±   2.528  ms/op

Answer 1

您的方法之所以起作用，是因为流管道仅由无状态操作组成。在这样的星座中，顺序流评估可以一次处理一个元素，因此对包装实例的访问不会重叠，例如illustrated here。但是请注意，这不是保证的行为。

它绝对不适用于sorted和distinct之类的有状态操作。它也不能与归约运算一起使用，因为它们总是必须至少包含两个要处理的元素，包括reduce，min和max。对于collect，它取决于特定的Collector。由于需要缓冲，forEachOrdered无法用于并行流。

请注意，即使您使用TheadLocal创建线程受限包装器，并行处理也会出现问题，因为无法保证在一个工作线程中创建的对象仍位于该线程本地。辅助线程可以在接收其他无关的工作负载之前将部分结果移交给另一个线程。

因此，此共享的可变包装器可与一组特定的无状态操作配合使用，例如map，filter，forEach，findFirst/Any，all/any/noneMatch。顺序执行特定的实现。您没有获得API的灵活性，因为您必须限制自己，无法将流传递给期望Stream的任意代码，也不能使用任意Collector的实现。您还没有接口的封装，因为您要承担特定的实现行为。

换句话说，如果您想使用这样的可变包装器，则最好使用实现特定操作的循环。您确实已经有这种手动实施的缺点，所以为什么不实施它就具有优势。

要考虑的另一个方面是，从重用这种可变的包装器中可以获得什么。它只能在类似循环的用法中使用，在临时用法中，无论如何应用Escape Analysis后，临时对象可能会被优化。在这种情况下，重用对象会延长其寿命，实际上可能会降低性能。

当然，对象标定不是保证的行为。在某些情况下，例如长流管道超过了JVM的内联限制，这些对象就不会消失。但是，临时对象不一定昂贵。

这已在this answer中进行了解释。临时对象便宜地分配。垃圾回收的主要成本是由仍然存在的对象引起的。在为新分配腾出空间时，需要遍历这些元素，并移动它们。临时对象的负面影响是，它们可能会缩短垃圾收集之间的时间间隔。但这是分配速率和可用分配空间的函数，因此这确实是一个问题，可以通过向其添加更多RAM来解决。更多的RAM意味着GC周期之间的更多时间和发生GC时更多的死对象，这使GC的净成本降低了。

尽管如此，避免过度分配临时对象仍然是一个令人关注的问题。 IntStream，LongStream和DoubleStream的存在表明了这一点。但是这些都是特殊的，因为使用原始类型是使用包装对象的一种可行的替代方法，而没有重用可变包装器的缺点。它也有所不同，因为它适用于原始类型和包装器类型在语义上等效的问题。相反，您要解决操作需要包装器类型的问题。对于原始流也适用，当您需要解决问题的对象时，装箱是没有办法的，装箱将为不同的值创建不同的对象，而不共享可变对象。

因此，如果类似地存在一个在语义上等效的避免包装器对象的替代方案而没有实质性问题的问题，例如在可行的情况下仅使用Comparator.comparingInt而不是Comparator.comparing，您可能还是更喜欢它。但只有那样。

简而言之，在大多数情况下，节省此类对象重用（如果有的话）不会证明缺点。在特殊情况下，这是有益的并且很重要，最好使用循环或完全控制的任何其他构造，而不要使用Stream。

Answer 2

您可以使用一些方便的功能，也可以使用线程安全版本来并行处理。

Function<T,U> threadSafeReusableWrapper(Supplier<U> newWrapperInstanceFn, BiConsumer<U,T> wrapFn) {
   final ThreadLocal<T> wrapperStorage = ThreadLocal.withInitial(newWrapperInstanceFn);
   return item -> {
      T wrapper = wrapperStorage.get();
      wrapFn.consume(wrapper, item);
      return wrapper;
   }
}

Function<T,U> reusableWrapper(U wrapper, BiConsumer<U,T> wrapFn) {
   return item -> {
      wrapFn.consume(wrapper, item);
      return wrapper;
   };
}

list.stream()
    .map(reusableWrapper(new Wrapper(), Wrapper::setSource))
    .forEach( w -> processWrapper(w) );
list.stream()
    .map(threadSafeReusableWrapper(Wrapper::new, Wrapper::setSource))
     .parallel()
    .forEach( w -> processWrapper(w) );

但是，我认为这不值得。这些包装材料寿命短，因此不太可能离开年轻一代，因此很快就会被垃圾收集。不过，我认为这个想法值得micro-benchmark library JMH

进行检查

Answer 3

尽管有可能，但在流外部引用对象会使代码的功能性降低。只需使用一个辅助函数就可以实现封装得非常紧密的等效项：

public class Context {

    private static final Wrapper WRAPPER = new Wrapper();

    private static void helper(Source source) {
        WRAPPER.setSource(source);
        processWrapper(WRAPPER);
    }

    public static void main(String[] args) {
        List<Source> list = Arrays.asList(new Source("Foo"), new Source("Baz"), new Source("Bar"));
        list.stream().forEach(Context::helper);
}

Java流图中可重用的单实例包装器/对象

3 个答案: