使用LongStream和jOOλ生成素数会导致StackOverflowError

时间:2016-03-13 08:55:13

标签: java java-8 stack-overflow java-stream

出于教育目的,我想使用Java-8创建素数流。这是我的方法。如果没有不超过x的素数除数,则sqrt(x)为素数。因此,假设我已经有一个素数流我可以使用以下谓词检查:

x -> Seq.seq(primes()).limitWhile(p -> p <= Math.sqrt(x)).allMatch(p -> x % p != 0)

在这里,我使用jOOλ库(0.9.10,如果重要的话)仅用于标准Stream API中不存在的limitWhile操作。所以现在知道一些以前的素数prev我可以生成下一个素数迭代数字,直到找到与该谓词匹配的那个:

prev -> LongStream.iterate(prev + 1, i -> i + 1)
                  .filter(x -> Seq.seq(primes()).limitWhile(p -> p <= Math.sqrt(x))
                                                .allMatch(p -> x % p != 0))
                  .findFirst()
                  .getAsLong()

将所有内容放在一起我编写了以下primes()方法:

public static LongStream primes() {
    return LongStream.iterate(2L, 
            prev -> LongStream.iterate(prev + 1, i -> i + 1)
                              .filter(x -> Seq.seq(primes())
                                              .limitWhile(p -> p <= Math.sqrt(x))
                                              .allMatch(p -> x % p != 0))
                              .findFirst()
                              .getAsLong());
}

现在启动它我使用:

primes().forEach(System.out::println);

不幸的是,它失败了,令人不快的StackOverflowError看起来像这样:

Exception in thread "main" java.lang.StackOverflowError
at java.util.stream.ReferencePipeline$StatelessOp.opIsStateful(ReferencePipeline.java:624)
at java.util.stream.AbstractPipeline.<init>(AbstractPipeline.java:211)
at java.util.stream.ReferencePipeline.<init>(ReferencePipeline.java:94)
at java.util.stream.ReferencePipeline$StatelessOp.<init>(ReferencePipeline.java:618)
at java.util.stream.LongPipeline$3.<init>(LongPipeline.java:225)
at java.util.stream.LongPipeline.mapToObj(LongPipeline.java:224)
at java.util.stream.LongPipeline.boxed(LongPipeline.java:201)
at org.jooq.lambda.Seq.seq(Seq.java:2481)
at Primes.lambda$2(Primes.java:13)
at Primes$$Lambda$4/1555009629.test(Unknown Source)
at java.util.stream.LongPipeline$8$1.accept(LongPipeline.java:324)
at java.util.Spliterators$LongIteratorSpliterator.tryAdvance(Spliterators.java:2009)
at java.util.stream.LongPipeline.forEachWithCancel(LongPipeline.java:160)
at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:529)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:516)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)
at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.LongPipeline.findFirst(LongPipeline.java:474)
at Primes.lambda$0(Primes.java:14)
at Primes$$Lambda$1/918221580.applyAsLong(Unknown Source)
at java.util.stream.LongStream$1.nextLong(LongStream.java:747)
at java.util.Spliterators$LongIteratorSpliterator.tryAdvance(Spliterators.java:2009)
...

您可能认为我应该得到的东西:我在primes()方法本身内递归调用了primes()。但是,我们只需将方法返回类型更改为Stream<Long>并使用Stream.iterate代替其他所有内容:

public static Stream<Long> primes() {
    return Stream.iterate(2L, 
            prev -> LongStream.iterate(prev + 1, i -> i + 1)
                              .filter(x -> Seq.seq(primes())
                                              .limitWhile(p -> p <= Math.sqrt(x))
                                              .allMatch(p -> x % p != 0))
                              .findFirst()
                              .getAsLong());
}

现在它就像一个魅力!不是很快,但在几分钟内,我得到的素数超过1000000,没有任何例外。结果是正确的,可以根据素数表进行检查:

System.out.println(primes().skip(9999).findFirst());
// prints Optional[104729] which is actually 10000th prime.

所以问题是:基于LongStream的第一个版本出了什么问题?是jOOλbug,JDK bug还是我做错了什么?

请注意,我对生成素数的替代方法不感兴趣,我想知道这个特定代码有什么问题。

2 个答案:

答案 0 :(得分:18)

LongStream生成流时,Streamiterate的行为似乎有所不同。以下代码说明了区别:

LongStream.iterate(1, i -> {
    System.out.println("LongStream incrementing " + i);
    return i + 1;
}).limit(1).count();

Stream.iterate(1L, i -> {
    System.out.println("Stream incrementing " + i);
    return i + 1;
}).limit(1).count();

输出

  

LongStream递增1

所以LongStream即使只需要第一个元素而Stream也不需要,也会调用该函数。这解释了您获得的例外情况。

我不知道这是否应该被称为bug。 Javadoc没有以这种或那种方式指定这种行为,尽管如果它是一致的那样会很好。

解决这个问题的一种方法是硬编码素数的初始序列:

public static LongStream primes() {
    return LongStream.iterate(2L,
        prev -> prev == 2 ? 3 : 
                prev == 3 ? 5 :
                LongStream.iterate(prev + 1, i -> i + 1)
                        .filter(x -> Seq.seq(primes())
                            .limitWhile(p -> p <= Math.sqrt(x))
                            .allMatch(p -> x % p != 0)
                        ).findFirst()
                        .getAsLong());

答案 1 :(得分:15)

你可以用更简单的方式产生这种差异。考虑以下两个版本(同样效率低下)的递归长枚举流,可以按如下方式调用以生成1-5的序列:

longs().limit(5).forEach(System.out::println);

会导致相同的StackOverflowError

public static LongStream longs() {
    return LongStream.iterate(1L, i ->
        1L + longs().skip(i - 1L)
                    .findFirst()
                    .getAsLong());
}

将起作用

public static Stream<Long> longs() {
    return Stream.iterate(1L, i ->
        1L + longs().skip(i - 1L)
                    .findFirst()
                    .get());
}

原因

盒装Stream.iterate()实施优化如下:

    final Iterator<T> iterator = new Iterator<T>() {
        @SuppressWarnings("unchecked")
        T t = (T) Streams.NONE;

        @Override
        public boolean hasNext() {
            return true;
        }

        @Override
        public T next() {
            return t = (t == Streams.NONE) ? seed : f.apply(t);
        }
    };

LongStream.iterate()版本不同:

    final PrimitiveIterator.OfLong iterator = new PrimitiveIterator.OfLong() {
        long t = seed;

        @Override
        public boolean hasNext() {
            return true;
        }

        @Override
        public long nextLong() {
            long v = t;
            t = f.applyAsLong(t);
            return v;
        }
    };

注意盒装迭代器只有在返回种子后才调用函数,而原始迭代器在返回种子之前缓存下一个值。

这意味着当您使用带有原始迭代器的递归迭代函数时,永远不会生成流中的第一个值,因为下一个值是过早获取的。

这可能会被报告为JDK错误,还有explains Misha's observation